Apache HBase vs. DataStax Enterprise

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

Real-time transaction processing (both reads and writes) is where DataStax Enterprise shines. It's very fast with linear scalability should more resources be needed. Additional nodes are added very easily. DataStax Enterprise on its own (without Solr or Spark enabled) isn't well suited for long complicated reports. The data model doesn't support joining multiple tables together which is common in BI reporting.

• 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

• Datastax Cassandra provides high availability and good performance for a database. It is built on top of open source Apache Cassandra so you can always somewhat understand the internal functioning and why.
• Datastax Cassandra is fairly simple to start using, you can install/setup your cluster and be productive in 1 day.
• Datastax Cassandra provides a lot of good detailed documentation, and when starting, the detailed free videos on the Datastax site and documentation are very helpful.
• Datastax Enterprise Edition of Cassandra provides more tools, good support, and quick response SLA for enterprise business support.

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

• Cassandra is a bit difficult to learn and understand
• The costs are slightly higher for our company
• Hardware requirement is moderate to high at the beginning

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

We will continue to use it because it scales well with commodity hardware and we are satisfied with the documentation and support.

Incentivized

There is a bit of a learning curve and tasks that are simple in traditional RDBMS systems can be complicated with DataStax Enterprise but once you get the hang of denormalizing data and getting the data model correct DataStax Enterprise is very usable. Usability from the developer's standpoint is very simple - the complication is on the architecture side with the data model.

DataStax has the best community. They have instant customer support to solve problems and are knowledgeable of the problems faced by the customer. The documentation is pretty top-notch.

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

DataStax Enterprise offered best-in-class write performance and scalability. The customer support team was very helpful in the adoption of new technology.

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

• Highly Scalable Database, Highly Available Services, and Platforms.
• High Performance, Low Latency and Highest throughput across varying workloads.
• Configured, Tuned and Monitored correctly works to provide the best user experience!
• Negative: Maintenance and Debugging Corner Cases

Incentivized