Hbase Reviews

The best with Hbase is data stored in hadoop cluster. The read is much faster. Data is replicated in clusters. Region Transition upon server failures is faster. Version based storage as defined. RDBMS (MySQL) we use need to maintain version data like history. Defining FamilyName helps grouping set of qualifiers (Columns) in a given row is good to fetch only certain group of columns data. Filters (RowFilter, SingleColumnFilter API) is flexible to fetch data based on requirement by filtering pattern.

SQL like Query language missing in hbase. Like Hive we need Query support. Binary data based storage. Every time in code we need to encrypt / decrypt data into Binary format and store it in DB. Lot of code we need to write.Update record is missing. So, we need to delete and put every-time or we may fetch rowId, version, timestamp to override the value in update.

When you evaluate NoSQL for your organization / product, its worth to evaluate HBase for your requirements.

We are storing huge amount of reporting data from energy utilities and other utilities data into Hbase on a daily / hourly basis and we have Map/Reduce framework to do analyse data from Hbase. We felt Hbase is perfect to work with Hadoop Map/Reduce framework. Reading data from Hbase was really faster and we could read huge data from reporting table where we couldn't read from MySQL. Replication, Scalability, Performance overall for NoSQL Hbase is good.

1.The capacity, storage and processing of bulk data, in such a robust manner.

2.Flexible schema as we can add n numbers of attributes in a column family at run time without declaring them at the time of table creation.

3.Fault tolerance- As we know mapReduce runs internally for all kind of operation, In case of failure scenarios mapper and reducer job handles it.

4.Versioning of records- Default feature for versioning is available. If that is enabled, hbase updates the record and also keeps the old record data.

1.Transaction concept is not applicable.-as its a noSQL database

2.No other primary key can be defined other than the row key.

3-Indexing of row key is a feature by default- but we can not explicitly index any other value, as we can not have any primary key other than row key itself.

Surely, but for NoSQL database

We are storing data from csv into Hbase after making an HFile .. Java implementation of map reduce is done for the same.

Hbase can easily manage, bulk amount of data in an efficient and robust manner.

It is considered to be a powerful NoSQL tool, which helps in data management, and provides an ease in fast retrieval and manipulation of the same.

It is better than traditional file system, because of the efficiency, which it provides for the same amount of system, and major advantage is the use of commodity hardware, to store the data.

Also it is fault tolerant, as it keeps replica of the data stored, so in case of failure, the replica can be used.

Hbase is not recommended for small amount of data, as it will take, some time in processing, making it not very efficient for that.

It has a single point of failure, i.e., HMaster, so if H Master fails, Hbase goes down, and we will not be able to perform any operations, until problem is resolved.

We cannot easily perform joins on Hbase, making it a complex tool to perform basic operations.

For storing bulk datain a tabular manner, I would recommend Hadoop Hbase, but for small amount of data, I personally would not suggest the use of this tool.

We are moving from traditional file system to Hadoop file system, and to store the data in a tabular manner, we are using Hbase. As the data is increasing day by day, the need to manage the same is also required, which is incorporated by Hadoop.

Hadoop Hbase is a fault tolerance No SQL data base, which can be used for analysis.

It makes replica of the data which is loaded, which makes it more reliable.

It has out of box features like, auto - sharding and auto - failover.

It can be integrated with Hadoop Hive, which is also a component of Hadoop, to use SQL like queries.

The major drawback of Hbase is that is does not have transaction support.

We cannot perform joins in Hbase easily, to perform joins we have to either write complex map - reduce code, or integrate with Hadoop Hive.

To store bulk amount of data, I would suggest Hbase. But is the amount of data to be stored is less, then it is not recommended. Also if we do not require transaction support, with huge amount of data, then we can always go for Hbase.

We are using Hbase to store all the data from old file system i.e., traditional file system to Hadoop.

As we are aware that data is growing day by day, so we need better products to store and manage this data, which is easily achievable by Hbase. So we are moving all our data into Hadoop storage in a tabular form in Hbase tables.

Hbase is a noSQL database which can handle, large amount of data easily.

It is also fault tolerance.

The schema of Hbase is also very flexible and at any point of time we can add new columns to the table. Only column families need to be defined initially.

As Hbase is a noSql database, here we don't have transaction support and we cannot do many operations on the data.

In Hbase joins are not supported, we need to connect it ti either hive to do so.

To store, huge volume of data, and if no transaction support is required, then I'd surely recommend this component of Hadoop.

We are storing all the data after converting it to a CSV to Hbase, as the amount of data is increasing day by day, and the traditional storage system cannot suffice the need.

The robustness of the application in terms of capacity, storage and processing of bulk data is the best. Also not having a table schema helps a lot which allows us to have as many columns as possible on the go without defining them. The concept of versioning of the records helps us to compare data properly and also store both the data if required.

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.

Highly recommend if dealing with bulk and variety of data as no schema is required during DDL.

In our business we are using it to store data and metadata of the complete Content Management System of our client.

Best thing is we can store large amount of data in it and related data are stored closely so that can be retrieved quickly. Column family helps me to segregate similar data . So , they can be extracted fastly. it has a very good support from community of hortanworks. So, it is a very good product to handle big data solution.

the way data is printed on console is not so user friendly. So we had to use some abstraction over hbase (eg apache phoenix) so there is one new component to handle.

Hbase can be helpful for few scenarios where you need a lot of data in db and also u want it to be accessed easily on basis of similarity of data. Like personal information are stored close by.

We are using it to store email files directly by bulkloading and then retrieving it using apache phoenix.

Apache hbase helps us to store data by making hfiles and directly uploading those hfiles to region servers.

Instead of having large number of tables in hbase , we are creating a single table for all email types and then in phoenix we are making views on top of that table and firing queries by phoenix.

1) Creating a table with any number of column family names, or any number of columns is easy

2) Map Reduce program helps in loading bulk amount of data in a very short span of time

3) The way we can view the tables and querying the table is very easy as its a NOSQL database

4)It has its own scheduler i.e OOZIE scheduler which is built on yarn user.

5) Kerborization is one big advantage which is supported by HBASE. This ensures the data is secure

6)To maintain the data integrity of data the checksum is used to check corrupted data. This API of HBASE is very helpful

1) The only way to identify the individual records is through the row key, there is no other alternative

2) As it is a NOSQL, joins is not supported when we query for multiple tables

Yes definitely

1) To store the data related to banking services

2) Emails, chats, fax data between customers and the bank are stored in HBASE under different tables

3) The investor profile details, are stored in HBASE

4) The jobs are scheduled using the OOZIE scheduler by cron expressions

5)Used to update the mutation records as well

1) Speed- Hbase helps in running map reduce programs which can load peta bytes of data to Hbase in parallel which speeds our work.

2) NoSQL Database- As Hbase is a noSQL database,we can store data in terms of key-value pairs in list of column families,this helps in quering faster and can have multiple values in a column

3) Storage- Hbase can store both metadata as well as content which reduces multiple resources in use.

4) Oozie Scheduler- Hbase has its own built in oozie scheduler which can schedule jobs using specified cron expression,Oozie has its own UI where in you can see the status of the job and refer to logs as well in case of failures which is very helpful.

4) Hadoop eco system also has distributed file sytem which partitions data among different data nodes which helps in storing huge files. I have used to store hfiles in HDFS and finally load them to Hbase using map reduce program in java.

5)Phoenix which supports sql on Hbase, We are using this to query Hbase which is fastens the scan of tables.

6) we are also using checksum to check for whether the data entered the base is corrupted or not which helps in tracking and reconciliation of data.

1) As Hbase is a noSQL database,quering with joins is not possible.

2) When we map phoenix with Hbase table, we are unable to create a column other than in Hbase and update it, Only vice versa is possible.

3) The restriction of Oozie scheduler which can be run only by yarn users and can pick files only from HDFS.

1) Hbase- NoSql database which helps in storage of big data and even helps in quering.

2) Supports parallel programming using map reduce which fastens our work.

3) Phoenix runs SQL on Hbase which scans faster.

4) Has built in scheduler-oozie

1) Hbase has helped in loading peta bytes of data using map reduce programs in java .We were able to load metadata as well as content to Hbase.

2) We are able to apply retention policy on records by scanning multiple tables using phoenix.

3) We have used Kerborisation to enhance the security of our modules in Hadoop eco system as well.

HBase is a good solution if you are kind of SQL guy and you work in Hadoop ecosystem, and you don't want to write a lot of code to handle the low-level HDFS I/O. HBase is really fast, and can store a very big data with hundreds of columns.

Also, HBase is bundled in Cloudera, and has a very active community of supporters. You can easily find answers for your questions in StackOverflow or elsewhere.

HBase takes many extra hard-disk, because it builds many index for one table. Also, you have to be careful if you want to get the best trade-offs between writing and querying - fine tuning is necessary.

HBase is also too level to support some kind of data schema such as time series. For that, you usually need to install other database on top of it, such as OpenTSDB

If you are just beginning to use Hadoop, and you are looking for something similar to SQL database to work with, HBase is an easy solution. It is built-in in many Hadoop vendor, which makes your life easier setting things up

I need to store my data extracted from raw Web archives to be able to easily query it later, and for my colleagues who are more familiar with SQL to work with. HBase seems to be a proper option, since we have Cloudera in our house anyway.

Hbase can efficiently handle huge amount of data.

It is fault tolerance.

This is an out of box component of Hadoop, so we do not have to purchase it.

The major drawback of Hbase is that we cannot perform joins in it, that is a very basic thing expected in a database.

Here we have single point of failure i.e., Hbase Master, on failure of which the whole hbase stops functioning.

Hbase is highly recommended, if we want to store bulk data and are not expecting to fetch SQL like results. Though nowadays, we have tools coming up which can fetch data from hbase and then we can perform our normal transnational queries.

We are storing all the data from traditional file system to Big data, and storing in Hbase at the end of the day.

High performance overall. Open source nature makes it easy to contribute and review the internals of the project. Also makes it easy for tools adding functionality to be built and integrated on top. Costs nothing. Well supported by PAAS providers such as AWS.

Consistency ensures correct results will be found, though they may take longer.

Can use SQL like language through integration with Apache Hive, allowing users new to NoSQL databases to limit the initial learning curve.

Choice of consistency and partitioning at the expense of availability results in some queries taking longer than necessary.

Ability to use SQL like language can lead users to view it as suitable for traditional relational DB use cases when this is not the case.

If availability is not your number one priority and you are looking for a well established, stable and easy to use NoSQL columnar database this is probably the best option out there. However if heading into the cloud vendors' own solutions (ie AWS' DynamoDB) may be worth examining first.

NoSQL database capable of integrating with Hadoop mapreduce jobs. Partitioning for scalability as the number 1 concern allowing for simple future expansion due to running on top of HDFS.

HBase is part of the Hadoop stack makes it a no brainer for usage if you have a Hadoop cluster setup already. Running on top of your existing HDFS makes for an easy install and use. For most people using Hortonworks, Cloudera or MapR this is part of your default install. HBase works well with Apache Spark as well and makes for a great NOSQL solution for many use cases. It is very well documented and there's tons of articles on uses and tutorials. http://hbase.apache.org/book.html#jvm

It could use a better query language. I would prefer if Phoenix was better integrated with HBase. Also they should include cell level security like Accumulo. Otherwise there's not much to dislike, it fits into the hadoop cluster and is easy to manage with Hue or Ambari.

If you have Hadoop, install it through Ambari or your Hadoop console and give it a try. if you don't have Hadoop, I would say try something else. Try it for some use cases in place of another cache, kv store or NoSQL. If you already have Accumulo or Cassandra, then you probably don't have too many uses for HBase, but some OOTB solutions use it. It doesn't hurt to have it installed as it proves to be a useful utility for many options.

We were using it to quickly access Key-Value type data for front-end applications. Basically a sampling of massive datasets stored in HDFS.

Storing bulk data on Hadoop file system, using NoSQL database. Ease of handling bulk data

As it is a NoSQL tool, we cannot fire normal SQL queries, to fetch data from the same

For loading huge data, I'd recommend, where we are not in a need to do analysis on a daily basis

Loading huge amount of data from CSV into a Hadoop, in a tabular manner.

- build from the ground up with strict consistency in mind, with the flexibility to relax the consistency level on an as-needed basis.

- easy to use shell provides both DML and DDL commands

- Java APIs are easy to use

- table and column family attributes can be customized per the use case

- built in auto-sharding capabilities

- replication is easy to setup and maintain

- native in-memory option

- native row versioning \ history capabilities

- fault-tolerant and self-healing

- plenty of good documentation, resources, blogs, etc

- no known, full-featured, management GUI (stand-alone or web application) seems to exist at this time

- DDL and DML via shell is easy for simple operations, but becomes syntactically awkward for more complex operations

- storing and aggregating hundred of millions time-series data points

- master data management: designing a single source of truth for storing and serving business data to internal and external applications and\or platforms

With HBase, you get what you asked for. HBase is great because it's an open-source, well-known Apache project. As a result, the community and documentation are well-developed -- most likely, any issue you run into will be on StackOverflow.

Unless you're buying into a fully-managed, bare-metal Hadoop environment, I'd say you should first look into what cloud-providers offer in terms of HBase-like, columnar databases. Check out Google Cloud Platform or Amazon Web Services before ever installing HBase from Apache, Cloudera, HortonWorks, etc., and even then, know that cloud instances are expensive. In addition, I'd make sure that a columnar database is even what you need. In most cases, a traditional relational database is probably just fine for your use case, as you'll later find exporting data from HBase or using HBase for a variety of queries is a lot of work.

First consider if you need a columnar database. If you're absolutely sure that the benefits outweigh the price, then look into cloud providers with fully-managed columnar databases.

I've used HBase for both look-ups and time-series data. It's great for when you know what your queries will be, but exporting data, especially for regulatory requirements, was more complex than it needed to be.

Stability and scaleability are the most important features in this software which I like. I deployed it over more than 20 servers it was easy to deploy and add new nodes.

I have a little issue with its rest web service and also zookeeper sometimes crashes but its native clients where great

easy of deployment

I deployed a central database for a big IDS and sensor network it stores more than 10Gbps data every date and lots of other components is connected to it for processing jobs

1. Highly Scalable.

2. Out of the box load balancing.

3. Doing short RangeScans

4. Support for Coprocessors(Server side UDF's)

5. Strong Consistency.

6. Rich set of Filters.

7. Support for storing historical data.

8. Deep Intergration with Hadoop Platform.

9. Huge Community support.

10. Provides cell level security.

HBase needs to integrate with Apache Phoenix OOTB so that users dont need to bother about reading and writing byte[] to and from HBase. OR It should provide high level constructs to read and write columns with DataType(like int, bigdecimal, short, etc..)

Its Documentation website can be improved and made more visual.

Data Modeling is KEY to successful HBase implementation. Make sure you get it right.

Tune HBase as per your workload.

Avoid using HBase for full table scan type of workload.

I have been using HBase for last 4 years. I have used it for two different use cases:

1. To store credit card transaction in HBase at Intuit.

2. To store Images of Cars in HBase at Truecar.com

Here are the benefits:

1. Its strongly consistent.

2. Integrates very well with Hadoop/MapReduce.

3. RangeScan

4. Can be used to store small files in HDFS/Hadoop.

5. Good community support.

6. Support for storing historical data.

Even though we cannot use it as a replacement of RDBMS,it suits number of use cases in Big Data space.In one among the use cases, the number of version for Hbase was kept as 1 (to simulate rdbms feature of maintaining only single version,not the version history of 3(default)) and used the feature Hive Hbase integration to read the Hbase table from Hive.So the application updates the Hbase table,and we used this table in etl flow along with other hive tables.

Note:Even if the version is greater than 1,Hive table which points to the Hbase table displays only the latest version

You need to monitor all the Hbase daemons along with the other services in the ETL/Hadoop Cluster .And the rowkey definition should be done with at-most care,as the rowkey defines the performance of Hbase.

As other big data eoc system tools are not permitting any updates on data stored in HDFS,we can use Hbase to simulate this feature using its "version" mechanism,and still leverage the capabilities of Hadoop

It's really fast and quite reliable. We manually instilled multiple namenode failures but it still worked flawlessly.

People coming from traditional relational databases will have a hard time wrapping their heads around how HBase works. The lack of a stronger query language might cause other people to not use it.

Keep in mind that it's an OpenSource project. So support is only through email lists. Also, it's not a RDBMS. So don't try to use it like one. It'll hurt more than it'll help. Try to denormalize your existing data if you are switching from an RDBMS.

Also, if you have good hardware and want better support, try using the Cloudera or Hortonworks distribution. I have experience with the Cloudera distribution and the Apache one as well. As far as I know, Cloudera's is free for smaller clusters. Also, it's very easy to install it that way.

We found out that while serving content through HBase it's fault tolerance was very handy. We killed multiple namenodes and it kept serving.

nosql architecture ,ease of scaling up to several nodes and easy retrieval of information, best suited for unstructured data.

very complex software and requires monitoring for performance

An amazing database to store structured/unstructred data

bigdata solutions and data crunching.

HBase is the right DB for any non-relational usecase. HBase operations run in real-time on its database rather than MapReduce jobs. It scales linearly to support billions of rows with millions of columns. Reliable and Fast

Difficult for people who are building custom tools for SQL like purposes to understand HBase. Cannot be used for transactional datasets

Make sure you absolutely need it. If your problem can be solved using relational db, use it. And, understand that the support is through the community distributions

Scalable and truly non-relational data

HBase is very much a developer-centric database. Hbase is built on Hadoop ecosystem, stored procedures through coprocessors and consistent

Doesn't have a easy query language like SQL, too complex and too many variable parts, mostly can only be used with single node cluster

We work with large datasets and use social media mining. Hbase is very compatible with Hadoop so it is very useful for our existing system.

Its open Source and written in java and its a non relational.

SQL integration layer is a bit complex, and it runs particularly on UNIX

Surely go for it as it is the future

We had the schema metadata to be moved to the HBASE

So we were trying to store the metadata.

HBase is an open source columnar non relational database. HBase is written in Java so most of the operations on HBase can be done using java and api calls.

There also exist HBase Shell/command line. HBase is not a direct replacement for RDBMS but it has almost all features of database including indexes.

Zookeeper maintains synchronized structure betweeen mulitiple clients.

Its free. Open Source.

Compatible with Hadoop. Very good for analytics using Hadoop and MapReduce.

HBase is very flexible on schema. Column families can be added on the fly.

It has feature to update a column value by updating corresponding rowkey as it tracks by timestamp.

Also it can delete a specific column from a table row.

Mostly dependant on the HMaster.

As many other Non relational databases HBase cannot be used for transactional datasets.

Most of the table operations like joins, aggregations still slower than regular RDBMS products as it depends on MapReduce

HBase is very well suited for any non relational database purpose.

I was using HBase for non relational columnar database.

HBase is one of default products in a Hadoop stack. HBase is on top of HDFS so Hadoop, Hbase, Zookeeper make more things better and scalable. From the CAP theorem triangle - HBase satisfied the Consistency and Partition Tolerance properties. HBase with its regions architecture is very efficient in reading data. HBase is optimized reads but adding a new column family, appending new values to a row key like update is very simple. HBase very well supports transaction within a Row.It also follows Write Ahead Log and acknowledging functionalities so that data is persistent. HBase supports indexing - can use bloom filters. Hive can directly access HBase tables so we can the advantages of both on data.

Data skewness is always an issue. So row key should be configured properly and data inserts can be divided into phases to distribute data equally across regions. Though its highly scalable and consistent, high availability is still an issue. Master can be crashed anytime and region servers recovery also expects some downtime.

Though it supports read and write it still not a RDBMS. Use it as any other big data database. HBase does automatic sharding but still you need to care about distributing logic. You can go for HBase when your application needs to do handle huge datasets and do analytical processing.

Used HBase as a database for storing and retrieving. ETL type pipeline building.

Low Latency, versioning row, consistency, Java API, interoperability with another software

Tuning, compaction, configuration and settings

Consider HBase if you need timeseries storage

Social Media Analytics

Easy to set up, and easy to use. Fact that it sits on top of hdfs is even better

not very easy to diagnose issues. GC tuning is a real p.i.t.a.

Using HBASE in pipeline flow to reduce time and storage of reads necessary.

HBase has some ACID capabilities: strong consistency at row level, which saved us a lot of headaches. The performance is great!

Also HBase has a vibrant community and questions get answered quickly.

HBase doesn't have SQL-like query language such as Cassandra's CQL.

Deployment of HBase and monitoring the cluster is not as easy.

We use a 15-node cluster to store email messages and perform analytics on them. It has seamless integration with Hadoop cluster.

HBase provides very good access to data values if you know the key. It is very good fit for key value stores. It is very tightly integrated with hdfs and we can run mapreduce jobs on top of hbase tables and analyze the data in less time.

Sometimes when we run hive queries on top of hbase, they will run slower and some times it leads to OOM if we did not configure heap sizes correctly.

For key value stores it is very good fit and we are using hbase to analyze the data and to store small files.

1. Highly Scalable.

2. Rich set of data type.

3. API support multiple language.

1. It is difficult to configure

2. Its Documentation website can be improved and made more visual.

1. Highly scalable.

2. Storage is cheep.

1. Data Analysis

1. Story history log

1. Free and open source

2. Comes as part of all Hadoop distribution

3. Good for fast inserts and scan use cases

HBase master High Availability issue still not resolved

Performance still not comparable to Cassandra

HBase performance tuning is quite tedious

Good for both OLAP & OLTP usecases

Stock History

Persistent store for real-time steaming data

Persistent store for OLAP cube

HBase is always at the top of mind when speaking to prospects. It was always easy to set traps for competing technologies.

HBase requires an extremely talented team to successfully deploy and leverage. Most companies think that they have the expertise in house, and they usually do not.

Recommendation engines are the most common use cases

The query and structured storage of big data. Can be connected via different platform or programming language.

I have not found anything to dislike in hbase . Sequential processing takes more time for big data and as data size increases.

NA

Banking applications. Easy for big data storage and transactions

It has most of the features of RDBMS databases. It is open source and it is written in java, so most of the activities can be done using java and api calls.

A lot of dependence on Hmaster.

Not good for transactional datasets.

Lack of native query language, I had to use Hive on top of it.

Very good for analytics and non relational database purposes.

Hbase is pretty flexible. It is very good for analytics when used along with Mapreduce.

Data handling and modification is pretty good.

The ability to just throw the kitchen sink at it and watch it eat it! Hbase can handle the load of a "low latency", constantly updating and high throughput data load. Easy once get "it".

Lots of knobs and buttons to tweak. Lots of resubmitting the same data until you get it. Documentation is ok.

Remember to understand that you design the tables based on the queries you think you are going to perform. Monotonically increasing keys are bad.

Low latency click stream data. Fast ingestion with quick query results.

Linear scalability and channel partnered with other Apache ecosystems and properatory products to built new tools for easy/quick data retrival

Hbase + Phoenix is focused on handling update/delete but its not close to relational data store. Start with dimentional tables and keep fact tables away. Use Hbase for immutable data which works on key, value pair

As we talk about IDW, Hbase palys a vital role is data processing making more ronom for Business Analyst and Operation

It's ability to store data versions, Also, not having to define schema for columsn apart from column family.

Not ACID, not like SQL needed to learn a different form again.

Moving from CDB server to HBase to improve speed.

The querry performance on huge data and the data shrading

Still work as master slave architecture. Cassandra is a good choice

Electronic domain. It's already having impact on our reporting and analytics

The speed. The complexity. The money saved.

The configuration. The arbitrality of parameters.

Research.

Increased productivity.

1. HBase scales linearly to support billions of rows with millions of columns.

2. It inherits the fault tolerance of HDFS

Secondary indexes are supported only with coprocessors or a sql engine like phoenix

It is perfect to store data such as search metadata, catalog, user interests, etc

Great opensource product for persistent storage. Scales very well.

Coming from a relational background the inability to index data on arbitrary columns causes is an issue.

We used Hbase to store data when our relational database is under maintenanace.

Scaling capability to 100 of nodes and super fast

Two many processes makes it hard to manage

Salesforce Big Objects

scalability, consistent reads and writes. Automatic and configurable sharding of tables, Failover support

Need more documentation on security and query language.

We have to handle the huge unstructured datasets.