3 ms·

It's not that they aren't ready for prime-time necessarily. Technologies like memcached are great compliments to any RDBMS-backed website. For a little theory

by mdasen 18y ago

It's not that they aren't ready for prime-time necessarily. Technologies like memcached are great compliments to any RDBMS-backed website. For a little theory: an RDBMS will store data and allow you to query it. So, when you say, get me article #15, it scans through its index in approx. log(n) time and finds the row you're looking for, fetches the row and gives it back to you. Memcached, on the other hand, will do hash(#15), grab that row. That's all done in O(1) time and so it's a lot more scalable. However, with an RDBMS you can say something like, "get me the articles written in the past month" and you can't do that with memcached. Memcached allows key lookups only. A lot of it is a tradeoff between scalability and convenience and using the right tool for the job.

gaius 18y ago
Check out Oracle Coherence.
Retric 18y ago
RDBMS and Memchash work well together. Using the RDBMS as an index lets you keep the whole thing in RAM, and then store your data in Memchash. You can store a lot of useful information into 1kb or less records and then store 1+ million records per GB in RAM.
neilc 18y ago
O(log n) tree search vs. O(1) hash lookup is not the reason for any scalability differences that might exist between RDBMS and key-value stores. RDBMSs with hash indexes are commonplace, and allow O(1) lookups and a b+-tree lookup over a few million rows only does a few I/Os (the fanout in a typical disk-based tree index is on the order of 100, and the nodes in the first level or two of the tree are likely to be cached). Any differences in scalability has more to do with architectural differences (easier to do horizontal partitioning with key-value stores, no need/expectation of ACID transactions, no need to parse + optimize queries at runtime, no need for a complex query executor, etc.) But I agree that a SQL RDBMS allows much more flexible ad-hoc queries than a key-value store does.

by mdasen 18y ago

gaius 18y ago

Check out Oracle Coherence.

Retric 18y ago

RDBMS and Memchash work well together. Using the RDBMS as an index lets you keep the whole thing in RAM, and then store your data in Memchash. You can store a lot of useful information into 1kb or less records and then store 1+ million records per GB in RAM.

neilc 18y ago

O(log n) tree search vs. O(1) hash lookup is not the reason for any scalability differences that might exist between RDBMS and key-value stores. RDBMSs with hash indexes are commonplace, and allow O(1) lookups and a b+-tree lookup over a few million rows only does a few I/Os (the fanout in a typical disk-based tree index is on the order of 100, and the nodes in the first level or two of the tree are likely to be cached). Any differences in scalability has more to do with architectural differences (easier to do horizontal partitioning with key-value stores, no need/expectation of ACID transactions, no need to parse + optimize queries at runtime, no need for a complex query executor, etc.) But I agree that a SQL RDBMS allows much more flexible ad-hoc queries than a key-value store does.