在 YugabyteDB 中删除逻辑删除对性能有影响吗？

Question

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

Answer 1

大量deletes/overwrites对一个key的影响还是蛮大的 YugabyteDB 中的最小值。

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

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

在 YugabyteDB 中大量覆盖键的影响非常小的原因是多方面的：

LSM 引擎中的读取操作是通过对 memtables/SSTables 进行逻辑合并来完成的，这些逻辑合并按每个键的时间戳降序排列。实际上，读取将首先看到该行的最新值，而删除的开销（在逻辑排序顺序中进一步向下显示）在实践中根本不应该被观察到。
Flushes和minor compactions只需要保留最新的deleted/overwritten值，所有其他的overwrites可以立即被垃圾回收。这不需要等待主要压缩。与 Apache Cassandra 不同，Apache Cassandra 执行最终一致的复制，因此，为了避免已删除值的问题，重现必须保留已删除的逻辑删除更长时间，在 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

在 YugabyteDB 中删除逻辑删除对性能有影响吗？

Is there a performance impact of delete tombstones in YugabyteDB?

yugabyte-db