Re:My Thoughts on NoSQL
by Maro on Tuesday July 21, 2009 @01:03PM
(#716519)
He mentions Tokyo as a successor to BDB, but I'm not sure in what respects that is true. I've used BDB in Keyspace and looked at Tokyo as an alternative, and they're not at all equivalent. BDB has tons more features than Tokyo. For example, concurrency in Tokyo is limited to one writer and many readers, which is equivalent to the so-called Concurrent Data Store (CDS) in BDB, but BDB also has a Transactional Data Store. Roughly, Tokyo and BDB's CDS use a global lock per db, where the TDS is more like a real database with finer-grained locks (and it's ACID). Also, the level of documentation is ~100:1 in favor of BDB. Nevertheless, I have many gripes with BDB which I'll write down some day soon.
He mentions Redis, but fails to mention the biggest limitation, which is that the entire dataset must fit into memory. To be fair, Redis seems to hit a sweetspot in terms of user-requirements --- lots of cases where data fits into memory. But I still wouldn't recommend it to a client, because what if his data storage needs grow? A few GBs are easily filled up, esp. if you're a web programmer and liberal about what you store.
CouchDB is mentioned. Having seen a recent video of Damien Katz where he describes how CouchDB came along, I feel it's more of an "MS Access for Web2.0", which is no surprise given DK worked on Lotus Notes. It's a lightweight integrated app+db server for Javascript programmers. It's not meant to be used at a Facebook scale operation.
This article, mentioning all these KV-stores together without differentiating them is really confusing and adds to the general melting pot of "NoSQL", which is unfortunate.
He mentions Redis, but fails to mention the biggest limitation, which is that the entire dataset must fit into memory. To be fair, Redis seems to hit a sweetspot in terms of user-requirements --- lots of cases where data fits into memory. But I still wouldn't recommend it to a client, because what if his data storage needs grow? A few GBs are easily filled up, esp. if you're a web programmer and liberal about what you store.
CouchDB is mentioned. Having seen a recent video of Damien Katz where he describes how CouchDB came along, I feel it's more of an "MS Access for Web2.0", which is no surprise given DK worked on Lotus Notes. It's a lightweight integrated app+db server for Javascript programmers. It's not meant to be used at a Facebook scale operation.
This article, mentioning all these KV-stores together without differentiating them is really confusing and adds to the general melting pot of "NoSQL", which is unfortunate.