-
Notifications
You must be signed in to change notification settings - Fork 735
Prefixed vector index: bug fixes #16376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ents + childs from single shard), because constant used instead of real value for table size
|
🟢 |
|
⚪ Test history | Ya make output | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
|
⚪ Test history | Ya make output | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
| const auto shardIndex = buildInfo.Shards.at(shardIdx).Index; | ||
| ev->Record.SetChild(buildInfo.KMeans.ChildBegin + (1 + TableSize) * shardIndex); | ||
| // about 2 * TableSize see comment in PrefixIndexDone | ||
| ev->Record.SetChild(buildInfo.KMeans.ChildBegin + (2 * buildInfo.KMeans.TableSize) * shardIndex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Это чтобы номера не пересекались нужно? Выглядит не очень надёжно :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Да все так.
Ну не очень очевидно как по другому сделать.
| const auto shardIndex = buildInfo.Shards.at(shardIdx).Index; | ||
| ev->Record.SetChild(buildInfo.KMeans.ChildBegin + (1 + TableSize) * shardIndex); | ||
| // about 2 * TableSize see comment in PrefixIndexDone | ||
| ev->Record.SetChild(buildInfo.KMeans.ChildBegin + (2 * buildInfo.KMeans.TableSize) * shardIndex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Не очень понимаю что тут происходит
Вот мы хотим построить индекс, запускаем на каждом шарде prefix kmeans
Запускаем последовательно и TableSize это число строк в шардах слева?
Что значит Y_ASSERT(buildInfo.KMeans.Level == 2), почему уровень второй?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Не очень понимаю что тут происходит
Вот мы хотим построить индекс, запускаем на каждом шарде prefix kmeans
Запускаем последовательно и TableSize это число строк в шардах слева?
Комментарий в другом месте подробный
Что значит Y_ASSERT(buildInfo.KMeans.Level == 2), почему уровень второй?
У нас построение выглядит так.
1ый уровень: построили вторичный индекс для префикса (в covered column запихнули embedding + vector index covered column)
2ой уровень: запустили читая из этого индекса n prefix_kmeans, они будут работать параллельно и важно чтобы их id не пересеклись. К сожалению мы заранее не знаем сколько уникальных префиксов всего и не знаем сколько их на конкретном шарде
| NTableIndex::TClusterId childBegin, NTableIndex::TClusterId child, | ||
| ui32 state, ui64 tableSize) { | ||
| Level = level; | ||
| ParentBegin = parentBegin; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Могу только догадываться что эти числа используются для нумерации кластеров, но явно не хватает какого-то комментария с тем картинкой как они используются и что значат
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ну они не в первый раз возникли)
Вообще идея такая:
У нас есть процесс построения, по сути это цикл в цикле в цикле развернутый в конечный автомат.
циклы выглядят так
for (;level < levels; ++level) {
for (parent = parentBegin; parent < parentEnd; ++parent) {
do something
}
}
parentEnd ~ childBegin (там функции есть, по ним видно)
child/childBegin нужны для удобства, в целом их посчитать можно из Parent+ParentEnd
Бтв
prefixed vector index levels setting транслируется в levels+1 (собственно + 1 уровень на вторичный индекс безусловно)
Changelog category
Description for reviewers