关于数据库:TiKV-新架构Partitioned-Raft-KV-原理解析

40次阅读

共计 1815 个字符，预计需要花费 5 分钟才能阅读完成。

作者：徐奇

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：物理数据布局比拟

“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 的数据量很大时，用户流量的提早不稳固。

每个 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”性能旨在最大化硬件性能，与“资源管控”一起应用，咱们的客户将可能充分利用其硬件资源，并通过将多个工作负载合并到一个集群中来降低成本。

正文完