4 ms·

Naturally, Hypertable and HBase, two of the more prominent and technologically advanced solutions aren't even included in this article.

• vicaya 17y ago
  He probably equates NoSQL to KV stores that has no chance of having SQL implemented, as they have no efficient range scan capabilities. It's totally feasible to have full SQL (and more) implementation on top over Hypertable.
  • jbellis 17y ago
    > It's totally feasible to have full SQL (and more) implementation on top over Hypertable. Except that would be ridiculous, since the data model is just not designed for denormalization. (And that's okay!)
    • vicaya 17y ago
      Denormalization can happen automatically based on the usage of queries with joins. Some commercial RDBMS like DB2 already do that. SQL is a declarative language. It doesn't force you to use a particular implementation.
      • jbellis 17y ago
        That doesn't make it a good idea. :) It's such a bad fit because your keys will be spread across other nodes in the cluster. Even appengine datastore, which doesn't go nearly all the way towards full sql and still emphasizes denormalization, has latency commonly in 100s of ms.
        • vicaya 17y ago
          You're guessing the implementation here. It's only a bad idea if you're doing it wrong :) The source/conceptual tables can be normalized, while the join views can be materialized/implemented with Bigtable like sparse columns, which are dynamically updated if the joins happen a lot. Any subsequent join queries hits the views but the source tables. Manual denormalization should be allowed but not required. GAE has nothing to do with this, it's a shared cluster, such that any benchmark is not reliable and comparable. It also has nothing to do with the SQL discussion, as it doesn't support joins either.