Влияние большого количества удалений / перезаписей на ключ в YugabyteDB довольно минимально.
YugabyteDB использует механизм хранения на основе LSM (дерева слияния журналов). Таким образом, это правда, что операции чтения должны потенциально обращаться к нескольким файлам SSTable перед отправкой ответа, а сжатия периодически уменьшают количество файлов SSTable, чтобы сохранить минимальные накладные расходы на чтение.
На самом деле количество SSTable файлы могут оказывать чуть более доминирующее влияние на производительность, чем количество перезаписей ключей. [Но и здесь использование фильтров Блума помогает минимизировать количество файлов SSTable, к которым нужно обращаться для чтения.]
Причина, по которой влияние большого количества перезаписей на ключ довольно минимальна в YugabyteDB является кратным:
Операция чтения в механизме LSM выполняется путем логического слияния memtables / SSTables, которые отсортированы в порядке убывания меток времени для каждого ключа. По сути, чтение сначала увидит последнее значение строки, а накладные расходы на удаление (которые отображаются далее в порядке логической сортировки) вообще не должны наблюдаться на практике.
Сбросам и незначительным уплотнениям нужно только сохранить последнее удаленное / перезаписанное значение, а все другие перезаписи могут быть немедленно собраны мусором. Это не должно ждать крупного уплотнения. В отличие от Apache Cassandra, которая в конечном итоге выполняет непротиворечивую репликацию и, следовательно, чтобы избежать проблемы повторной обработки удаленных значений, должна сохранять удаленные надгробия гораздо дольше, в YugabyteDB (которая использует протокол Raft для репликации), для удаления не требуется никакой специальной такой обработки .
Наконец, вот пример программы, которую я пробовал против 2.0.10.0 на кластере RF = 1.
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