BTreeIndex Split Flush method, use bigger resolution #3182
Conversation
kunga
changed the title
|
⚪ |
|
⚪ |
|
⚪
|
|
⚪
|
|
⚪
|
|
⚪
|
kunga
changed the title
| @@ -226,7 +226,7 @@ BENCHMARK_DEFINE_F(TPartFixture, DoCharge)(benchmark::State& state) { | |||
| BENCHMARK_DEFINE_F(TPartFixture, BuildStats)(benchmark::State& state) { | |||
| for (auto _ : state) { | |||
| TStats stats; | |||
| BuildStats(*Subset, stats, NDataShard::gDbStatsRowCountResolution, NDataShard::gDbStatsDataSizeResolution, &Env); | |||
| BuildStats(*Subset, stats, NDataShard::gDbStatsRowCountResolution, NDataShard::gDbStatsDataSizeResolution, NDataShard::gDbStatsResolutionMultiplier, &Env); | |||
There was a problem hiding this comment.
Странновато конечно, что в коде tablet_flat используются переменные из даташардов. Может быть тут конкретные значения указать, зачем из даташардов тянуть?
| ui32 BTreeIndexNodeTargetSize = 7 * 1024; /* 1 GB of (up to) 140B keys leads to 3-level B-Tree index */ | ||
| ui32 BTreeIndexNodeKeysMin = 6; /* 1 GB of 7KB keys leads to 6-level B-Tree index (node size - ~42KB) */ | ||
| ui32 BTreeIndexNodeKeysMax = Max<ui32>(); /* for UTs */ | ||
| ui32 BTreeIndexLeafDataSizeMax = 1024 * 1024; /* gDbStatsDataSizeResolution / gDbStatsResolutionMultiplier */ |
There was a problem hiding this comment.
Я если честно не понимаю зачем. Зачем нам мельчить с размерами страниц индекса? Давай представим, что я храню в таблице uint64 key -> bytes data, и у меня там строки по 4MB. Даже одна data страница будет пробивать этот лимит, как я понял там в итоге накопится 6 ключей (uint64) и будет этакая мелкая leaf страница? А какой в ней смысл в такой мелкой? Мы бы с тем же успехом могли сканировать их на leaf уровне.
| Levels[levelIndex].GetKeysCount() > waitFullNodes * NodeKeysMax || | ||
| CalcPageSize(Levels[levelIndex]) > waitFullNodes * NodeTargetSize || | ||
| levelIndex == 0 && Levels[levelIndex].GetDataSize() > waitFullNodes * LeafDataSizeMax || | ||
| levelIndex == 0 && Levels[levelIndex].GetRowCount() > waitFullNodes * LeafRowsCountMax; |
There was a problem hiding this comment.
Мне кажется для таблиц у которых uint64 key -> uint64 value и на одной странице помещаются сотни строк (или даже больше, если размер data страницы увеличили), по этому условию будут генерироваться индексные страницы всегда по 25-50 ключей вместо пары сотен, они будут всегда существенно меньше 7KB, и это всё-таки слишком мелко. Что-то я не уверен насколько это полезно.
Я думаю тут не нужно как-то специально подгонять индекс под статистику, тут статистику нужно считать по тому, что есть. Сначала очень грубо и с большим uncertainty, зато быстро, и постепенно уменьшая uncertainty (там где это действительно необходимо) пока не дойдём до нужного разрешения или кол-ва ключей.
На разрешении 10MB (и уж тем более 1MB!) тоже свет клином не сошёлся, даташард наоборот разрешение уменьшает если оказывается что ключей слишком много получается (там максимум 100 ключей в гистограмме кажется, и на 2GB это разрешение 20MB). Думаю очень верхнеуровнево можно было бы помержить sst'ки по корню индекса, получилось бы N ключей, но т.к. мержим мы sst разных размеров, и ключи идеально не совпадают, между ключами может получаться большой возможный разброс размеров данных, и вот тут мы пытаемся его уточнить, спускаясь на уровень ниже и выбирая другой более подходящий ключ. Так как нам в итоге нужен максимум 100 ключей, нам в крупных sst скорее всего нужно будет ещё на пару уровней спуститься (если ключи большие, а не uint64) и всё. И вообще лучше не плясать от разрешения 10MB (это хак из расчёта 2GB/100=20MB!), а плясать от необходимого нам кол-ва ключей. Так 2GB делим на 100 - получаем желаемое разрешение 20MB, и если между парой ключей ±5-10MB, то это уже good enough. Но если шард на 10MB, то мы всё-равно на самом деле хотим 100 ключей, просто сейчас из-за хака не можем.
А ещё, мы на самом деле скорее всего даже не хотим 100 ключей. Нам было бы достаточно 10. SchemeShard'у так вообще кроме медианы сейчас больше ничего не нужно.
kunga
force-pushed
the
btree-build-stats-leaves
branch
from
f95c2ef to
7219232
Compare
|
⚪ |
|
⚪ |
|
⚪ |
|
⚪ |
|
⚪ |
|
⚪
|
|
⚪
|
kunga
changed the title
|
⚪
|
|
⚪
|
Changelog entry
...
Changelog category
Additional information
BTreeIndex Split Flush method, use bigger resolution
Before: https://nda.ya.ru/t/G8iQ0UAh759rCW
After: https://nda.ya.ru/t/G8iQ0UAh759rCW