我们该用什么去存储数据？（mysql+hbase+es+时序数据库）

​ ​ 在2019年里，有幸跟着项目组接触到了hbase和es，更有幸的是我将这些技术应用到项目中，对这些技术也有了一些了解，结合之前用过的mysql和最近在学习的时序数据库，想聊聊关于存储的一些问题。

​  ​ 数据库技术的发展，大多数是针对于某个场景，优化了该场景需要的一些特性，牺牲了对于该场景不太需要的特性，从而在该场景发挥的更好（我自己瞎总结的）。

---

​  ​ 下面我会从大家最熟悉的mysql开始，逐渐引出现在很厉害的分布式数据库 es、hbase以及时序数据库的一些查询写入原理，揭开这些数据库的神秘面纱。

 ​我们主要会从这几个方面聊一下:

• mysql的瓶颈以及解决方案

• hbase为什么写入比mysql快好几个量级？

• 为什么说es一切都为了搜索？

• hbase和es的分布式都做得很厉害，它们分别是怎么做的，为什么这么做？

• **时序数据库为什么比较适合存储时序数据？ **

---

1.mysql的瓶颈以及解决方案？

​  ​ 我们先来聊聊mysql吧。

​  ​ 这是一个很长很长的故事，在很久之前，我们的互联网还不是很发达，需要处理的数据量也不多，我们服务器上有很多关系型的数据需要存储起来（比如用户、角色、资源、 订单、支付等数据），并且需要提供灵活的结构化查询（包括多条件查询以及多表联查），这时候传统的关系型数据库就出现了，其中代表就是mysql。
​  ​ 为了更好的支撑业务，我们在这个数据库上做了很多功能，比如为了保证业务数据的ACID特性，我们增加了事务（通过共享锁和排他锁实现）,为了更加快速的查询。我们增加了索引（通过B+树实现），为了更加快速的写入，我们采用了日志先行（WAL，先将数据写入到redo日志中，返回成功，再异步写到磁盘中（innodb））的策略，就这样，mysql可以很好的支持一般的应用系统。
​  ​ 后来我们发现，随着业务的发展，我们的单机mysql是有局限的。
​  ​ 第一个问题，如何保证数据库的高可用，万一数据库挂掉了我们怎么办？
​  ​ 主备，这是我们保证高可用的基本，好吧，我们在一个mysql（master）的基础上增加一台备用的mysql（slave），一般正常情况下，我们只有一个master进行工作，当这个master挂掉之后，我们需要将slave顶上去，继续进行工作。
​  ​ 那么slave怎么知道master挂掉了呢？我们还需要一个zookeeper这样的协调服务告知slave master的状态，或者说我们也可以通过slave去监控master，这样，master挂掉了slave也知道。
​  ​ 还有，既然slave要能顶替master，那么slave就要和master的数据保证一致，这样就不至于slave顶上去出岔子，那么我们就需要在数据更新的同时，数据通过binlog同步完slave之后才能返回成功（当然这样做的话牺牲了写入的性能（主从复制网络耗时），我们也可以在更新到master后就返回成功，再异步同步slave，但是这样的话也有个问题就是说在master挂掉之后，slave的数据不一定完整，只能选取数据最多的slave进代替master，这样可以提高写入性能，但是如果是要保证数据准确性的场景下，是不适合的。别担心，这些应该都是可以配置的）。
​  ​ 另外，为了减少master的压力，我们可以做读写分离，在slave上读取数据，在master上写入数据。
​  ​ 第二个问题，如果数据量大了，或者ops高了，我们如何做水平扩容（如何保证高扩展）？
​  ​ 首先，解决存储数据量的问题
​  ​ 随着数据量越来越大，我们的单库单表产生了瓶颈，单表产生瓶颈是因为我们的数据量大了，查找一条数据需要扫描的条数越来越多，导致查询越来越慢，超过了用户等待的极限时间或者数据库连接的极限时间，单库产生瓶颈是因为数据量大小达到了我们的操作系统的文件系统ext2 ext3的存储容量极限（当然在现在微服务化和单元化的潮流中，由于一个微服务对应一个数据库，分库的需求实际在慢慢的变