Y
На запросы с LIKE, на запросы на конкретное совпадение и т.д...
Size: a a a
2020 July 24
Y
Видимо, размер блум-фильтра для отзывов на Amazon надо брать побольше (я использую отзывы для товаров на амазоне (https://s3.amazonaws.com/amazon-reviews-pds/tsv/index.txt) для моделирования «логов» :))
Y
Пока что вижу только такое:
Index
Index
body_idx has dropped 0 granules.То есть, блум-фильтр вообще никак не помогает :)
Y
средняя длина строки в отзывах Амазона — 324 символа. В целом, в дебаг-логах обычно примерно похоже, разве нет?
D
Пока что вижу только такое:
Index
Index
body_idx has dropped 0 granules.Если дроппед 0 гранулес, только вред от этого индекса
Y
Если дроппед 0 гранулес, только вред от этого индекса
Ну так о чём и речь :)
D
То есть, блум-фильтр вообще никак не помогает :)
Скип индекс помогает в определенных случаях, когда в блоке можно поскипать данные...
D
Т.е. есть у этой колонки корреляция с первичным ключем хорошо.
Есть высокая уникальность построчно - тоже можно блумфильтр
Есть высокая уникальность построчно - тоже можно блумфильтр
Y
Скип индекс помогает в определенных случаях, когда в блоке можно поскипать данные...
У меня было предположение, что индекс по 3граммам позволит ускорить фильтрацию по логам, особенно в случае, когда искомой фразы не содержится в целом блоке
Y
Пока что на датасете из отзывов амазона (которые наверняка имеют не совсем такое же распределение, как в настоящих логах) блум-фильтр на 512 байт на блок из 8196 вообще ничего не дает на различных запросах
Y
Если у кого-то есть открытый датасет настоящих логов с продакшена, которым они готовы поделиться, дайте знать, пожалуйста :)
Y
Кстати говоря, ALTER TABLE amazon MATERIALIZE INDEX для ngrambf_v1 индекса на одну колонку почему-то тоже упирается в одно ядро...
AK
Кстати говоря, ALTER TABLE amazon MATERIALIZE INDEX для ngrambf_v1 индекса на одну колонку почему-то тоже упирается в одно ядро...
Мутация однопоточная всегда
D
Если у кого-то есть открытый датасет настоящих логов с продакшена, которым они готовы поделиться, дайте знать, пожалуйста :)
Вам в эластиксерч
Y
ngrambf_v1(3, 4096, 2, 0) уже намного лучше себя показывает с амазоновскими отзывами: тот же запрос читает теперь 15.5 Гб вместо 23.2. (Index
body_idx2 has dropped 4301 granules.)Y
(до этого был размер блум-фильтра 512 вместо 4096)
Y
Попробую ещё увеличить размер блум-фильтра :)
Y
Наверняка есть какая-то формула для расчета, какого размера нужен блум-фильтр, если известно количество элементов, но мне лень считать, сколько это получится
AZ
Наверняка есть какая-то формула для расчета, какого размера нужен блум-фильтр, если известно количество элементов, но мне лень считать, сколько это получится
D
Наверняка есть какая-то формула для расчета, какого размера нужен блум-фильтр, если известно количество элементов, но мне лень считать, сколько это получится
вы же понимаете что в логах у вас будет не так... ну и это улучшение слишком маленькое, у вас будет много времени потеряно в самом начале при проверке индекса
вообще если вы ищете слова, наверно лучше пробовать tokenbf_v1?
если есть конкретные ключевые слова/паттерны, лучше добавьте bitmap по ним в order-by, скип индекс тогда будет эффективней так как данные с этими словами будут "рядом"
вообще если вы ищете слова, наверно лучше пробовать tokenbf_v1?
если есть конкретные ключевые слова/паттерны, лучше добавьте bitmap по ним в order-by, скип индекс тогда будет эффективней так как данные с этими словами будут "рядом"