Suggestions for a simple NoSQL DB for .NET/Mono

S

Spacerat

Expert Member
Joined
Jul 29, 2015
Messages
1,527
Reaction score
660
I need to implement a simple table database that is nice and fast. Needs to talk to .NET and run on Linux/Mono. Pref zero install (just an assembly reference). I could use Sqlite but might be a bit on the slow side. Basically just for implementing a persisted queue type mechanism. But slightly more rich functionality than just a queue.

Any other suggestions?
 
NoSQLite ?

Don't think you're going to get anything (much) better than SQLite/NoSQLite using just an assembly reference. Speed should only be an issue IMO if the db file gets very big.
 
Hamster said:
NoSQLite ?

Don't think you're going to get anything (much) better than SQLite/NoSQLite using just an assembly reference. Speed should only be an issue IMO if the db file gets very big.
Click to expand...

Can always put the SQLite db into memory as well if it's only gonna be used for a few entries?

Otherwise I would've suggested something like redis just because of the simplicity and speed, although that requires an installation...
 
Last edited:
Tx for the responses. This is going to run in embedded fashion on Mono but dev on a Win PC. The Mono version we use is compatible with .NET 2. So yes maybe Sqlite/NoSqlite is the best option. Its just to temporarily store data until it is uploaded.
 
It's a bit unclear what you need exactly; but considering that you mentioned a "persisted queue type mechanism"; I am picturing an end to solution; where this part queues it (because of some overhead: network?), persisting to disk and transmits.

If that's the case; why bother with SQL; because won't that just create extra work for decoding / encoding of those transmissions? If I understood correct; then why not just use an existing persistent queuing solution?
 
Last edited:
...or dump flat files to disk and keep the metadata in memory (depending on requirements of course).
 
I've used Lightning.NET (an LMDB key/value store) before for a small project.
It doesn't need an installation and just basically streams directly to memory/file as set up.

You just need to check the .NET2/Mono compatibility.

https://github.com/CoreyKaylor/Lightning.NET
 
[)roi(];20382427 said:
It's a bit unclear what you need exactly; but considering that you mentioned a "persisted queue type mechanism"; I am picturing an end to solution; where this part queues it (because of some overhead: network?), persisting to disk and transmits.

If that's the case; why bother with SQL; because won't that just create extra work for decoding / encoding of those transmissions? If I understood correct; then why not just use an existing persistent queuing solution?
Click to expand...

Tx will look at the link...

This is a portable embedded device running Linux. It basically gathers data samples and needs to store it until the device has connectivity to a network. Once the device is connected to a network, the sample are uploaded to a server. Persistence of the samples is required because the app may be closed between sessions. So the 'DB' is purely there for transient storage from when the sample was taken to when it is uploaded.

File based could be an option i.e. log a certain number of samples to a file as a 'block'. And then like Hamster said, keep the metadata in a DB. Then the upload can also be per file as a 'block'.

But my first thought was just to have a simple flat persisted table implementation to push samples into and pull as it uploads.
 
Store-n-forward basically. You could even go as far as storing the metadata as a header in each file and skip the db altogether. Create a class with all the details, serialise to disk.
 
Spacerat said:
Tx will look at the link...

This is a portable embedded device running Linux. It basically gathers data samples and needs to store it until the device has connectivity to a network. Once the device is connected to a network, the sample are uploaded to a server. Persistence of the samples is required because the app may be closed between sessions. So the 'DB' is purely there for transient storage from when the sample was taken to when it is uploaded.

File based could be an option i.e. log a certain number of samples to a file as a 'block'. And then like Hamster said, keep the metadata in a DB. Then the upload can also be per file as a 'block'.

But my first thought was just to have a simple flat persisted table implementation to push samples into and pull as it uploads.
Click to expand...
Most are probably far more complex than you need. I'd probably either hinge it off something simple like SFTP, or build something custom or a bit of both.
Anyway here's a decent enough example of a build it yourself option with only C#:
https://www.google.com/url?sa=t&rct...or-NET&usg=AFQjCNEUkXG18nabtKAhaV9zsNJBKslqvg
 
Hamster said:
NoSQLite ?

Don't think you're going to get anything (much) better than SQLite/NoSQLite using just an assembly reference. Speed should only be an issue IMO if the db file gets very big.
Click to expand...

Something I'm tinkering with atm. Sqlite database only 3 tables. Easy peasy.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X