Каково влияние количества уровней в уровневом уплотнении?

LCS решает проблему пространственного усиления STCS. Это также уменьшает усиление чтения (среднее количество операций чтения с диска, необходимых для одного запроса на чтение).

Уровневое уплотнение делит небольшие sstables («фрагменты») на уровни:

Уровень 0 (L0) — это новые sstables, недавно очищенные от memtables. По мере роста их числа (и замедления чтения) наша цель — переместить sstables с этого уровня на следующие уровни. Каждый из других уровней, L1, L2, L3 и т. д., представляет собой единичную серию с экспоненциально растущим размером: L1 – серия из 10 sstables, L2 – серия из 100 sstables, L3 – серия из 1 000 sstables и скоро. (Коэффициент 10 является настройкой по умолчанию как в Scylla, так и в Apache Cassandra).

Решая или, по крайней мере, значительно улучшая проблему пространственного усиления, LCS усугубляет другую проблему — усиление записи.

«Усиление записи» — это количество байтов, которое нам пришлось записать на диск для каждого байта только что сброшенных sstable данных. Усиление записи всегда выше 1,0, потому что мы записываем каждый фрагмент данных в журнал фиксации, а затем записываем его. снова в sstable, а затем каждый раз, когда сжатие включает этот фрагмент данных и копирует его в новый sstable, это еще одна запись.

Об этом подробнее здесь:

• https://www.scylladb.com/2018/01/31/compaction-series-leveled-compaction/
• https://docs.scylladb.com/kb/compaction/
• https://docs.scylladb.com/architecture/compaction/compaction-strategies/

Уровневое уплотнение работает в Scylla очень похоже на то, как оно работает в Cassandra и Rocksdb (с некоторыми небольшими отличиями). Если вам нужен краткий обзор того, как работает уровневое уплотнение в Scylla и почему, я предлагаю вам прочитать мой пост в блоге https://www.scylladb.com/2018/01/31/compaction-series-leveled.-compaction/.

Ваш конкретный вопрос о том, почему двух уровней (L0 недавно очищенных sstables, Ln sstables с непересекающимся диапазоном) недостаточно - это очень хороший вопрос:

Основная проблема заключается в том, что одна сброшенная таблица памяти (sstable в L0), содержащая случайный набор операций записи, часто пересекается всеми sstables в Ln. Это означает перезапись всей базы данных каждый раз, когда сбрасывается новая таблица памяти, и в результате получается супер-огромный объем записи, что совершенно неприемлемо.

Одним из способов значительного (но, возможно, недостаточного) уменьшения этого усиления записи является введение каскада промежуточных уровней L0, L1, ..., Ln. Конечным результатом является то, что у нас есть L(n-1), который составляет 1/10 (скажем) размера Ln, и мы объединяем L(n-1) — ни одного стабильного — в Ln. Это подход, который используется во всех системах, которые вы упомянули.

Совсем другой подход мог бы состоять в том, чтобы не сливать один sstable в Ln, а попробовать сначала собрать большой объем данных, а уже потом сливать в Ln. Мы не можем просто собрать 1000 таблиц в L0, потому что это сделает чтение очень медленным. Скорее, для сбора такого большого количества данных можно было бы использовать сжатие по уровням размера (STCS) внутри L0. Другими словами, этот подход представляет собой «смесь» STCS и LCS с двумя «уровнями»: L0 использует STCS для новых sstables, Ln содержит серию sstables (sstables с непересекающимися диапазонами). Когда L0 достигает 1/10 (скажем) размера Ln, L0 сжимается в Ln. Такой смешанный подход может иметь более низкое усиление записи, чем LCS, но, поскольку большая часть данных выполняется в Ln, у него будет такое же мало места и усиление чтения, как и в LCS. Насколько мне известно, ни одна из упомянутых баз данных (Scylla, Cassandra или Rocksdb) не поддерживает такое «смешанное» сжатие.