Apache HBase vs. Google Cloud BigTable

Hbase is well suited for large organizations with millions of operations performing on tables, real-time lookup of records in a table, range queries, random reads and writes and online analytics operations. Hbase cannot be replaced for traditional databases as it cannot support all the features, CPU and memory intensive. Observed increased latency when using with MapReduce job joins.

Incentivized

Google Bigtable is ONLY suited for massive data sets which scale PetaBytes and TerraBytes. Anything under this can easily be done via dedicated VMs and open source tools. Google Bigtable is expensive and shall be used wisely. It should be utilised only where it is well suited else you would simply be wasting dollars and not utilizing its full benefits.

Incentivized

• Scalability. HBase can scale to trillions of records.
• Fast. HBase is extremely fast to scan values or retrieve individual records by key.
• HBase can be accessed by standard SQL via Apache Phoenix.
• Integrated. I can easily store and retrieve data from HBase using Apache Spark.
• It is easy to set up DR and backups.
• Ingest. It is easy to ingest data into HBase via shell, Java, Apache NiFi, Storm, Spark, Flink, Python and other means.

Incentivized

• Analytics: is at Google's heart. No on can beat Google in this space and BigTable is one of its implementation of this. The insights you gain from BigTable are simply usable in your day to day activities and can help you make real difference.
• Speed: Processing TBs and PBs of data under minutes needs real efficient platform which is capable of doing much more than just processing data. All this data cannot be processed by a single machine, but rather huge pairs of machines working in conjuction with each other. BigTable's implementation is one of the finest and allows you achieve great speeds!
• Interface: is great. Google has segregated required task under logically placed buttons which takes no time by users to understand and get habituated.

Incentivized

• There are very few commands in HBase.
• Stored procedures functionality is not available so it should be implemented.
• HBase is CPU and Memory intensive with large sequential input or output access while as Map Reduce jobs are primarily input or output bound with fixed memory. HBase integrated with Map-reduce jobs will result in random latencies.

Incentivized

• User interface's responsiveness: I understand so much is going on under the hood, but laggyness is acceptable if a workload is running or being processed. In case their is not workload being process, GUI should work blazing fast. I have faced this at times, and this becomes frustrating as well.
• Nothing other than this - BigTable is quite efficient platform and does exactly what it is built for.

Incentivized

There's really not anything else out there that I've seen comparable for my use cases. HBase has never proven me wrong. Some companies align their whole business on HBase and are moving all of their infrastructure from other database engines to HBase. It's also open source and has a very collaborative community.

Incentivized

For big IT firms like us, data is very important and it only holds its value if it can make sense to us. Therefore, Bigtable's usability is priceless when it comes to decision making based on data.

Incentivized

Google provides premium support services for BigTable which is absolutely blazing fast similar to Bigtable's performance.

Incentivized

Cassandra os great for writes. But with large datasets, depending, not as great as HBASE. Cassandra does support parquet now. HBase still performance issues. Cassandra has use cases of being used as time series. HBase, it fails miserably. GeoSpatial data, Hbase does work to an extent. HA between the two are almost the same.

Incentivized

• As Hbase is a noSql database, here we don't have transaction support and we cannot do many operations on the data.
• Not having the feature of primary or a composite primary key is an issue as the architecture to be defined cannot be the same legacy type. Also the transaction concept is not applicable here.
• The way data is printed on console is not so user-friendly. So we had to use some abstraction over HBase (eg apache phoenix) which means there is one new component to handle.

Incentivized

• Positive return on investment.

Incentivized