分布式文件系统HDFS无索引就无K/V

首先分布式数据并不是绝对的喜欢使用kv存储模式，例如分布式数据库里面mongodb和elasticsearch是文档形式存储，若把HDFS也算进去的话，它是无索引的存储。

上图是HDFS作为分布式数据存储的文件分块存储模式，简单直接，并没有进行任何的kv索引建立。我们可以看到图中Nginx日志被切割成duo多份，然后分布在三台数据节点上，要注意的是，HDFS的副本一般是三份，图中只做了两份代表副本的意思，但实际上是三份。客户端在进行访问通信是时候，都是通过数据块scan的方式进行，没有索引，就没有随机访问机制。

TiDB的架构特征

像cockroach,tidb，明明是关系库，为啥非要弄个key，即使业务逻辑不需要表有unique key，也要给每条记录硬加一个key，这是什么目的？

其实cockroach，tidb都叫NewSQL，是NoSQL+关系型数据库的合体，认为它们是关系库，说得不恰当。

例如：tidb分为PD、TIKV、TIDB，PD管理者kv的关系结构，这部分可以对标关系型数据库。

上图是TIDB的架构图，图中可以看到TIDB形成的集群主要是接收外部应用的SQL，处理SQL的逻辑，与PD交互获取KV地址，与KV交互获取数据；

PD组成的集群主要是通过元数据的语义理解kv在集群中的位置，实现对KV集群的调度和负载均衡，分配全局事务ID；

TIKV就是我们说到的重点，通过Key-Value存储引擎，提供分布式事务能力。每个节点有多个Region，Region存储一个范围Key的数据——Key Range，主要是为了形成连续的小组，在局部提供写入和读取的性能优势。并且以Region作为原子单元，实现集群跨节点的副本复制，复制方式用Raft协议实现。

实际上TIKV部分就是标准的NoSQL为基础的数据持久化层了，TIKV的持久化数据层就是RocksDB，同样的cockroach持久化数据层也用的是RocksDB，RocksDB的就是LSM-Tree的日志追加方式WAL (write ahead log)快速写入数据，再通过LSM-Tree的memtable，sstable结构，索引key，获取value，所以就是个标准的key/value数据库。

RocksDB的核心优势LSM-Tree结构

为什么它们不约而同的都选择了RocksDB，因为作为核心结构LSM树的WAL，memtable，sstable方式具有写入数据的巨大优势并保证数据可靠性，形成很多小的顺序分组，同时又得到局部热点上的惊人查询优势，在内存中完成查找。

而且LSM-Tree配合Bloom Filter又能将时间线作为优先级，快速索引数据在磁盘中的位置范围，这就大大减少扫描磁盘的动作。

若遇到大范围随机查找，Bloom Filter有也查不到位置的情况，才会通过二分查找，并在树的不同层进行多路合并，取优先级最高的数据。

那么通过这种思路，就能比关系型数据库的b/b+树索引在写的性能方面带来质的提升，而且对于局部热点，也就是近期数据带来惊人的查询性能，虽然全局范围的查询有所降低，数据段合并会带来的资源消耗(rocksdb通过多线程合并提升了这一过程的效率)，但数据库读写的整体性能的平衡性变得更合理了，总之将来通过集群处理读的问题总是比处理写的问题更容易，这就是选择key/value数据库的底层逻辑。

NewSQL相对于MySQL的优势

反观关系型数据库，例如要给MySQL加上一条索引，那么索引字段就是key。所以RDBMS也不能说自己跟key/value存储没啥联系。

作为业务逻辑上不需要unique key而非要加一个key，这是因为关系型数据库设计的初衷就不是为了海量数据的快速写入和查找所设计的，即便没有索引，行集扫描也没有问题，这才是常态是其本质，这和Hadoo HDFS的按块扫描一样，都是一种原始的状态，HDFS之上依然需要HBase数据库来解决海量数据的随机查找场景，本质上作为列族分类的HBase也是Key/Value模式。

NewSQL选择了RocksDB，也就是选择了业务记录中key存在的必须，但换来的是海量数据的高效写入和查找，非常划算。