4 ms·

I don't think that's something they are trying to solve right now. Although HBase guarantees write consistency, I think http://research.google.com/pubs/pub36726

I don't think that's something they are trying to solve right now. Although HBase guarantees write consistency, I think http://research.google.com/pubs/pub36726.html http://research.google.com/pubs/pub36726.html is the closest paper on how to go about it, but I could be wrong. Like you mentioned, a lot of people use HBase as a data-store, it's incredibly good at that.

duaneb 13y ago
> Like you mentioned, a lot of people use HBase as a data-store, it's incredibly good at that. This is exactly what confuses me about NoSQL. It's not really comparable to relational databases on the CA[P] spectrum.
- monstrado 13y ago
  HBase doesn't claim to be some NoSQL database or equivalent to a relational database, anyone who thinks otherwise hasn't actually read into HBase. Just look at HBase's website which describe it exactly as > Apache HBase is the Hadoop database, a distributed, scalable, big data store.
  - duaneb 13y ago
    I mean, I understand this, but plenty of people identify it as NoSQL. I'm sure the people on HBase are intelligent enough to understand it's a meaningless phrase that would make them look silly. EDIT: By which I mean, "NoSQL" doesn't even make sense as an approach by name. ACID relational databases and high availability data stores both have their places so evangelizing on either side is just silly. Though I would like to point people toward http://research.google.com/pubs/pub38125.html http://research.google.com/pubs/pub38125.html.
    - monstrado 13y ago
      True, but there's no way to avoid people interpreting NoSQL as a relational database alternative. To your point regarding Google's F1, try looking at Impala (https://github.com/cloudera/impala https://github.com/cloudera/impala)...
      - duaneb 13y ago
        It's quite interesting to compare the two approaches, thanks for the tip. I mentioned it not because of the SQL but because of its unusual construction: it's a relational database stored on top of a (admittedly ACID) NoSQL (it actually does have a sql engine) key-value store: it's a full-blown relational database system where you don't have to worry about sharding. I think Impala also has a great approach to this, but I'd say it's far more similar to Dremel in that it's structurally still Key-Value. This, again, could be good or bad: probably easier to develop with but harder for the query planner to plan without the hints provided by a table-and-index based system. (i.e. possible—that would basically be F1—but you'd have to do it by hand).

duaneb 13y ago

> Like you mentioned, a lot of people use HBase as a data-store, it's incredibly good at that. This is exactly what confuses me about NoSQL. It's not really comparable to relational databases on the CA[P] spectrum.

monstrado 13y ago
HBase doesn't claim to be some NoSQL database or equivalent to a relational database, anyone who thinks otherwise hasn't actually read into HBase. Just look at HBase's website which describe it exactly as > Apache HBase is the Hadoop database, a distributed, scalable, big data store.
- duaneb 13y ago
  I mean, I understand this, but plenty of people identify it as NoSQL. I'm sure the people on HBase are intelligent enough to understand it's a meaningless phrase that would make them look silly. EDIT: By which I mean, "NoSQL" doesn't even make sense as an approach by name. ACID relational databases and high availability data stores both have their places so evangelizing on either side is just silly. Though I would like to point people toward http://research.google.com/pubs/pub38125.html http://research.google.com/pubs/pub38125.html.
  - monstrado 13y ago
    True, but there's no way to avoid people interpreting NoSQL as a relational database alternative. To your point regarding Google's F1, try looking at Impala (https://github.com/cloudera/impala https://github.com/cloudera/impala)...
    - duaneb 13y ago
      It's quite interesting to compare the two approaches, thanks for the tip. I mentioned it not because of the SQL but because of its unusual construction: it's a relational database stored on top of a (admittedly ACID) NoSQL (it actually does have a sql engine) key-value store: it's a full-blown relational database system where you don't have to worry about sharding. I think Impala also has a great approach to this, but I'd say it's far more similar to Dremel in that it's structurally still Key-Value. This, again, could be good or bad: probably easier to develop with but harder for the query planner to plan without the hints provided by a table-and-index based system. (i.e. possible—that would basically be F1—but you'd have to do it by hand).