There seems to be a lot of embedded KV store already, and SQLite is pretty much the defacto embedded relational DB. Is there a good embedded Graph DB around? Specifically, a embedded property graph DB. Hypergraphdb is embeddable, but it's not property graph, and while neo4j has an embedded version, I don't think it works for non-java use case.
There are a lot of platform specific solutions (neo4j, networkx, Core Data, etc) but I'm not aware of a generalized solution. I would like to know this too, because I'm often constrained to certain languages/platforms but would like to use something like neo4j.
If you are using NodeJS then http://github.com/amark/gun might do the trick. Embedded graph database with realtime push notifications. Properties are just regular ol'JSON.
Does anyone have recommendations on a constant DB optimized for sequential integer keys? Running LZ4 over things is cool, but using delta encoding or more clever schemes, you can work right on the compressed key data. (And even more fun if the value is also just a restricted set of integers, like an inverted index.)
also add lmdb/boltdb to that list. there seems to be a convergence around a certain feature-set for embeddable key/value stores: MVCC semantics and ordered keys.
Just to be clear, does embeddable have a specific meaning here? I'm a firmware developer, often writing code for small CPUs and microcontrollers. Does this apply? It seems like here "embeddable" means it can be compiled into an app, as opposed to getting accessed through a server. Is that correct? Thank you.
I believe embeddable is referring to the definition you inferred - that is, you can compile it into your application rather than running it as a separate service.
@pmwkee:
http://sphia.org/pv12.html doesn't tell us the scaling characteristics. The cited performance page is DB at steady state of 6.0M keys. how does it behave under dynamic load? Various scenarios to help your potential users determine if the software is a good fit for their use-case, would be helpful.
Glanced at the code and the arch doc. Looks promising and shows careful crafting. Well done!
Cool! I was looking for a simple key-value alternative for SQLite3 and was going to use redislite[1]. But this is perfect, I think it has the potential to replace SQLite3.
SQLite4 is being designed as a key-value alternative to SQLite3[1]. SQLite3 and SQLite4 are meant for different use-cases and are expected to co-exist. Unfortunately, SQLite4 hasn't yet been released, but wanted to let you know that the SQLite developers are actively working on addressing the need for an embedded key-value store with SQLite4.
BerkleyDB is now AGPL3[0], which some projects have a problem with. (Of course, you can buy a commercial license. Some projects have a problem with that too).
But the main reason, almost regardless of context, as to "why not BerkleyDB" is LMDB[1]. It works way better than everything else, in just about every practical use that has more reads than writes.
The only downside as far as I can tell, is that right now it relies on memory mapping the entire database, so you're limited to ~1GB overall database size on 32 bit systems. There is no practical limit on 64 bit systems. Also, I recall Howard Chu (main LMDB developer) mentioned that in the near future LMDB will gain the ability to manage memory manually - thus removing this restriction as well (for a performance price if used this way).
BerkeleyDB is awesome, but its license may not be suitable for many organizations. Also, the different design would probably result in different behaviors under different scenarios. It seems like Sophia is optimized for inserts.
[+] [-] NhanH|11 years ago|reply
[+] [-] RussianCow|11 years ago|reply
[+] [-] marknadal|11 years ago|reply
[+] [-] mdcox|11 years ago|reply
[+] [-] sophacles|11 years ago|reply
[+] [-] taterbase|11 years ago|reply
[+] [-] fasteo|11 years ago|reply
[1] http://www.tarantool.org
[+] [-] slapresta|11 years ago|reply
[+] [-] vbit|11 years ago|reply
[+] [-] MichaelGG|11 years ago|reply
[+] [-] hyc_symas|11 years ago|reply
[+] [-] gfodor|11 years ago|reply
[+] [-] donpdonp|11 years ago|reply
[+] [-] retrodict|11 years ago|reply
[+] [-] jonatanheyman|11 years ago|reply
[+] [-] diydsp|11 years ago|reply
[+] [-] ximus|11 years ago|reply
Yes
whether or not it is a good fit for small CPUs and microcontrollers is another characteristic that I can't comment on.
[+] [-] notduncansmith|11 years ago|reply
[+] [-] vezzy-fnord|11 years ago|reply
[+] [-] eternalban|11 years ago|reply
Glanced at the code and the arch doc. Looks promising and shows careful crafting. Well done!
[+] [-] johncmouser|11 years ago|reply
[1]https://github.com/seppo0010/redislite
[+] [-] otoburb|11 years ago|reply
[1] https://sqlite.org/src4/doc/trunk/www/design.wiki
[+] [-] aswanson|11 years ago|reply
What's not to like...
[+] [-] virmundi|11 years ago|reply
[+] [-] beagle3|11 years ago|reply
BerkleyDB is now AGPL3[0], which some projects have a problem with. (Of course, you can buy a commercial license. Some projects have a problem with that too).
But the main reason, almost regardless of context, as to "why not BerkleyDB" is LMDB[1]. It works way better than everything else, in just about every practical use that has more reads than writes.
The only downside as far as I can tell, is that right now it relies on memory mapping the entire database, so you're limited to ~1GB overall database size on 32 bit systems. There is no practical limit on 64 bit systems. Also, I recall Howard Chu (main LMDB developer) mentioned that in the near future LMDB will gain the ability to manage memory manually - thus removing this restriction as well (for a performance price if used this way).
[0] http://www.oracle.com/technetwork/database/database-technolo...
[1] http://symas.com/mdb/
[+] [-] pron|11 years ago|reply
[+] [-] halayli|11 years ago|reply
[+] [-] tremols|11 years ago|reply
[+] [-] halayli|11 years ago|reply
[+] [-] raghavsethi|11 years ago|reply
[+] [-] skeoh|11 years ago|reply