数据库领域的热度目前逐渐从传统关系型数据库系统向分布式数据库系统转移，例如：擅长于分布式一致性、宽表分析的HBase；优势在高可用、线性扩展、海量查询的Cassandra；高度成熟的高可靠并适合于数据底座的HDFS；国内广泛应用且很成熟的全文搜索兼备海量存储的Elasticsearch；专业于工业、监测领域以时间为主线支撑超大规模吞吐与存储的influxdb；以及通过分布式事务的优势开拓关系型数据库领域的市场，并具有oltp+olap融合优势的TiDB。
要说眼前一亮的事情，我就罗列一些架构设计方面的特性，但并不一定是这些数据库的主要优势：
结合基础环境会变得更方便， 分布式文件系统中，除了我们熟知的Hadoop HDFS之外还有GlusterFS，MooseFS，这两位都有一个比较牛逼的特征，那就是结合了Unix/Linux的FUSE内核机制，有了这层机制，就可以在使用分布式文件系统的时候当成客户端挂载(Mount)的一个目录，当做本地文件来操作，这实在是太方便了，而且应用面会很广泛，例如：可以将MySQL的数据存储目录的设定放到挂载的这个目录里，那么MySQL就自带高可靠了！
优雅的共识规则更胜于元管理， 我们再谈到分布式列簇数据库Cassandra，它将kv数据在集群节点的分布设计成了一致性哈希环，但是优于普通的一致性哈希环，设计得非常优雅，本质上Cassandra并没有直接让集群节点与一致性哈希环做绑定，而是设计出了token这样虚拟的节点概念，那么如果一个节点有512个token，4个节点就有2048个token分布在环上，4个节点的token在环上都是交替排列，这样只要写入的数据记录hash(rowkey)匹配了一个token范围，那么数据就落入环的此token位置，副本依次顺时针向下一个token存放(遇到机架和数据中心会根据策略来定)，落到哪个token就存在哪个节点里。这种机制不仅写入的时候分布的数据非常均匀，如果取消一个节点，512个token从犬齿交错的环上被拿掉后，会顺时针找到下一个token，而下一个token所属节点依然是均匀分布的，不会出现数据倾斜，新增一个节点同理。总之Cassandra面向去中心化的设计在一致性哈希环的设计上极为优雅，那么再多的节点伸缩也会在这种规则下平稳的运行。
完美契合业务特征那才叫专业， 最后在说说专业的时序数据库influxdb的分区组(shardgroup)，这绝对是influxdb一大创新亮点。influxdb的特征在于先说清楚数据保留多久，保留这么久的数据再平均按照多久做一次切分，那么这就是保留策略(RP)和分区组(shardgroup)的作用了！假如我们把数据保留1个月，每天做一次切分，那么shardgroup就会按照每天做一次数据目录和文件的分隔，这就相当于把时序数据库的数据切成了一段一段，在查找的数据的时候，就可以根据时间范围知道在哪几段的分区文件上找。更有意思的是influxdb集群模式会有多个节点，例如4个节点2个副本策略，相当于4/2形成了双分区双副本，也就是一个shardgroup里面管理2个shard，也就是说在一个分区组的时间段内，写进来的时序数据可以再分布到两个分区，分布都手段就是hash(series)取模，这样是不是又把数据读写的压力分担在了不同的节点上了，因此influxdb集群的设计思路就是基于时间线的数据分段以及在分段中进行数据分布式存放与访问，完美契合时序的特征。
数据高可靠的新玩法， 对于高可靠的理解可以使用在很多方面，例如：Redis的哨兵模式，挂掉的Redis Master数秒后会被Redis Slave替代，这就是Redis利用哨兵的集体投票选出了新的领袖机制，这就是保障了服务运行的高可用，对于这个系统不中断的高可用场景，可以认为是运行高可靠。
但分布式文件系统对上层应用提供的高可靠主要是数据冗余，做到数据的高可靠，列如：运行MySQL的节点宕机无法启动，传统方式就希望存储工程师从OS层面的存储中恢复或者在slave备份中找。
但若是我们把MySQL的data目录部署在了MooseFS所挂载的目录，一方面实例照常运行，但数据是在DFS中保存着，另一方面MySQL实例节点故障亦或者DFS某个节点故障都不是问题，也就是说数据始终在独立的数据底座中可靠的运行着，对于运维就很方便，换一个MySQL实例就行了。那么我们可以将这种数据冗余的场景称之为数据高可靠。
MySQL master/slave岂不是更方便？很多人会这样理解，我的新的观点是：如果仅仅是为了数据备份，主从架构只能服务于MySQL！另外主服务宕机始终还要手动切换。
但是DFS提供了一种通用的备份冗余底座，为MySQL形成了数据引擎与数据存储的分离，又不仅仅服务于MySQL。关键这是上层应用建筑而非硬件底层依赖，这样就很方便的衔接在开发和运维过程之中。
