4 ms·

the real irony is that RDBMS are all built on fast k:v stores :)

by liveoneggs 7y ago

HelloNurse 7y ago
The real point is that you don't want to reimplement a poor, ad-hoc RDBMS inside your application.
posix_me_less 7y ago
What do you mean, a filesystem?
- bjornagoransson 7y ago
  I think it's a reference to RocksDB, and maybe also InnoDB
- vidarh 7y ago
  Pretty much all RDBMSs can be considered a set of key-value collections, and their storage backends often conceptually are pretty much that. Assuming a row-oriented storage engine, a simple approach is: * A main key/value collection consisting of primary key (key) mapping to a serialization of the row (value) * One key/value collection per index consisting of each index function applied to the row (key) mapping to the primary key (or some internal object id; the value) It's a bit of a simplification as an RDBMS needs to maintain a sort-order and allow e.g. range queries, and need interfaces that allow reading/writing lots of rows with low per-row overhead, and so it's not that they'd be a good match for just any key-value store.
bottled_poe 7y ago
I’m not sure what you mean? Aren’t most databases built on assumptions of continuous disk space mapped by indexed arrays? How does k:v fit into the picture?
- marcosdumay 7y ago
  The most common high-level use of a DBMS is the pair "given this key, get me the record that is its value" and "store this record under a new key". It's not exactly equal to the usual k:v usage (because it uses meaningless keys), but it's very similar. That said, I don't think this is the usage scenario most DBMS are optimized for, because despite being common, it's a very fast case, so there is relatively little to gain. At the same time, this is the only usage of k:v storage, so you bet it's optimized for that.
hodgesrm 7y ago
> the real irony is that RDBMS are all built on fast k:v stores :) Not if the RDBMS is a column store. Or if the storage model is based on log-structured merge trees. There are many ways to map the relational model to storage. Even for the traditional row-oriented case in InnoDB there are structures like B+-tree indexes that do not directly correspond to a K:V store.

the real irony is that RDBMS are all built on fast k:v stores :)

HelloNurse 7y ago

The real point is that you don't want to reimplement a poor, ad-hoc RDBMS inside your application.

posix_me_less 7y ago

What do you mean, a filesystem?

bjornagoransson 7y ago
I think it's a reference to RocksDB, and maybe also InnoDB
vidarh 7y ago
Pretty much all RDBMSs can be considered a set of key-value collections, and their storage backends often conceptually are pretty much that. Assuming a row-oriented storage engine, a simple approach is: * A main key/value collection consisting of primary key (key) mapping to a serialization of the row (value) * One key/value collection per index consisting of each index function applied to the row (key) mapping to the primary key (or some internal object id; the value) It's a bit of a simplification as an RDBMS needs to maintain a sort-order and allow e.g. range queries, and need interfaces that allow reading/writing lots of rows with low per-row overhead, and so it's not that they'd be a good match for just any key-value store.

bottled_poe 7y ago

I’m not sure what you mean? Aren’t most databases built on assumptions of continuous disk space mapped by indexed arrays? How does k:v fit into the picture?

marcosdumay 7y ago
The most common high-level use of a DBMS is the pair "given this key, get me the record that is its value" and "store this record under a new key". It's not exactly equal to the usual k:v usage (because it uses meaningless keys), but it's very similar. That said, I don't think this is the usage scenario most DBMS are optimized for, because despite being common, it's a very fast case, so there is relatively little to gain. At the same time, this is the only usage of k:v storage, so you bet it's optimized for that.

hodgesrm 7y ago

> the real irony is that RDBMS are all built on fast k:v stores :) Not if the RDBMS is a column store. Or if the storage model is based on log-structured merge trees. There are many ways to map the relational model to storage. Even for the traditional row-oriented case in InnoDB there are structures like B+-tree indexes that do not directly correspond to a K:V store.