Evaluating key-value and document stores for short read data(bcbio.wordpress.com)
bcbio.wordpress.com
Evaluating key-value and document stores for short read data
http://bcbio.wordpress.com/2009/05/10/evaluating-key-value-and-document-stores-for-short-read-data/
6 comments
It was probably compressed, hence the size load/time tradeoff.
Yes, that's right. For the test I ran the tyrant server with:
ttserver test.tcb#opts=ld#bnum=1000000#lcnum=10000
d specifies a deflate encoding. The type of database may also make a difference on loading times; in this case it was a B+ tree.
ttserver test.tcb#opts=ld#bnum=1000000#lcnum=10000
d specifies a deflate encoding. The type of database may also make a difference on loading times; in this case it was a B+ tree.
i dont get it why does each datastore needs a tyrant process running. anyway...
OTOH, he can do that in any rdbms because he does not have large number of simultenous users.
OTOH, he can do that in any rdbms because he does not have large number of simultenous users.
There I was brainstorming ideas to replicate the hierarchical database/collection/document management that MongoDB and CouchDB offer. One solution I have used, and became disenchanted with, was combined keys with all this information munged together. It would be interesting to hear what others do with their key/value stores.
Edit: He notes in the comments that a switch to pytc (direct Tokyo Cabinet bindings rather than going through Tyrant) would improve things, but that he wanted to keep it distributed. I'd still like to see where the bottlenecks are, though.