M
То есть особенность моего подхода в том, что я буду интенсивно записывать сразу во множество партиций, нежели в одну текущую.
Size: a a a
2020 June 03
SD
Насколько я знаю, во много партиций сразу писать не очень рекомендуется, скорее всего, это будет медленнее. Кроме того, есть ограничение дефолтное на возможность записать за раз в максимум 100 партиций
M
Спасибо. Надо попробовать. Одновременно 100 партиций — это, пожалуй, перебор. Но у меня особенность генератора данных — он генерит сразу все данные по одному юзеру за всю историю его сессий, пишет в бд, затем переходит к другому, из-за этого и затрагивается сразу много партиций.
AT
ну они не сразу а во время мержа у вас будут затронуты потому что сортировка идет по ключу следовательно надо пересортировать, ну а там зависит уже от скорости дисков, размера данных
A
Подскажите пожалуйста, будет ли для кликхауса разница (в основном интересует скорость индексации или ещё какие-то ньюансы, которые могут возникнуть), буду я делать записи в рамках примерно одинакового таймфрейма (CreatedAt записей монотонно увеличивается) или буду добавлять пачками записи, где CreatedAt будет размазан, например, сразу на год? К примеру, есть действия пользователя. Обычно они пишутся по факту возникновения. Но мне нужно записать в бд сразу все действия пользователя, сделанные за год.
Зависит от партиционирования и ключа сортировки.
Если данные сортированные льются, мержи будут проходить быстрее.
Что касается партиций, если сразу льете во множество, то будет создаваться по парту на каждую партицию, это будет достаточно сильно влиять на IO.
Если данные сортированные льются, мержи будут проходить быстрее.
Что касается партиций, если сразу льете во множество, то будет создаваться по парту на каждую партицию, это будет достаточно сильно влиять на IO.
M
Интересно. Попробую ещё в самом генераторе организовать временное окно, но это сильно много памяти потребуется.
AT
в клике есть временные окна - buffer tables )) оттуда можно вставлять отсортированными
M
Почитал, это чуть другое. Буферизировать я могу в генераторе, я это и делаю. Я имел в виду, что мне нужно в идеале писать всё во временном окне/в одной партиции, чтобы работало, как в реальности, а для этого нужно хранить все сессии всех пользоватей в памяти, что очень и очень накладно.
AT
вы можете вставлять в буферную таблицу в каком угодно порядке, а когда оттуда вычитываете через INSERT INTO SELECT делаете ORDER BY по ключу
AT
имхо это сильно проще чем делать это в генераторе
AT
да и в общем и целом мне кажется стоит просто попробовать вставить в клик как вам удобно - возможно что на ваших объемах / железе вы и не почувствуете разницы
ДА
здравствуйте, подскажите, можно ли запросить выборку из определенной партиции? мне известно примерное время, однако, при запросе
оно лопатит все данные, хотя логика подсказывает, что можно искать в партиции за данный месяц
where time='2019-06-18 16:03:18' оно лопатит все данные, хотя логика подсказывает, что можно искать в партиции за данный месяц
SC
а какой order by/primary key у таблицы?
ДА
гм, не указываю при запросе, есть разница?
SC
не, у самой таблицы
ДА
в структуре? date
ДА
ENGINE = MergeTree(date, (---, --, --), 8192)
S
ну поскольку у вас переход на новую версию
то это уже новые инстансы кликхауса и поэтому у вас уже новые метрики с новыми labels показываются, не важно где это хранится
а насчет того что показатели упали, ну это же к вашему clickhouse запросы идут
вы их в приложении никак не можете проверить? чтобы точно знать,
возможно эти вещи никак не связаны
то это уже новые инстансы кликхауса и поэтому у вас уже новые метрики с новыми labels показываются, не важно где это хранится
а насчет того что показатели упали, ну это же к вашему clickhouse запросы идут
вы их в приложении никак не можете проверить? чтобы точно знать,
возможно эти вещи никак не связаны
SC
добавляйте тогда в запрос ещё where date='2019-06-18'
ДА
ага, тогда оно по немувыберет :) класс. спасибо, попробую