LiteDB – A .NET NoSQL Document Store in a Single Data File | Hacker News Reader

LiteDB – A .NET NoSQL Document Store in a Single Data File

github.com

116 pointsingve52 comments

Great to see another NoSQL DB on .NET landscape. In my UWP days I had to port LevelDB (https://github.com/maxpert/LevelDBWinRT shameless plug, it's available as nuget package too). But it only works on UWP this seems more robust and it can work on Xamarin.

I really wish this had existed back when I still coded apps in .NET.

Of course I would opt for Sqlite, however if I really need NoSQL type of data I always would recommend LiteDB.

The API is similar to MongoDB which is great because I consider MongoDB drivers the best DB drivers for C# except for maybe EF.

Is it possible to pre-allocate a fixed-size file with sqlite to then use as a local cache evicting old data? Supporting this may offer a chance to differentiate a bit.

Closest I could find was a workaround that is probably close enough (disable auto_vacuum and delete a giant blob) https://stackoverflow.com/a/4821318.

can you elaborate on opting for Sqllite?

Battle-tested multiplatform support (and thus reliability) is definitely a key selling point. This is further reinforced by its impressively extensive test suite.

Long ago I lost my first Android smartphone's SMS database since they used to delete + re-create even barely corrupted databases, but by now most of the kinks have been worked out.

Plus it's amazingly fast and is packed with SQL features. For such a small lib, it's a miracle. And the way the author talks about it (he is not from a DB background) it so funny.

Sqlite is one of the simplest RDBMSs that you can run on a client, which is really useful for deploying apps that need their own data store

Also Sqlite has native EF drivers which makes it first-class .NET citizen.

Very cool! You can also test-drive it online using their shell (has some restrictions according to their docs)

http://www.litedb.org/#shell

I wonder how 'production ready' this is.

A very valid use case is for use in MVPs and side-projects that would be hosted on Azure. I built an MVP using .Net and SQL Server for the database (db was needed only once a day for 30 mins to do batch jobs and save data), only to find out upon deployment that you have to pay about $50/ month minimum to have your 1 SQL Server database up and running, and also that you can't 'switch it off' ever and save $ [1].

So I ended up rewriting parts of the data layer to use SQL Lite and an embedded .DB data file.

[1] Source: Stopping SQL Azure DB when not in use https://stackoverflow.com/a/42063293/325521

Azure's cheapest SQL Server as-a-service offering is only $5/mo.

I did not know this. Recent addition? Just googled it and you are right, single database with 2 GB storage is $4.9.. / months.

https://azure.microsoft.com/en-us/pricing/details/sql-databa...

Thanks!!

We're using it for syncing thousand of files and it's very reliable!

> One database per account/user data store

This is very interesting to me. I am writing a multi-tenant app with a single RDBMS schema right now and balancing all of my needs (scaling/sharding, partitioning tables, normalizing vs denormalizing) has been challenging.

I've never written a system with a whole database per account. Does anyone have any good reading or examples on this general tactic?

It has it's plusses and minuses. The plusses are that everything is isolated and the data doesn't get too big. It becomes problematic when you need to access multiple clients at the same time (and you probably will at some point). Deployment is harder since you have to do it more. Keeping schema versioning straight is also a pain. Data isolation is inherent in single tenant though.

See actordb

LiteDB is pretty neat. Side note, RavenDB is another .NET document-style full stack database that just hit 4.0 today: https://ravendb.net/

This is pretty cool. If it has low enough overhead, I wonder if this could be used to replace the current format of ODT (Open Document) files, which right now are basically just zipped up XML documents and image assets

Looking at the file format limitations [1], it doesn't seem like a good fit for an alternative to ODT files. (A cursory judgment based solely on this wiki page has me wondering if they are using the best data structure for an Index, but again, very cursory.)

A question is why you would want to replace the current ODT format? "Just" a zipped up file tree of XML documents and image assets is a pretty robust format choice. There are unzip programs on almost every platform. XML isn't always everyone's favorite markup language, but it's well supported by almost every language ecosystem, and still roughly okay to humanly eyeball if needed. The relative inefficiencies of the textual encoding and verbosity of XML are directly suited for compression efficiency of a Zip file. For most trade-offs of a document file, it's a somewhat resilient option, with likely a long shelf life (both zip and XML technologies have lasted enough decades, and are reasonably well standardized enough, that you can imagine they will continue to be unzippable/readable decades from now).

[1] https://github.com/mbdavid/LiteDB/wiki/How-LiteDB-Works

Well suited? Zip?

I’ve tested some hacks to get a file below email server file size limitations. Unzipping an excel file, then tarballing it into a .tar.xz archive can cut the size by 30%, say. The only issue is that the receiver might not know what on earth to do with it!

Another trick is you can repack modern MS Office files with advzip from advancecomp. With -z4 It will use Zopfli to pack them. Further gains can be had with more rounds, (such as -i50). The resulting files can be quite a bit smaller and Office will open them without complaint.

Yet another trick is you can save as binary format files. In Excel this is XLSB. Supposedly those are less compatible across Office versions however.

"Well suited" doesn't necessarily mean "best suited". :)

Because incremental updates are very difficult in a zip file.

The point of an embedded database like LiteDB or SQLite is to allow incremental updates to a file without needing to write out the entire file every time.

The nice thing about tools like SQLite and LiteDB is that they have APIs that are fundamentally similar to APIs that we already know. It keeps the learning curve light so we can spend more time on the task at hand instead of learning a new thing.

Give the size of most ODT files and the power of current computers, incremental updates are completely irrelevant. Regenerating the entire file takes a blink.

But the current format benefit from the XML ecosystem (validation, transformation, namespacing, nesting, semantic markup) that is very handy for a document.

Plus, being text based is a very good selling point if you want your format to last: event in 30 years if you don't have the spec, you can peak in the zip and see what's up.

sqlite has already done a similar thought experiment: https://sqlite.org/affcase1.html

Why would I want to use that over BDB or TokyoCabinet?

I revisited these databases recently while researching if any serverless redis options are available.

BDB is under Oracle. Some people may not want to navigate the white papers and pricing questions to get to the database.

TokyoCabinet appears to be dormant seven years.

Anyway, I assume LiteDB has better C# integration.

LMDB is a faster BDB

Benchmarks? (R/W ops per second, etc.)

What is the advantage over SQLite?

I needed a small for my C# MAME frontend IV/Play, it didn't matter if it was relational on not. I picked this over SQLite because it's a single native DLL with no dependencies. It also supports POCO mappings (think serialization) which usually requires some ORM type package.

SQLite in .NET is still a little messy - there are several versions in various state of support, and they all depend on multiple packages.

I am developing a mobile game and the BaaS we use (Gamesparks) uses MongoDB. Currently I use SQLite to cache the data locally, but that can be a pain to transform document formatted data to relational, and back. I wish I had known about this before (and I use Unity so the app code is C#).

SQLite can work as a document store too. Data can be any type (in spite of defined column types), and it works even for pretty big document sizes.

Interesting, I did not know that. However, I use a 3rd party framework to transform the table rows to classes, and I assume I would lose all that magic conversion. In other words, the reason I go through all the effort of transforming to relational is for querying and updating, but if I just put the raw document in there, I won't have granularity on my querying (I imagine).

You can store everything in JSON in SQLite and then query it using json functions (https://www.sqlite.org/json1.html) or even combine than with indexes on expressions (https://sqlite.org/expridx.html) if you have a good indexable property

Ok this is pretty cool. This is also why I love HN. I've been using SQLite for ~3 years, have I missed this from the beginning or has it been added since then?

Probably wasn't available at that time.

From the VCS history, looks like it was very first started on 2015-08-12, not sure when it became stable or part of a release.

It's definitely only about two years old. I remember commenting on it when someone submitted the repo timeline relating to JSON on HN.

Back in the dark ages as everyone upgraded from 32-bit to 64-bit environments, shipping two versions of native dependencies caused extra hassle. However, this may not be much of an issue these days.

I don't know for sure, but I believe it would be that SQLite is relational, this is NoSQL (document key/value store)

It's native and NoSQL.

NoSQL is not a feature, it is the lack of a feature.

This car is a NoTires car! You don't have to go through the hassle of replacing your tires! :)

Any day, if someone invents wheels for the twentyfirst century. The rubber-rings are a kludge, not a fundamental condition of life.

Says you.

"NoSQL" is a meaningless term. Even when strictly taken as either not supporting SQL or not relational, it is a rather useless way to search for options.

We've our own dot net based InMemory Columnstore at InMemory.Net

is there a library like this in c++?

Yeah, it's called EJDB. https://github.com/Softmotions/ejdb

Thanks

You mean like Tokyo cabinet?

ya, something like mongodb, but embed-able into an application.

Reply on news.ycombinator.com