The Apache HBase project's goal is the hosting of very large tables -- billions of rows X millions of columns -- atop clusters of commodity hardware. Apache HBase is an open-source, distributed, versioned, non-relational database modeled after Google's Bigtable.
N/A
Couchbase Server
Score 8.6 out of 10
N/A
Couchbase Server is a cloud-native, distributed database that fuses the strengths of relational databases such as SQL and ACID transactions with JSON flexibility and scale that defines NoSQL. It is available as a service in commercial clouds and supports hybrid and private cloud deployments.
N/A
Riak
Score 10.0 out of 10
N/A
Riak is a NoSQL database from Basho Technologies in Bellevue, Washington.
We looked at several different SQL and NoSQL systems. Most were either too expensive, didn't provide the needed functionality, or were too hard to use with the size of our team. We ultimately went with Couchbase because of its performance, horizontal scalability, and price.
At the time I worked on the project those were the three competing technologies I evaluated. Couchbase didn't have memcache integrated at the time. Riak was by far the easiest to set up, and it's linking capability struck the right balance of having just enough relational …
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.
Best suited when edge devices have interrupted internet connection. And Couchbase provides reliable data transfer. If used for attachment Couchbase has a very poor offering. A hard limit of 20 MB is not okay. They have the best conflict resolution but not so great query language on Couchbase lite.
Highly available: If nodes go offline for any reason, the system still operates.
Highly scalable: There is a minimum of 5 nodes, which can handle a lot by themselves. When scaling is required, it can be done easily, with minimal to no downtime on large scales.
Very fast searching: Riak has SOLR indexing built-into the core product, which makes querying for data very fast.
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.
The N1QL engine performs poorly compared to SQL engines due to the number of interactions needed, so if your use case involves the need for a lot of SQL-like query activity as opposed to the direct fetch of data in the form of a key/value map you may want to consider a RDBMS that has support for json data types so that you can more easily mix the use of relational and non-relational approaches to data access.
You have to be careful when using multiple capabilities (e.g. transactions with Sync Gateway) as you will typically run into problems where one technology may not operate correctly in combination with another.
There are quality problems with some newly released features, so be careful with being an early adopter unless you really need the capability. We somewhat desperately adopted the use of transactions, but went through multiple bughunt cycles with Couchbase working the kinks out.
Deletes!!! We've seen on numerous occasions where Riak has "resurrected" deleted data. We've worked with Basho numerous times and tried multiple changes to the way we interact with Riak to prevent the problem but it still remains. The deletes seem to reappear weeks, even months, after the delete was issued. We've had to work around this issue by providing a "deleted" flag for all data objects stored in Riak. Thus, we do no delete but simply flip the flag. Excess baggage we would really like to not have to worry about.
Search. Currently there's no way to tell what data you have in Riak without already knowing a particular bucket/key. There is a way to list the keys for a given bucket but due to performance implications, this is not a viable method to lookup data. Especially when you have a large amount of keys in the bucket.
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.
I rarely actually use Couchbase Server, I just stay up-to-date with the features that it provides. However, when the need arises for a NoSQL datastore, then I will strongly consider it as an option
Right now, I'm on a project where we need databases that can run on embedded systems. Riak isn't necessarily the best fit for that scenario. But when we need a clustered database, that's where we'd start considering Riak.
Couchbase has been quite a usable for our implementation. We had similar experience with our previous "trial" implementation, however it was short lived.
Couchbase has so far exceeded expectation. Our implementation team is more confident than ever before.
When we are Live for more than 6 months, I'm hoping to enhance this rating.
One of Couchbase’s greatest assets is its performance with large datasets. Properly set up with well-sized clusters, it is also highly reliable and scalable. User management could be better though, and security often feels like an afterthought. Couchbase has improved tremendously since we started using it, so I am sure that these issues will be ironed out.
I haven't had many opportunities to request support, I will look forward to better the rating. We have technical development and integration team who reach out directly to TAM at Couchbase.
Despite Basho going bankrupt and the project becoming fully open-source, community support is reasonably good, albeit a little slow at times. Paid enterprise-grade support is also available from former Basho engineers but the same company also contributes to the community support for free for basic questions or specific knowledge areas.
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.
The Apache Cassandra was one type of product used in our company for a couple of use-cases. The Aerospike is something we [analyzed] not so long time ago as an interesting alternative, due to its performance characteristics. The Oracle Coherence was and is still being used for [the] distributed caching use-case, but it will be replaced eventually by Couchbase. Though each of these products [has] its own strengths and weaknesses, we prefer sticking to Couchbase because of [the] experience we have with this product and because it is cost-effective for our organization.
Because of the RESTful HTTP interface, the consistency model, and because of the catalog-driven data model, Riak was an easy win over Redis and Memcached.
So far, the way that we mange and upgrade our clusters has be very smooth. It works like a dream when we use it in concert with AWS and their EC2 machines. Having access to powerful instances along side the Couchbase interface is amazing and allows us to do rebalances or maintenance without a worry
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.
Riak has been a key part of our company's build process for our client's search backend. It is valuable for is in that it provides a reliable way to view the current search index.
