MySQL：关系数据库主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group Replication架构模型(本文全部)Innodb例如，不涉及其他存储引擎）。
HBase：基于HDFS，支持大量数据读写(尤其是写作)，支持数亿行、数百万列的分布式列NoSql数据库。天然分布式，主从架构，不支持事务，不支持二级索引，不支持sql。
ElasticSearch：简称ES基于底层的分布式全文检索框架Lucene虽然技术实现ES它还提供存储和检索功能，但我从来没有想过ES是一个数据库，但ES与数据库的界限越来越模糊。分布式，P2P采用倒排索引提供全文检索倒排索引提供全文检索。
假设有这样的人员信息表：
MySQL数据库应提前定义表结构，需要提前定义数据表中有多少列（属性），并定义每个列所占用的存储空间。数据由行为单位组织在一起，如果没有数据，也需要占用存储空间。
HBase以列为单位存储数据，每列为一个key-value，HBase列表(属性)不需要提前定义，列可以动态扩展。例如，需要在人员信息表中添加新的address”字段，MySQL需要提前alter表增加字段，HBase可直接插入。
ES在索引中更灵活field类型可以提前定义(定义)mapping），也可以不定义，如果不定义，会有默认类型，但出于可控性，建议提前定义关键字段。（Solr必须提前定义schema.xml文件）
数据显示在上图中MySQL和HBase即使第二条记录了存储差异（与实际情况有差距），也可以看到存储差异sex字段为空，MySQL它仍然会为字段保留空间，因为后续可能会有update句子更新记录，补充sex内容。而HBase每一列都被视为记录，row 列名作为key，data作为value，依次存放。若某一行某一列没有数据，则直接跳过该列。稀疏矩阵的大表，HBase它可以大大节省存储空间。
看到这里，你会有一个问题：使用它吗？HBase存储时，如果此时需要添加第二行sex如何实现内容，数据是否连续？以后将解释读写过程。
不一样的ES
ES存储方式与上述两种不同，MySQL和HBase是以不同的方式存储数据，至少它们存储或数据，ES则存的是倒排索引。我们先来了解一下什么是倒排索引，以及为什么需要倒排索引（Inverted Index）：
我们肯定会有这样的经历：偶然看到一个好词，但不知道来源，此时去图书馆，一个接一个，无疑是大海捞针，这次有全文检索技术，其核心是倒排索引。如有以下文件：
我们想知道哪些文档包含you这个关键字，首先可以创建一个倒排索引，格式如下：
前部叫dictionary(字典)，里面的每个单词都叫term，后面的文档列表叫做psoting-list，list中记录了所有含有该term的文档id，两个组合是一个完整的倒排索引（Inverted Index）。可以看出，如果需要查找含有you根据文档dictionary然后找到相应的posting-list即可。
在全文检索中创建Inverted Index这是最关键、最耗时的过程，也是真实的Inverted Index结构远比图中显示的复杂，不仅需要对文档进行分词（ES中文可以自定义分词器)TF-IDF，方便评分排序(搜索时)you时间，评分决定哪个doc显示在前面，即所谓的搜索排名)，压缩等操作。每接收一个document，ES在倒排索引中更新其信息。
可以看出ES和MySQL、HBase存储还是有很大区别的。ES不仅包括倒排索引，还包括默认文档doc存储起来，所以当我们使用ES在某种程度上，你也可以获得完整的文档信息，感觉就像使用数据库一样，但你也可以配置不存储文档信息，然后你只能根据查询条件获得文档id，无法获得完整的文档内容。
总结：
MySQL：存储方式更合适OLTP业务。
HBase：列存储更适合OLAP业务，而HBase采用列族平衡的方式OLTP和OLAP，支持水平扩展，如果数据量大，性能要求不高，对事务没有要求，HBase可以考虑。
ES：ES对所有字段的默认索引，因此更适合复杂的检索或全文检索。
3、容灾对比
3.1 MySQL
单节点：
目前的数据库被广泛使用write ahead log避免数据丢失的策略，wal机制的简单解释是：提交CUD操作，数据写入内存的同时，也要写一份log保证文件log数据落盘成功后，才能方向client如果此时数据库停机，已提交到内存的数据还没有时间刷回磁盘，重启数据库后，可以回放log恢复内存中的数据。
问题又来了:写log对性能会有很大的影响吗？其实有一点影响，但是log相对而言，为了保证数据的完整性，这种性能损失是可以接受的。
单机情况下，MySQL的innodb通过redo log和checkpoint保证数据完整性的机制。因为害怕log越写越大，占用磁盘太多，当log特别大的时候，恢复起来也很费时。checkpoint要解决这些问题。
checkpoint机制保证了以前的log数据必须刷回磁盘，当数据库停机时，只需要checkpoint之后的log数据库可以定期回放checkpoint，这保证了数据库恢复的效率。
但考虑到机器在硬件故障无法启动，或磁盘故障时数据无法恢复，checkpoint redo log为了防止这种故障，方案不起作用，MySQL还提供了master-slave和group replication 集群级容灾方案。
Master-Slave架构的主要思路是：master负责业务的读写请求，然后通过binlog复制到slave节点，如果主库因不可抗拒因素无法恢复，可以从库中提供服务。在这里，我们使用复制这个词，而不是同步binlog复制方案不能主从数据强一致，这种主从同步方式会导致主库挂断后从库中丢失少量数据。
正是因为主从架构存在数据不一致的问题，MySQL5.7出现了Mysql Group Replication方案，mgr采用paxos该协议实现了数据节点的强同步，确保所有节点都能编写数据，所有节点读取最新数据。
3.2 HBase
HBase的容灾和MySQL单机容灾有些相似，但具体实现还是有自己的特点。
在介绍HBase容灾前，我们先来了解一下HBase和HDFS的关系：HBase存储在数据中HDFS可以简单理解HBase分为两层：
一层为NoSql service(即提供分布式检索服务)
一层是分布式文件系统(数据存储的位置，目前使用HDFS）。HBase中region不同的分布regionserver上，client端通过meta哪个数据在表中定位？regionserver的region然后获取数据，但数据可能不一定在这里regionserver本地保存，每一个region大家都知道自己对应的数据在HDFS哪些数据块，最后，通过访问HDFS获取数据，尤其是当HBase和HDFS当部署在不同的集群上时，数据的读写完全是通过RPC实现，减少RPC确保服务稳定的费用往往会HBase和HDFS在同一集群中部署。
同样，当一个regionserver挂了，region可以快速切换到别的regionserver因为它只涉及回放Log，已经落盘的数据不会移动，而且HBase也会控制log减少恢复时间。
HBase也是采用写log防止数据丢失的方法，同时写入内存HLog，HLog也是存储在HDFS上，写入HLog之后，你会认为数据是成功的，某个regionserver挂掉之后，master在故障机上regions调度到别的regionserver上，regionserer通过回放HLog来恢复region的数据，恢复成功后，region重新上线，由于log是直接写在HDFS上，所以不用担心单个节点挂掉log数据丢失的问题。
这里引出一个问题：回放HLog的时候，正在被恢复的region会短时间不可用，直到HLog回放成功。HBase1.0版本中加入了region replicas功能，也就是提供一个slave region，当主region挂掉的时候，依然可以通过slave replicas来读数据，但是slave不提供write，而且slave replicas和primary region并不是强同步的，并不一定总能读到最新的数据，所以开启该功能时，也要考虑自己业务是否必须要求强一致。
HBase也提供了cluster replication，目的是为了做机房级的容灾，boss说现在cluster replication功能还有些bug，目前也在积极优化改进，相信以后会cluster replication会越来越完善。
3.3 ES：
ES的容灾也是采用写log的方式，与HBase不同的是，ES的节点保存各自的log，这点跟MySQL类似，log是存放在本地的，这也就存在和MySQL一样的问题，假如机器宕机或硬盘故障，log数据也会丢失，所以index每个shard也有主备，默认配置是一个primary shard，一个replica shard，当然也可以配置多个replica。
默认情况下：primary shard首先接收client端发送过来的数据，然后将数据同步到replica shard中，当replica shard也写入成功后，才会告知client数据已正确写入，这样就防止数据还没写入replica shard时，primary挂掉导致的数据丢失。
又到了提问环节，如果有一个replica节点出了问题，比如网络故障无法写入，那岂不是数据一直写入不成功了？所以ES的master维护了一个in-sync set，里面保存了目前存活、且与primary同步的replica集合，只要set中的replica同步完成即认为数据写入成功。考虑到一种情况：所有的replica因为网络故障都下线了，in-sync set此时为空，数据只在primary中保留一份，很有可能因primary故障而导致丢数据，所以ES新增了wait_for_active_shards参数，只有当存活的replica数大于该参数时，才能正常写入，若不满足，则停止写服务。
（这是5.X版本的实现，由于ES版本更新过快，这和2.X之前的版本有些差异，5.X中in-sync set的方式和Kafka的容灾模式非常类似，但和Kafka有一点区别：ES的primary负责写服务，但是primary和replica都可以提供读服务，而Kafka只有primary partition提供读写服务，replica只是同步primary上的数据，并不提供读。
4、读写方式
4.1 Mysql
MySQL的Innodb中的数据是按主键的顺序依次存放，主键即为聚簇索引（对聚簇索引和非聚簇索引不了解同学可以看看这篇文章），索引采用B+树结构进行组织。
从图中可以看出，数据是按聚簇索引顺序依次存放，假设下面一些场景：
1.查询
Innodb中主键即为聚簇索引，假如根据主键查询，聚簇索引的叶子节点存放就是真正的数据，可以直接查到相应的记录。
假如是二级索引查询，那么需要先通过二级索引找到该记录的主键，然后根据主键通过聚簇索引找到对应的记录，这里多了一个索引查找的过程。
2.插入
顺序插入：因为Innodb的数据是按聚簇索引的顺序依次存放的，如果是根据主键索引的顺序插入，即插入的数据的主键是连续的，因为是顺序io，所以插入效率会较高。
随机插入：假如每次插入的数据主键是不连续的，MySQL需要取出每条记录对应的物理block，会引起大量的随机io，随机io操作和顺序io的性能差距很大，尤其是机械盘。
（Kafka官网提到一个机械盘的顺序写能达到600M/s，而随机写可能只有100k/s。As a result the performance of linear writes on aJBODconfiguration with six 7200rpm SATA RAID-5 array is about 600MB/sec but the performance of random writes is only about 100k/sec—a difference of over 6000X.这也是为什么HBase、ES将所有的insert、update、delete操作都统一看成顺序写操作，避免随机io）
note：这也是为什么MySQL的主键通常定义为自增id，不涉及业务逻辑，这样新数据插入时能保证是顺序io。另外MySQL为了提高随机io的性能，提供了insert buffer的功能。
3.更新 & 删除
update和delete如果不是顺序的话，也会包含大量的随机io，当然MySQL都针对随机io都进行了一些优化，尽量减少随机io带来的性能损失。
4.2 HBase
HBase不支持二级索引，它只有一个主键索引，采用LSM树。
HBase是一个分布式系统，这点跟MySQL不同，它的数据是分散不同的server上，每个table由一个或多个region组成，region分散在集群中的server上，一个server可以负责多个region。
这里有一点需要特别注意：table中各个region的存放数据的rowkey（主键）范围是不会重叠的，可以认为region上数据基于rowkey全局有序，每个region负责它自己的那一部分的数据。
1.查询
假如我们要查询rowkey=150的这条记录，首先从zk中获取hbase:meta表（存放region和key的对应关系的元数据表）的位置，通过查询meta表得知rowkey=150的数据在哪个server的哪个region上。
2.插入
上图粗略的展示了HBase的region的结构，region不单单是一个文件，它是由一个memstore和多个storeFile组成（storeFile上的上限可以配置）。插入数据时首先将数据写入memstore，当memstore大小达到一定阈值，将memstore flush到硬盘，变成一个新的storeFile。flush的时候会对memstore中的数据进行排序，压缩等操作。可以看到单个storeFile中的数据是有序的，但是region中的storeFile间的数据不是全局有序的。
这样有的好处就是：不管主键是否连续，所有的插入一律变成顺序写，大大提高了写入性能。
看到这里大家可能会有一个疑问：这种写入方式导致了一条记录如果不是一次性插入，很可能分散在不同的storeFile中，那在该region上面查询一条记录时，怎么知道去找哪个storeFile呢？答案就是：全部查询。HBase会采用多路归并的方式，对该region上的所有storeFile进行查询，直到找到符合条件的记录。所以HBase的拥有很好的写入性能，但是读性能较差。
当然HBase也做了很多优化，比如每个storeFile都有自己的index、用于过滤的bloom filter、compaction：按可配置的方式将多个storeFile合并成一个，减少检索时打开的文件数。
3.更新 & 删除
HBase将更新和删除也全部看做插入操作，用timestamp和delete marker来区分该记录是否是最新记录、是否需要删除。也正是因为这样，除了查询，其他的操作统一转换成了顺序写，保证了HBase高效的写性能。
4.3 ES
ES的也是一个分布式系统，与ES类似的还有一个叫Solr的项目，都是基于Lucene的全文检索分布式框架，有兴趣的可以去Lucene官网了解，这里就不做对比了。
上如展示了ES和传统数据库的概念对比。下面的介绍中，统一使用index对应DB中table，doc对应table中的记录，field对应row中的一列。
ES集群由一个或多个node组成，一个node即为一个ES服务进程。一个index由多个分片shard组成，shard分散在各个node上面，每个shard都采用Lucene来创建倒排索引，维护各自的索引数据。
图中的一个小方框即为一个shard，出于容灾考虑，每个shard都会有多副本，副本个数可以配置，默认为2，绿色的即为primary shard，灰色的即为replica shard。
1.插入
先来说说写入吧，由于有多个shard，请求过来时，如何判断写入到哪个shard呢，ES中每个doc都会有一个唯一id，默认会对id取hash值，根据shard的个数mode到对应的shard上，默认情况下shard中的数据id不是全局有序的，这点和Mysql、HBase有很大区别。
ES的写入和HBase有些类似，也是将所有的写操作变成顺序写，也是先将数据写入内存，然后一段时间后会将内存数据flush到磁盘，磁盘的索引文件会定时进行merge，保证索引文件不会过多而影响检索性能。
另外提一点,数据存入ES后并不是立马就能检索到，这点跟MySQL和HBase，或者说跟数据库系统是完全不一样的。主要是因为由于Inverted Index结构的复杂，需要一个专门的indexReader来查询数据，但是indexReader是以snapshot的方式打开的索引，也就是说indexReader看不到之后的新数据。所以ES提供了一个refresh功能，refresh会重新打开indexReader，使其能够读到最新的数据。默认refresh的间隔是1s，所以ES自称是近实时检索功能。
说到顺序写,这时候大家可能会想：那ES的写入速度和HBase差不多喽？那，其实不是的，不止不如而且差的还不是一点点，因为ES多了两个最关键的步骤：build index和refresh index！这两个过程是很耗时的: build index时需要分词、计算权重等复杂的操作（对inverted index创建，检索感兴趣的，可以参考《信息检索导论》）。而refresh会重新打开index,这两个过程加起来导致ES接收文档的速率并不高（可以通过bulk方式来加快数据导入）。但也正是因为这些过程才使ES有强大的检索功能。（虽然我insert慢，但是我花样多呀^ ^）
2.读取
每个node都可以接收读request，然后该node会把request分发到含有该index的shard的节点上，对应的节点会查询、并计算出符合条件的文档，排序后结果汇聚到分发request的node（所以查询请求默认会轮循的将发送到各个节点上，防止请求全部打到一个节点），由该node将数据返回给client。（ES也支持指定shard查询，默认是根据文档id进行路由，相当于主键查询，但是假如不能确定数据在哪个shard上时，还是需要查询所有shard）
这里要强调一下，由于ES支持全文检索，根据Inverted Index的特性，大部分情况下，一个关键字对应了很多的doc，如果全部返回，数据量较大，会对集群造成较大压力，所以ES默认只返回权重最高的前20条记录（可配置），也可以通过scroll功能获取全部数据。类似的场景跟我们平时使用baidu、google是一样的，我们使用搜索引擎时，往往是希望得到关联性最强的top N文档，并不关心全部文档有多少个，这也是为什么要计算权重的原因。
现在的ES的功能越来越丰富，不仅仅包含全文检索的功能，而且还有统计分析等功能，说它是全文检索框架吧，它比全文检索功能要丰富，说它是数据库吧，但是它不支持事务，只能说现在各个框架之间的界限越来越模糊了。
3.更新 &删除
ES的更新和删除和HBase类似，也是全部看做是插入操作，通过timestamp和delete marker来区分。
又到了问题环节 :D ：既然这种将更新删除统一变成顺序写的方式能够提高写性能，那它难道没有什么坏处吗？
答案是肯定有的呀，这种方式能够有效的提升写性能，但是存在一个很大的问题就是后台经常会需要merge，而merge是一个非常耗资源的过程，对于某些稳定性要求较高的业务来说，这是不能接受的，但是不merge的话，又会降低查询性能（过多的小文件影响查询性能）。目前通用的做法是尽量选择业务低峰期进行merge操作。
5、使用场景
说了这么多，其实还是希望对MySQL，HBase，ES各自的实现做下对比，方便我们根据业务特点选择最合适的存储、检索方案。下面说一下笔者在工作中使用的经验：
MySQL在三款中最为成熟，而且支持事务，支持二级索引，容灾备份方案也最为成熟，所以线上核心业务Mysql是不二之选（当然如果不差钱，Oracle也挺不错，而且出问题自己解决不了的话，打电话就可以了，手动斜眼）。
HBase因为其强大的写入能力和水平扩展能力，比较适合存储日志，用户行为等数据量比较大的数据，这种数据一般不涉及事务级别的读写，对二级索引的需求也不是很高。而且HBase的主键不像Mysql，往往是涉及到业务逻辑的，如果查询条件单一的话，可以把直接把需要查询的字段作为主键的一部分，类似MySQL的联合索引，来提供检索功能。
ES现在不仅提供全文检索，还提供统计功能，并且提供的Restful接口非常好用，配上Kibana还可以进行图形化展示，第三方插件也很丰富。虽然ES可以水平扩展，但是考虑到ES的大部分检索都会检索该index的所有shard，如果单个index数据过大，性能多少也会受到影响，所以单个index的大小最好控制在一定的范围，比如存储用户行为日志的index，可以每隔一段时间归一次档，创建新的index，做到冷热分离。而且ES也可以作为MySQL或HBase的索引来使用，虽然Mysql也有索引功能，但是过多的索引往往会拖累MySQL的性能，并且线上MySQL数据库一般也不允许执行统计类的sql，这时可以用ES辅助实现统计，HBase因为只有主键检索，所以更需要二级索引的功能。
举一个笔者前司组合使用的场景：trace系统的log数据以HBase作为主要存储，同时最近三个月的数据也在ES里面保留一份，ES主要用来完成各种复杂检索、统计。但数据同步需要业务自己实现，当然trace业务对一致性要求不那么高，也可以忽略这个问题。
tip：将数据库的数据向ES中同步的时候，因为网络延迟等问题，到达的顺序可能会乱序，这时老数据有可能会覆盖新的数据，ES提供了一个version功能，可以将数据的timestamp作为version值，防止旧version的数据覆盖新version的数据。
总结
传统的关系型数据库有着强大的事物处理能力，满足了大部分线上业务需求，但是水平扩展性一直是一个头疼的问题，NoSql数据库虽然解决了水平扩展问题，但是功能太单一，现在越来越多的公司开始着手研究新一代NewSQL数据库，结合了关系型数据库的优点外还拥有水平扩展能力，比如淘宝的Oceanbase，PingCAP的TiDB，国外的CockroachDB，让我们做好拥抱NewSQL的准备吧。
IT技术分享社区
个人博客网站：https://programmerblog.xyz
文章推荐程序员效率：画流程图常用的工具程序员效率：整理常用的在线笔记软件远程办公：常用的远程协助软件，你都知道吗？51单片机程序下载、ISP及串口基础知识硬件：断路器、接触器、继电器基础知识