там по структуре не очень тривиально всё по идее... условно
- если уровней меньше (скажем 1), то меньше RA (read amp) и в лучшем случае - меньше итоговый WA (т.к. ключ проходит через меньшее число уровней, пока доходит до низа)
- с другой стороны, если уровней меньше, то (как я понимаю) при компакшене может потребоваться переписывать больше таблиц, что, наоборот, повышает WA (это, соответственно, в худшем случае)

если делить размер ssd на 11 итерактивно -- получшь достаточно оптимальное значение для max_bytes_for_level_base

вот это кажется фигня

ну вторая часть в смысле

ну а почему? вот фиганул ты обновление по всему диапазону ключей рандомно

опять же компакшен ну раз в сутки делается -- кого это волнует?

уровень в любом случае не в одном файле лежит, а побит по 64М

нннуууу.............зависит от нагрузки по идее

ну да - отсортированных по ключу. и вот фиганул ты обновление по всему диапазону - и когда ты будешь мержить, ты возьмёшь каждую таблицу с твоего L1 и вольёшь в неё изменённые ключи

а, о господи. на L0 кладётся несколько таблиц что ли

> Compaction triggers when number of L0 files reaches level0_file_num_compaction_trigger, files of L0 will be merged into L1. Normally we have to pick up all the L0 files because they usually are overlapping:

ну без разницы какой у тебя размер уровня, общий объем остается тот же

несколько файлов по 64M

они все не понолитные

я вот про это

вот если у тебя будет крайний случай когда всё на одном уровне

то у тебя в худшем случае он будет перезаписываться целиком всегда

и вот скажем ты поставишь размер уровня 6 гб

т.е. оно все порезанно на кусочки по 64М (по дефолту)