HBase @ WorldLingo - Get more Information Technology
The second talk given was by Jan Lehnardt, a CouchDB team member. I am looking into Erlang for the last few months to see how we could use it for our own efforts. CouchDB is one of the projects you come across when reading articles about Erlang. So it was really great to have Jan present too.
At the end of both our talks it was great to see how the questions from the audience at times tried to compare the two. So is HBase better or worse than CouchDB. Of course, you cannot compare them directly. While they share common features (well, they store data, right?) they are made to solve different problems. CouchDB is offering a schema free storage with build in replication, which can even be used to create offline clients that sync their changes with another site when they have connectivity again. One of the features puzzling me most is the ability to use it to serve your own applications to the world. You create the pages and scripts you need and push it into the database using CouchApp. Since the database already has a built-in web server it can handle your applications requirements implicitly. Nice!
I asked Jan if he had concerns about scaling this, or if it wouldn't be better to use Apache or Nginx to serve the static content. His argument was that Erlang can handle many many more concurrent request than Apache can for example. I read up on Yaws and saw his point. So I guess it is a question then of memory and CPU requirements. The former is apparently another strength of CouchDB, which has proven to serve thousands of concurrent requests only needed about 10MB of RAM - how awesome is that?!?! I am not sure about CPU then - but take a gander that it is equally sane.
Another Erlang project I am interested in is Dynomite, a Erlang based Amazon Dynamo "clone" (or rather implementation). Talking to Cliff it seems it is as awesome leveraging the Erlang OTP abilities to create something that a normal Java developer and their JRE is just not used to.
And that brings me to HBase. I told the crowd in Berlin that as of version 0.18.0 HBase is ready for anyone to get started with - given they read the Wiki to set the file handles right and a few other bits in pieces.
Note: I was actually thinking about suggesting an improvement to the HBase team to have a command line check that can be invoked separately or is called when "start-hbase.sh" is called that checks a few of these common parameters and prints out warnings to the user. I know that the file handle count is printed out in the log files, but for a newbie this is a bit too deep down. What could be checked? First of the file handles being say 32K. The next thing is newer resource limits that were introduced with Hadoop for example that now need tweaking. An example is the "xciever" (sic) value. This again is documented in the Wiki, but who reads it, right? Another common issue is RAM. If the master knows the number of regions (or while it is scanning the META to determine it) it could warn if the JRE is not given enough memory. Sure, there are no hard boundaries, but better to see a Warning: Found x regions. Your configured memory for the JRE seems too low for the system to run stable.
Back to HBase. I also told the audience that as of HBase 0.19.0 the scanning was much improved speed wise and that I am happy where we are nowadays in terms of stability and speed. Sure, it could be faster for random reads so I may be able to drop my MemCached layer. And the team is working on that. So, here's hoping that we will see the best HBase ever in the upcoming version. I for myself am 100% sure that the HBase guys can deliver - they have done so in the past and will now as well. All I can say - give it a shot!
So, CouchDB is lean and mean while HBase is a resource hog from my experience. But it is also built to scale to Petabyte size data. With CouchDB, you would have to add sharding on top of it including all the issues that come with it, for example rebalancing, fail-over, recovery, adding more servers and so on. For me HBase is the system of choice - for this particular problem. That does not mean I could use CouchDB, or even Erlang for that matter, in a separate area. Until then I will keep my eyes very close in this exciting (though in case of Erlang not new!) technology. May the open-source projects are rule and live long and prosper!
Posts
I'm still digging into CouchDB but as I understand it handles clustering for you.
ReplyDeleteOne 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.
Hi p7a,
ReplyDeleteCouchDB 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?
Thanks Lars,
ReplyDeleteThat 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,
ReplyDeleteI 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?
Hi,
ReplyDeleteI 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