数据库是数据持久化存储方案。
关系型数据库mysql已经在我们的项目中广泛应用，并很好的支持了项目的正常运行，那为什么还发展出了分库分表和分布式数据库呢？
1. 关系型数据库mysql的局限性
当表中的数据达到200万行（也有说500万行）后，即使优化后，整体数据库的查询还是明显变慢。原因呢？
先说说mysql数据库正常情况下查询慢的原因：
1）没有加索引或者没有使用到索引；
2）索引么有优化；
3）一次查询的数据量过大；
4）内存不足；
5）出现死锁；
参考：https://www.fengnayun.com/news/content/339357.html
那么数据库的量大了以后的原因：
1）上述问题会dubbo；
2）相同的查询条件下，500万行与10万行需要扫描的数据量是不同的，肯定变慢；
3）如果是二级索引，那么回表的次数会大大增加，磁盘寻道的时间也会加长；
4）当单表达到500万行和原来的10万行数据相比，整体数据库查询到这张表的概率会增大，也就是说对这张大表的数据库IO会增多，那么也会影响整体数据库的性能；也就是会影响到其他表的查询；
那么怎么办：
答案是 分库分表
2.分库分表
apache shardingSphere 中间件
把一张大表中的数据分片，实现分式 分库分表，有client和proxy模式，本质 分片。在此不多论述。但是当数据库继续增加，达到亿量甚至更大的时候，这种模式就不合适了。比如原来一张500万行的表分成了3张表，但是当3张表都又达到 500万行，怎么办？好，继续分表。再大呢？继续分。累不累。这时候就需要分布式数据库进行统一管理分片。
3.分布式数据库
那么分布式数据库是咋回事呢？
1）为了解决关系型数据库的数据量增大后查询慢的问题，hbase来了。
hbase是计算和存储分离的架构，存储使用的是hadoop的HDFS（分布式文件系统），计算采用hadoop的mapReduce。他采用了ROOT表和META表来存放region。那么他的查询怎么就快了呢?
看它的查询步骤：ROOT表--》META表--》RegionServer--》查询。
内存中会有MemStore文件，查询的时候先去MemStore中查询，如果没有才去磁盘中进行扫描查找。
一个RegionServer大约管理1000个region，region由各个StoreFile组成，StoreFile与HFile对应，最后刷盘。存储在HDFS上面，而HDFS默认一个文件的大小是128M。也就是说天然分表。
2）那么elasticsearch是这样的吗？
大同小异。
elasticsearch是计算和存储一体的架构，底层搜索引擎是lucene。
lucene不是分布式的，ES就是分布式的lucene而已。
ES的分片其实和hbase等分布式存储差不多，都是主从架构，并实现了原数据的分片和副本。
至此，数据库存储功能演化分析结束。（不包括查询分式的不同，下一篇分析）
分布式数据库的本质-----------》 分片
