AK
А где этот размер посмотреть? А то я понял, чтоне очень знаю
думаю что в спеках амазоновских машин. Ну по дефолту это 8-16-32-64 МБ, соответственно page_size должен быть степень двойки
Size: a a a
2020 June 25
YS
Нужно бежать не с начала, а с последнего запомненного.
AP
думаю что в спеках амазоновских машин. Ну по дефолту это 8-16-32-64 МБ, соответственно page_size должен быть степень двойки
Мы на своем железе
AK
Кажется я догадываюсь: т.к. это LSM, то что происходит:
- в первый раз пробегаем 1000 таплов и удаляем их.
- это вставляет 1000 "надгорбий" (tombstones)
- второй раз пробегаем 1000 надгробий + 1000 живых таплов. Вставляем ещё 1000 надгробий.
- втретий раз пробегаем 2000 надгробий + 1000 живых таплов...
В общем O(N^2)
- в первый раз пробегаем 1000 таплов и удаляем их.
- это вставляет 1000 "надгорбий" (tombstones)
- второй раз пробегаем 1000 надгробий + 1000 живых таплов. Вставляем ещё 1000 надгробий.
- втретий раз пробегаем 2000 надгробий + 1000 живых таплов...
В общем O(N^2)
А потом запускается компакшен (потому что количество надгробий+ количество живых таплов превысило run_size) и кладём перф)
YS
А потом запускается компакшен (потому что количество надгробий+ количество живых таплов превысило run_size) и кладём перф)
Перф кладётся ещё до этого. Компакшн видимо ещё какой-то спец-эффект добавляет.
DS
интересная гипотеза
AK
Мы на своем железе
Тогда должны знать какие у вас диски + вы можете покрутить настройки буферизации ОС
AP
Я железом не очень занимаюсь, но посыл понял., разберемся с этим, спасибо
AP
Нужно бежать не с начала, а с последнего запомненного.
Итератор по умолчанию так будет бежать? или как это мне сделать? Что-то я растерялся?
AK
vinyl_range_size фактически влияет на частоту запуска компакшена
AK
Т.е. берёте ваш рпс и считаете сколько у вас нарастает записей скажем за час, если хотите компакшен раз в час
AK
Компакшен перезаписывает все данные, поэтому время его выполнения будет зависеть только от размера данных, соответственно чем чаще его запускаете тем больше страдаете по времени
YS
vinyl_range_size фактически влияет на частоту запуска компакшена
Я считаю, vinyl_range_size нужно делать поменьше, чтобы накапливалось поменьше tombstone. Возможно даже, единицы мегабайт. Но я не знаю, как тарантул в таком режиме работать будет.
YS
Итератор по умолчанию так будет бежать? или как это мне сделать? Что-то я растерялся?
Запоминай последний таймстэмп в цикле по индексу, и в следующий раз начинай итерироваться с него.
Изредка начинай итерацию с начала на случай, если кто ttl в прошлое поставил.
Изредка начинай итерацию с начала на случай, если кто ttl в прошлое поставил.
AK
Я считаю, vinyl_range_size нужно делать поменьше, чтобы накапливалось поменьше tombstone. Возможно даже, единицы мегабайт. Но я не знаю, как тарантул в таком режиме работать будет.
Будет зависеть от vinyl_run_count_per_level и vinyl_run_size_ratio, причём больше от последнего
YS
Будет зависеть от vinyl_run_count_per_level и vinyl_run_size_ratio, причём больше от последнего
для этого индекса vinyl_run_count_per_level точно нужно делать 1. А vinyl_run_size_ratio побольше. Тогда LSM станет апроксимацией BTREE.
AK
чем больше эти числа, тем хуже чтение и тем лучше запись
AK
Ну да
YS
TTL индекс - худший кейс для LSM. Так что, лучше сделать его максимально похожим на BTREE.
AK
для этого индекса vinyl_run_count_per_level точно нужно делать 1. А vinyl_run_size_ratio побольше. Тогда LSM станет апроксимацией BTREE.
при единице плохо будет с компакшеном кмк, если хотим btree то надо ставить 2