У нас есть вариант использования с высокой пропускной способностью (TPS 50 тыс. или 180 млн транзакций в час); около 15-30 миллионов таких операций в час удаляются. Учитывая, что YugabyteDB представляет собой базу данных с журнальной структурой, а перезаписанные данные восстанавливаются только при сжатии, как это повлияет на производительность чтения?
Влияет ли удаление надгробий в YugabyteDB на производительность?
Ответы (1)
Влияние большого количества удалений/перезаписей ключа в 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
person
Kannan Muthukkaruppan
schedule
19.01.2020
