1

我们有高吞吐量用例（TPS 为 50k，或每小时 180M txn）；每小时约有 15-30 百万次这些操作被删除。鉴于 YugabyteDB 是一个日志结构化数据库，并且仅在压缩时才回收覆盖的数据，那么读取性能会受到什么影响？

4

1 回答 1

2

在 YugabyteDB 中，对键进行大量删除/覆盖的影响非常小。

YugabyteDB 使用基于 LSM（日志结构合并树）的存储引擎。因此，确实在提供答案之前读取必须潜在地查阅多个 SSTable 文件，并且压缩会定期不断减少 SSTable 文件的数量以保持读取开销最小。

事实上，SSTable 文件的数量对性能的影响可能比键覆盖的数量稍微大一些。[但在这里，布隆过滤器的使用也有助于最大限度地减少阅读时需要查阅的 SSTable 文件的数量。]

在 YugabyteDB 中，大量覆盖对密钥的影响很小的原因是多方面的：

  • LSM 引擎中的读取操作是通过对每个键按时间戳降序排序的 memtables/SSTables 进行逻辑合并来完成的。实际上，读取将首先看到行的最新值，并且在实践中根本不应该观察到删除的开销（在逻辑排序顺序中进一步显示）。

  • 刷新和次要压缩只需要保留最新的删除/覆盖值，所有其他覆盖都可以立即被垃圾回收。这不需要等待一个主要的压缩。与 Apache Cassandra 不同，后者进行最终一致的复制，因此，为了避免删除值重新显示的问题，必须将已删除的 tombstone 保留更长时间，在 YugabyteDB（使用 Raft 协议进行复制）中，删除不需要特殊的此类处理。

最后，这是我在 RF=1 集群上针对 2.0.10.0 尝试的示例程序。

https://gist.github.com/kmuthukk/f93a5373dbaddd4e49427cc7b4130427

该程序首先$iters对每个键进行多次覆盖（默认为 25 次）（首先删除它们，然后再将它们插入回去）。并测量读取时间。平均读取延迟约为 0.35 毫秒。将 $iters 更改为 1 或 50 不会对读取延迟产生任何显着影响。

$iters=1
Read ops per sec: 2836.8794326241
Avg read latency (ms): 0.35

$iters=25
Read ops per sec: 2857.1428571429
Avg read latency (ms): 0.35

$iters=50
Read ops per sec: 2836.8794326241
Avg read latency (ms): 0.35
于 2020-01-19T06:14:34.213 回答