什么场景下将MySQL替换为HBase

点击查看原文：https://ctovision.com/2011/01/when-do-you-pick-hbase-instead-of-mysql/，

https://www.quora.com/Can-HBase-replace-MySQL-as-the-main-database?no_redirect=1#!n=12

本文仅列出部分内容，未作修改。

文章1：

Now back to the title of this post.  How do you know if you should pick MySQL or HBase for a solution?

If you are designing systems to operate at huge scale, or integrating with other Hadoop related projects, select HBase. HBase, with Hadoop and related capabilities, is also there to support analysis at scale. So, if you are designing for making sense over big data, pick HBase.

MySQL is not going away. But the things it will be optimized for are traditional RDBMS solutions. If you can comfortably store your data in tables with rows and columns and don't have that much of it or don't do fast analysis over it, MySQL may be your best pick. MySQL is widely used, highly reliable, and well understood. So if your future growth and business model indicates you will never run into scale problems or have challenges conducting analysis over your data, MySQL may well be the best choice.

文章2：

HBase is not designed to replace MySQL entirely and in my opinion will not go in that direction in the future either. Here's why:

1. HBase is designed to handle large volumes of data and large number of concurrent clients. It really shines when you operate it at scale. If the storage requirements of an application are not something that requires a distributed database, HBase is not the right choice. There is no benefit in using an HBase cluster to store a few 100 GBs of data. That can be very easily handled by a single node database. You can replicate it to achieve higher durability guarantees and fault tolerance. That's an entirely different discussion.

2. To achieve scalability, HBase makes trade offs on certain properties. For instance, HBase does not provide cross row transactions.

3. Scalability in terms of volume was one requirement that informed the design of HBase. Another requirement was having a flexible data model. HBase does not have the same data model as traditional database systems like MySQL. There is no concept of predefined columns and types. HBase has column families (think of them as groups of columns), with each column family allowing arbitrary number of columns, without strict type definition. The column names are actually given at write time and not during table instantiation. This allows for flexibility in the type of data that is stored.

4. HBase does not have a query language like SQL. The way to access data in HBase is through the API provided - get, put and scan. It's simple but restrictive.

5. HBase provides a more granular control over I/O performance (IMO) that you can extract from it as compared to MySQL. You can design your tables such that data that is accessed together is stored together on the disk, giving you predictable disk seeks when you access that data. The downside of this is that you have to be familiar with the internal workings of HBase so you can leverage these properties.

Having said all of this, there are applications that clearly benefit from the trade offs HBase makes and the features it provides as a database. Tight integration with Hadoop MapReduce for instance is one of them. As highlighted in some of the previous responses, HBase is being used in production for several applications where it probably replaced an existing MySQL solution. The solutions likely required some redesigning in terms of how they interact with the underlying database. There is work being done to provide multi row transactions in HBase (https://issues.apache.org/jira/b...), but that will not make it drop in replacement for MySQL.

Written 6 Jun 2012  ·  View Upvotes