Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Although it's an old question, I've been looking into this recently and have come across the following (at least two of which were written after this question was asked). I'm not sure how any of these handle very large objects - and at 10GB you would probably have to do some serious testing, as I presume few database developers would have objects of that size in mind for their products (just a guess). I would definitely consider storing them to disk directly, with just a reference to the file location in your database.</p> <p>(Opinions below are all pretty superficial, by the way, as I haven't used them in earnest yet).</p> <hr> <p><a href="http://code.google.com/p/orient/" rel="noreferrer">OrientDB</a> looks like the most mature of the three I found. It appears to be a document and/or graph database and claims to be very fast (making use of and "RB+Tree" data structure - a combination of B+ and Red Black trees). It claims to be super fast and light, with no external dependencies. There seems to be an active community developing it, with lots of commits over the last few days, for example. It's also compliant with <a href="http://tinkerpop.com/" rel="noreferrer">TinkerPop</a> graph database standard, which adds another layer of features (such as the Gremlin graph querying language). It's <a href="http://en.wikipedia.org/wiki/ACID" rel="noreferrer">ACID</a> compliant, has REST and other external APIs and even a web based management app (which presumably could be deployed with your embedded DB, but I'm not sure).</p> <p>The next two fall more into the simple key-value store camp of N(ot)O(nly)SQL world.</p> <p><a href="https://github.com/jankotek/JDBM3" rel="noreferrer">JDBM3</a> is an extremely minimal data store: it has a hash map, tree map, tree set and linked list which are written to disk through memory mapped files. It claims to be very light and fast, is fully transactional and is being actively developed.</p> <p><a href="http://hawtdb.fusesource.org/" rel="noreferrer">HawtDB</a> looks similary very simple and fast - a BTree or Hash based index persisted to disk with memory mapped files. It's (optionally) fully transactional. There has been no commit in the past seven months (to end March 2012) and there's not much activity on the mailing list. That's not to say it's not a good library, but worth mentioning.</p> <p>JDBM3 and HawtDB are pretty minimal, so you're not going to get any fancy GUIs. But I think they both look very attractive for their speed and simplicity.</p> <hr> <p>Those are all I've found matching your requirements. In addition, Neo4J is great - a graph database, which is now a pretty mature and works very well in embedded mode. It's GPL/AGPL licensed, though, so may require a paid license, unless you can open source your code too: <a href="http://neotechnology.com/products/price-list/" rel="noreferrer">http://neotechnology.com/products/price-list/</a></p> <p>Of course, you could also use the <a href="http://www.h2database.com/" rel="noreferrer">H2 SQL database</a> with one big table and no indices!</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload