LiteDB: A .NET embedded NoSQL database
litedb.org
litedb.org
Building on top of Microsoft's FASTER[1] Log and FASTER KV would be a good option for a storage engine, as that is also C# and notably provides higher performance than the in-memory ConcurrentDictionary class in the standard library!
LiteDB uses locks for writers, which means it has virtually no chance of being anywhere near as performant as a lock-free log.
For the link you provided, I wonder if Microsoft would accept a pull request to merge it into the standard library to replace the built-in concurrent dictionary…?
However, it might not be off the table yet, because scaling per core is dramatically better especially in moderate to write-heavy scenarios which remains the main use case for ConcurrentDictionary. I have been benchmarking it on arm64 lately and it shows different numbers much more favoring non-blocking implementation without any regressions discussed in the PR.
I think you chose this instead of MongoDB like you would chose SQLite instead of MSSQL. The library is very similar to Mongo's .Net library, so its almost a 1:1 code replacement.
I guess it depends on what's important.
Some people primarily care about the API. Other people focus on the operational story.
Another thing is you might want the lack of features. I.e. you want it so people don't do joins etc. Because you want the team to use the same paradigm with local data as with server hosted. I can think of reasons why.
The native Sqlite wrapper libraries such as Microsoft's Microsoft.Data.Sqlite have faster performance than EF, but because you're forced to pass around SQL strings, most .NET dev's don't prefer to use them.
Perf with litedb is pretty awful in my experience if you're using it as a schemaful db. But it's probably the wrong tool for the job if you're comparing to sqlite. I've yet to come across any embedded db that can do schema + document with decent performance.
I am yet to find a modern up-to-date tutorial and implementation of System.Data.Sqlite that offers encrypted database support without making my brain melt.
The ergonomics could be better, but this enabled query execution to avoid heap allocations and reflection.
SQLite is slower than LiteDB in this benchmark project created by the LiteDB inventor
https://github.com/mbdavid/LiteDB-Benchmark
https://github.com/mbdavid/LiteDB/issues/291
Another (lesser) reason is the similarity to MongoDB methods, if that's what you are used to it will feel familiar, but no MongoDB server needed.
I just mention this because a lot of these little issues might only become more apparent after integrating the db into your project and so it can be a bit annoying.
Have a look: https://martendb.io/documents/
How to query: https://martendb.io/documents/indexing/duplicated-fields.htm...
Ended up ripping it out, it caused no end of crashes and bugs. Hopefully its more stable now.
the right sides shows
SELECT title, year, genres FROM movies...Best way to read it nowadays is probably "not like the popular DB's of the 90's".
I don't think I would use EF Core with a document database, but I can understand the appeal in sharing models with EF Core, and maybe even utilizing a shared "Change Tracker". Unless you are doing your own things, most EF Core models should be POCOs easily enough serializable to JSON to directly use in your document DB, and EF Core contexts at this point have an easy enough Change Tracker API to query that you could possibly reuse it easily enough for a document DB (though that is probably overkill because you don't need per-property tracking at that point usually, just per-document tracking).
Ravendb has a great linq provider and is a nosql db.
We use LiteDB to hold all game state: objects on the ground, button/switch states, ai variables, inventory, etc. LiteDB allows using C# classes directly with the BSON mapper, allowing easy interoperability between the database and using the data in game. LiteDB allows using MemoryStreams which are convenient for loading and saving from a binary storage like a cloud service or a file. It’s fast at querying, but we’ve had issue with upsert performance so we perform all upserts at once in a separate thread to not impact the main game thread. Over all has worked well for the project and has had minimal issues over a year plus of development.
(I recently found LiteDB while researching log destinations.)
For me, yes. I experience a pretty large performance hit on shared vs direct mode. That being said, shared mode does seem to work with multiple processes; However, all processes must be on the same machine, as he uses a mutex around critical code. Or at least, he did last time I looked at the codebase.
If your DB is on a network location and the processes are on different machines, bad things will happen.
My experience is that LiteDB in direct mode is faster than SQLite, but in shared mode is slower.
I have only used Serilog for pet projects so far, but liked it really much, and have uses MS / Nlog and other "battle tested" solution is larger deployments so far. had some letdowns with those as well.
Surprising..