像cockroach,tidb,yugabyte这些，明明是关系库，为啥非要弄个key，即使业务逻辑不需要表有unique key，也要给每条记录硬加一个key，这是什么目的？
这个世界归根结底就是一个巨大的 Map。
不管是 MySQL 的 InnoDB，还是 PostgreSQL 的 Heap File，甚至是你内存里的指针寻址，如果我们把显微镜倍数调到最大，它们骨子里全都是 KV 存储。
拿最经典的 MySQL InnoDB 引擎来说，大家都在背八股文说它是 B+ 树，但 B+ 树是啥？不就是一个有序的 KV 映射吗？ 在 InnoDB 的聚簇索引（Clustered Index）里，Key 就是你的主键（Primary Key），而 Value 就是这一行数据（Tuple）的 payload。 而在二级索引（Secondary Index）里，Key 是索引列的值，Value 则是主键 ID。 每一次 SELECT * FROM table WHERE id = 1，在底层物理层面，就是在 B+ 树上做一次 Get(1) 操作。 哪怕是 PostgreSQL 这种堆表（Heap Table），它的 KV 属性虽然没那么明显，但实际上它的 Key 就是 (BlockID, Offset) ——我们常说的 CTID，通过这个物理坐标去映射（KV）到具体的数据块。
既然大家都是 KV，为什么我们还要特意强调分布式数据库是“基于 KV 构建”的？这里面其实藏着一个架构分层（Layering）和抽象边界的本质区别。
在单机数据库（如 MySQL）里，KV 结构和 SQL 解析引擎是“血肉相连”的。 InnoDB 并不是一个纯粹通用的 KV 引擎，它是为了关系型数据特化的。它知道什么是“Schema”，知道这一行数据里第几个字节是 int，第几个字节是 varchar。SQL 执行器（Executor）是可以直接把手伸进存储引擎的肚子里，去操作 Page（页）、去加行锁、去控制 Buffer Pool 的。这种紧密耦合（Tightly Coupled）带来了极致的单机性能，但也导致了它很难拆分。
但在 TiDB、CockroachDB 这种新一代分布式数据库里，KV 被“暴力剥离”出来了。 这里的 KV 层（比如 TiKV 或 RocksDB）变得非常“傻”，或者说非常“纯粹”。它完全不关心你存的是一行用户记录，还是一张图片，还是一段日志。它看到的 Value 就是一串毫无意义的二进制字节流（Bytes）。 这种剥离带来了两个巨大的变化：
第一是网络边界的硬隔离。 在 MySQL 里，存储和计算在同一个进程里通过函数调用交互。但在分布式架构下，计算层（SQL 节点）和存储层（KV 节点）中间隔着网线。计算层想拿数据，必须走 RPC 协议发一个标准的 Get 或 Scan 请求。这就逼着架构师必须把接口定义得极其简单、标准，而 KV 就是最标准的选择。
第二是数据模型的降维。 MySQL 的 KV 是为了“查得快”设计的（B+ 树适合读多写少），而分布式 KV（往往基于 LSM-Tree）是为了“写得快”和“易搬运”设计的。因为在分布式环境下，数据一直在不同的机器间飞来飞去（Rebalance），LSM-Tree 这种把数据当作 Log 追加写入、并在后台批量压缩的模式，比 B+ 树这种原地更新、甚至这就导致页分裂（Page Split）的模式要友好太多了。
所以，单机数据库本质也是 KV。但分布式数据库之所以强调 KV，是因为它把这个“隐式的底层实现”变成了一个“显式的架构契约”。它告诉你：只要你能实现一个标准的 put 和 get 接口，我就能在你上面跑 SQL，不管你底下是内存、SSD，甚至是 S3。
这种“万物皆 KV”的视角，正是我在写 NoKV时的核心理念。
在这个项目里，我特意模糊了“记录”的概念。在 NoKV 的代码里，你看不到任何关于 Table、Column 或者 Schema 的定义，你只能看到最原始的 []byte 到 []byte 的映射。但我恰恰是通过这个项目想证明：只要这个最底层的 KV 足够稳（Raft 协议保证一致性）、足够快（存储引擎优化），你完全可以在这之上通过简单的编码规则，构建出一个复杂的 SQL 引擎。NoKV 展示的就是这个庞大分层架构中最基石的那一块——它是如何把混乱的分布式硬件，抽象成一个逻辑上永远可靠的 Map 的。如果你想看看这种“剥离了业务逻辑的纯粹存储”长什么样，欢迎来 GitHub 跟我一起盘盘代码。
