作者：徐奇
TiKV 推出了名为“partitioned-raft-kv”的新试验性功能，该性能采纳一种新的架构，不仅能够显著进步 TiDB 的可扩展性，还能晋升 TiDB 的写吞吐量和性能稳定性。
在上一篇文章中，咱们介绍了 Partitioned Raft KV 这一新试验个性带来的性能和可伸缩性大幅晋升。本文咱们将为大家介绍为什么它能够有如此大的劣势。
架构
以下是 TiKV 的架构。
图 1 TiKV 架构 —— 逻辑数据分区
一个 TiKV 集群由许多数据分区（也称为 Region）组成。每个 Region 负责特定的数据片段，由其起始和完结键范畴决定。它在不同的 TiKV 节点上领有 3 个或更多的正本，并通过 raft 协定进行同步。在旧的 raft 引擎中，每个 TiKV 中只有一个 RocksDB 实例用于存储所有 Region 的数据。partitioned-raft-KV 个性引入了一个新的物理数据布局：每个 Region 都有本人的 RocksDB 实例。
图 2：物理数据布局比拟
旧 Raft KV 引擎面临的挑战
“Region” 是 TiKV 中的逻辑规模单元。每个数据拜访和治理操作，如负载平衡、扩大和放大都由 Region 进行分区。然而，在以后架构中，它是一个纯逻辑概念，物理上没有清晰的区域边界。这意味着：
- 当须要将一个 Region 的数据从一个 TiKV 挪动到另一个 TiKV（也称为负载平衡）时，TiKV 须要在微小的 RocksDB 实例中进行扫描以获取该 Region 的数据。这造成了读扩充。
- 当几个 Region 具备大量的写流量时，如果它们的键范畴扩散，那么很可能会触发 RocksDB 中的大型压缩，其中包含其余闲暇 Region 的数据。这引入了读和写扩充。例如，SST11 是一个 1MB 大小的 SST，只有 region1 的数据，但蕴含相当大的键范畴。当它被选中合并到 L2 时，SST21、SST22 和 SST23 都参加了压缩，它们蕴含了 region2、3、4 的数据。TiKV 的规模越大，读写扩充越大。
图 3：不同 Region 之间的压缩数据
- 没有 Region 隔离，因而多数热门 Region 可能会拖慢所有 Region 的性能。
因而，在旧的 raft KV 引擎中，咱们可能会遇到以下问题：
- 扩所容的速度很慢，因为须要屡次数据扫描。
- 因为 RocksDB 的写组是单线程的，因而写吞吐量受到限制。
- 因为数据压缩会不断产生，当 RocksDB 的数据量很大时，用户流量的提早不稳固。
Partitioned Raft KV 引擎的改良
- 每个 Region 的数据都是一个专用的 RocksDB 实例，因而只需将 RocksDB 进行 x-copy 以进行 Region 间的负载平衡，防止了读放大的产生。
- 热点 Region 的写入流量只会触发其本人的 RocksDB 的压缩，不波及其余 Region 的数据。因而，它无效地缩小了读和写放大。
- 在将数据写入 RocksDB 时，写入线程之间并不会产生数据同步和锁争用，因为每个线程都在写一个不同的 RocksDB 实例。这样就打消了写入瓶颈。因为没有 WAL 日志，向 RocksDB 的写入是一个内存操作。
- 一个 RocksDB 性能不好并不会影响其余 Region。因而，Region 的性能在存储层面上是隔离的。
- 当初每个 Region 都反对更大的容量，默认状况下为 15 GB。和过来 96MB 的 Region 大小限度相比，心跳和内存占用这一类的 Region 开销降幅高达 99%。
因而，应用 partitioned raft KV，TiDB 在扩大或放大数据方面的速度大概快 5 倍，并且因为压缩的影响要小得多，其性能总体上更加稳固。
适用范围
所有看起来都很好。然而还有一个问题。当初咱们有更多的 RocksDB 实例，因而它们的 memtable 的内存耗费要多得多，这意味着您可能须要额定的 5GB〜10GB 的内存开销能力在内存耗费和性能之间达到均衡。因而，当内存资源曾经十分缓和时，通常不倡议关上此性能。然而，当您在 TiKV 中有额定的内存并关怀可扩展性和写入性能时，这个性能可能会对您有所帮忙。
写在最初
一些客户可能会说以后版本的 TiDB 曾经足够好了。所以新性能对他们来说仿佛并不重要。然而，如果他们能够在一个集群中用于多个工作负载，而且每个工作负载都能够失去良好的隔离和 QoS 保障呢？这就是 7.0 版本中的“资源管控”性能。“partitioned raft KV”性能旨在最大化硬件性能，与“资源管控”一起应用，咱们的客户将可能充分利用其硬件资源，并通过将多个工作负载合并到一个集群中来降低成本。