3 ms·

Hypertable vs. HBase Performance Evaluation

12 points by coderdude 16y ago

ghshephard 16y ago
It's starts off fairly passive agressive, but then things get a little cranky right here: "Hey Doug: Please undo your purchase of the hbase adword. There are plenty of open forums for disseminating your message and on which hbasers can respond should they wish but your purchase of the hbase adword leaves us only one response and thats to outbid you. The only winner in that game will be google." I really don't understand why some people persist in engaging in language/platform wars; particularly professionals operating at this level. Who really cares if one product is running on top of a JVM and the other is compiled machine code - isn't the real issue the performance, reliability and features?
- coderdude 16y ago
  I'm quite surprised that he even bothered to say something to Doug about that, let alone publicly as HBase is not for profit and there is no trademark on HBase (please correct me if I'm wrong). Seems a little childish to me. I will say this though, Doug comes off as having HBase envy and now that he created Hypertable, Inc. I don't want to lend as much trust to his analysis of HBase.
eclark 16y ago
This was from a LONG time ago. There have been a LOT of changes in the hbase code. See the release of 0.9.0
- beagle3 16y ago
  Do you know of any recent comparison of hbase vs. hypertable?
ehsanul 16y ago
These results demonstrate that implementation language matters, and that C++ delivers a significant performance advantage. What a strange thing to say, given that it's probably very likely that the implementations probably work pretty differently internally. You'd probably see similar differences with such a different implementation no matter the language, assuming it isn't something ridiculous like Ruby (I'm a Ruby programmer, don't bite). Secondly, isn't the overhead for a database mostly disk IO? I realize a finely tuned DB/server is probably CPU-bound instead, but that's generally assuming that the working set fits snugly into RAM and gets cached. Which may not quite be the case when you operate the scale at which you'd resort to HBase/HyperTable.

12 points by coderdude 16y ago

It's starts off fairly passive agressive, but then things get a little cranky right here: "Hey Doug: Please undo your purchase of the hbase adword. There are plenty of open forums for disseminating your message and on which hbasers can respond should they wish but your purchase of the hbase adword leaves us only one response and thats to outbid you. The only winner in that game will be google." I really don't understand why some people persist in engaging in language/platform wars; particularly professionals operating at this level. Who really cares if one product is running on top of a JVM and the other is compiled machine code - isn't the real issue the performance, reliability and features?

coderdude 16y ago
I'm quite surprised that he even bothered to say something to Doug about that, let alone publicly as HBase is not for profit and there is no trademark on HBase (please correct me if I'm wrong). Seems a little childish to me. I will say this though, Doug comes off as having HBase envy and now that he created Hypertable, Inc. I don't want to lend as much trust to his analysis of HBase.

eclark 16y ago

This was from a LONG time ago. There have been a LOT of changes in the hbase code. See the release of 0.9.0

beagle3 16y ago
Do you know of any recent comparison of hbase vs. hypertable?

ehsanul 16y ago

These results demonstrate that implementation language matters, and that C++ delivers a significant performance advantage. What a strange thing to say, given that it's probably very likely that the implementations probably work pretty differently internally. You'd probably see similar differences with such a different implementation no matter the language, assuming it isn't something ridiculous like Ruby (I'm a Ruby programmer, don't bite). Secondly, isn't the overhead for a database mostly disk IO? I realize a finely tuned DB/server is probably CPU-bound instead, but that's generally assuming that the working set fits snugly into RAM and gets cached. Which may not quite be the case when you operate the scale at which you'd resort to HBase/HyperTable.