M
ну тогда правильно. Остальные методы будут нагибать мердж, особенно если рефандов много и они падают в большое временное окно, будут постоянно мерджиться разные куски.
Size: a a a
2020 July 24
AS
Ок спасибо за помощь
DC
В день 50-60к прибавляется
КХ-то вам зачем? Возьмите mysql
AS
Для графиков, сегментирование фильтрация и тд
AS
Быстро же
AS
Ну и сами транзакции у нас лежат в PG, КХ только для графиков
VB
я бы ReplacingMergeTree использовал
order by transaction_id и передавал бы DateTime как
order by transaction_id и передавал бы DateTime как
ver чтобы схлопывать по дате измененияDC
Ну и сами транзакции у нас лежат в PG, КХ только для графиков
ну раз в сутки переливайте в КХ из PG все 7млн. в финальном виде
VB
правда объем действительно не сильно большой
AS
ну раз в сутки переливайте в КХ из PG все 7млн. в финальном виде
Хорошая идея
AS
Но количество растёт
DC
Но количество растёт
КХ это бульдозер, с ним один геморрой, который у вас уже явно вылез, а вам лопаты хватит.
Y
Скажите пожалуйста, кто-нибудь использовал n-gram индексы в ClickHouse? (конкретно я хочу попробовать, насколько n-gram индексы ускоряют выборку по запросам вроде LIKE '%...%'). Добавил такой индекс: ngrambf_v1(3, 512, 2, 0). Выполняю OPTIMIZE TABLE ... FINAL, чтобы индекс полностью материализовался, но процесс идет медленно (10-20 Мб/сек чтение и запись с диска, 0% iowait) и сервер ClickHouse показывает загрузку CPU почти ровно 100% (при этом на сервере 4 ядра, то есть я ожидаю, что будет 400%). В таблице всего одна партиция.
Y
Та же таблица без n-gram индекса мержилась намного быстрее и не упиралась в одно ядро.
AK
Ну, может потом быстро читать будешь )
D
Скажите пожалуйста, кто-нибудь использовал n-gram индексы в ClickHouse? (конкретно я хочу попробовать, насколько n-gram индексы ускоряют выборку по запросам вроде LIKE '%...%'). Добавил такой индекс: ngrambf_v1(3, 512, 2, 0). Выполняю OPTIMIZE TABLE ... FINAL, чтобы индекс полностью материализовался, но процесс идет медленно (10-20 Мб/сек чтение и запись с диска, 0% iowait) и сервер ClickHouse показывает загрузку CPU почти ровно 100% (при этом на сервере 4 ядра, то есть я ожидаю, что будет 400%). В таблице всего одна партиция.
зависит от локальности данных (т.е. насколько однородные данные в блоке)
D
Скажите пожалуйста, кто-нибудь использовал n-gram индексы в ClickHouse? (конкретно я хочу попробовать, насколько n-gram индексы ускоряют выборку по запросам вроде LIKE '%...%'). Добавил такой индекс: ngrambf_v1(3, 512, 2, 0). Выполняю OPTIMIZE TABLE ... FINAL, чтобы индекс полностью материализовался, но процесс идет медленно (10-20 Мб/сек чтение и запись с диска, 0% iowait) и сервер ClickHouse показывает загрузку CPU почти ровно 100% (при этом на сервере 4 ядра, то есть я ожидаю, что будет 400%). В таблице всего одна партиция.
OPTIMIZE TABLE ... FINAL необязательно было делать
есть команда INDEX MATERIALIZE...
есть команда INDEX MATERIALIZE...
YV
Сорян глюк
Y
Ну, может потом быстро читать будешь )
Пока что вижу только такое:
Index
Index
body_idx has dropped 0 granules.