Comments on Lineland: HBase vs. CouchDB in Berlin

Hi, I am struggling with the difference between s...

2010-05-27T12:27:15.764-07:00

Hi,

I am struggling with the difference between several systems. I am trying to get a grasp on the storage of CouchDB (document-oriented), C-Store (column-oriented), and HBase (which says it is row and column but, in the end is a stoage map array)

Thanks

Hi, I really struggled with HBase because of my R...

2010-03-07T22:16:22.436-08:00

Hi,

I really struggled with HBase because of my RDBMS & SQL background and finally I found an analogy between the two: One should think that He can only write an SQL Query to an HBase table such that he can only "filter" for a unique ROW_ID...

Meaning that the only valid pseudo-SQL query for an HBase table is like this one:
"select col1, col2 from hbasetable where row_id = 1";
You can not specify anything other than row_id in WHERE part of your SQL query...

What do you think of my argument? Is it valid?

Thanks Lars, That does explain a lot. RE: CouchD...

2009-04-24T06:54:00.000-07:00

Thanks Lars,

That does explain a lot.

RE: CouchDB clustering, I suppose you could stick a load balancer in front of a number of CouchDB nodes to achieve some form of clustering? Since it's REST based, this should be trivial. But, I get your point that this isn't suitable for certain use cases. (Adding nodes won't give you more storage space, for example.)

On HBase... I'm more interested in doing a 'join' between two tables, so the lookup table solution would work. I could also have a M/R job that would create the lookup tables from scratch.

Hi p7a, CouchDB handles replication for you, but ...

2009-04-23T23:34:00.000-07:00

Hi p7a,

CouchDB handles replication for you, but not the clustering. So you can replicate across many machines that run independently of each other or in remote locations. But it does not form a scalable cluster as I would define it. HBase is a cluster of machines that act as one system. As you add more machines to it it scales to handle more storage and load needs. It implicitly handles splitting the data into regions and distributing them across the whole cluster. That is the part that CouchDB - as of now - does not do. You would have to put a layer on top to shard the data into many replicated instances. Then you are facing the same issues scaling a conventional relational database.

HBase's secondary indexes are an add-on that is - again, as of now - not the fastest as it relies on another addition called Transactional HBase. The thing with HBase is to not think of it as a database with many ways to find data quickly. It is more like a Java ArrayList where you have to iterate over it to process each entry or ask for one entry by its key.

If you need the secondary indexes you can either design this into your code by filling extra look-up tables with the data you need (although you still get no wild card matches etc.) or use Lucene for example to generate a searchable index that you can query any way you like.

While there are common markers between CouchDB and HBase they do fit different needs and there is less of a functional overlap as there is when it comes to general functionality they provide, i.e. storing data.

Does that help explaining it a bit better?

I'm still digging into CouchDB but as I understand...

2009-04-23T08:33:00.000-07:00

I'm still digging into CouchDB but as I understand it handles clustering for you.

One thing I really liked about CouchDB is that it incrementally updates the secondary index for you.

HBase 0.19 apparently supports secondary indices, but i can't find enough literature on how it works.

For the moment, you need to declare the secondary index when the column group is created, but apparently the devs are working on a fix for that.