не удается даже запустить сервер

которая существует только на этой ноде?

Если она нереплицируемая то должно быть достаточно удалить файлы таблицы в /var/lib/clickhouse/data/ваша_схема/таблица и метаданные /var/lib/clickhouse/metadata/ваша_схема/таблица

По партициям можно тут https://github.com/yandex/ClickHouse/blob/master/docs/ru/table_engines/custom_partitioning_key.md

По партициям можно тут https://github.com/yandex/ClickHouse/blob/master/docs/ru/table_engines/custom_partitioning_key.md

спасибо!

Коллеги, привет. Подскажите есть для кликхауса нечто подобное pgbouncer'у в postgres? чтобы ставить на паузу входящие запроса во время мейнтейнса. Или как это лучше организовать?

Есть chproxy, но, возможно, это не совсем то. Мы на время смены версий/альтеров и прочего просто отключаем запись в шард, после чего по одной машине апдейтим

https://github.com/Vertamedia/chproxy

А так у нас лоадбалансинг и фейловер, воркеры сами найдут рабочую машину, так что выключение не особо критично

Мы haproxy юзаем

Привет. В документации сказано что "В таблицу, содержащую столбцы типа AggregateFunction невозможно вставить строчку обычным запросом INSERT". Я нашел вариант как сделать почти обычный INSERT. https://github.com/yandex/ClickHouse/issues/756 INSERT INTO agg_stats (event_date, company_id, clicks, views) VALUES ('2017-12-01', 1, arrayReduce('sumState', [toUInt32(234)]), arrayReduce('sumState', [toUInt32(1)])) Насколько плохо таким способом постоянно из приложения писать в таблицу с полями AggregateFunction?

Всем привет. Какие есть эффективные способы делать пагинацию? Ведь обычный limit с сортировкой не работает на больших объемах, фильтруя даже за день.

скажите, detach partition - реплицируемая команда?

Всем привет. Какие есть эффективные способы делать пагинацию? Ведь обычный limit с сортировкой не работает на больших объемах, фильтруя даже за день.

если у вас количество строк такое что order by + limit не работает, то что вы там собираетесь читать глазами?

если у вас количество строк такое что order by + limit не работает, то что вы там собираетесь читать глазами?

Я агрегирую сотни тысяч разных значений, которые нужно отдавать постранично глазу или роботу - не имеет смысла. Вопрос был в другом. Может у кого-то есть эффективные способы решения такого. Не думаю, что пагинацию с сортировкой я первый использую в кликхаусе

до некоторых пределов она вполне работает, у нас люди пачками по 100к строк выкачивают достаточно длинные ответы

возможно зависит от конкретной ситуации.

Спасибо

скажите, как из бавится от такой ошибки при копировании данных?

Memory limit (for query) exceeded: would use 9.40 GiB (attempt to allocate chunk of 134217728 bytes), maximum: 9.31 GiB.

строки тяжелые?

много данных очень

таблица весит 145Гб

но я пытаюсь только за один месяц данные выбрать

может быть можно как-то скопировать партицию из одной таблицы в аналогичную?

Memory limit (for query) exceeded: would use 9.40 GiB (attempt to allocate chunk of 134217728 bytes), maximum: 9.31 GiB.

Разработка: 003. GROUP BY и Memory limit exceeded Алексей Миловидов

Константин если у вас не с group by проблема, а какой-то другой аггрегацией (sort, join, distinct), то можно почитать про настройки max_bytes_before_external...

да, у меня груп бай используется

вы копируете данные с group by?

А вот есть к примеру 146 миллионов агрегированных разных значений за день. Как мне можно вытащить их по 1000 на страницу? Кто-нибудь с таким сталкивался?

запрос с order by .. limit 1000 сколько работает? и как у вас вообще group by с таким выходом отработал?

Нет. Для данных целей, Materialized View следует создать с Replicated движком на обеих серверах. Тогда вставленные данные на одном сервере, попадут в Materialized View, и будут реплицированы по всем репликам.

В таком случае MV будет реплицироваться из других MV, а не тянуть данные из своей копии реплицируемой t1? Т.е. при вставке данных в t1 на каком-либо сервере, естественным образом пополнится MV на том сервере, но потом из этой MV данные расползутся в реплики этой MV?

запрос с order by .. limit 1000 сколько работает? и как у вас вообще group by с таким выходом отработал?

1000 rows in set. Elapsed: 20.056 sec. Processed 46.09 million rows, 4.51 GB (2.30 million rows/s., 224.97 MB/s.) но это на 46-ти миллионах

В таком случае MV будет реплицироваться из других MV, а не тянуть данные из своей копии реплицируемой t1? Т.е. при вставке данных в t1 на каком-либо сервере, естественным образом пополнится MV на том сервере, но потом из этой MV данные расползутся в реплики этой MV?

Да, MV создает (или использует уже существующую) таблицу для хранения результатов, сам запрос выполняется как "треггер" и перед вставкой в основную таблицу пишет эти данные в таблицу MV

А вот есть к примеру 146 миллионов агрегированных разных значений за день. Как мне можно вытащить их по 1000 на страницу? Кто-нибудь с таким сталкивался?

Мы, наш воркер каждый день в 5 утра разливает данные в агрегированные таблицы

Мы, наш воркер каждый день в 5 утра разливает данные в агрегированные таблицы

все реалтайма хотят :(

Для реалтайма у нас суммирующие матвьюхи для последнего дня

Да, MV создает (или использует уже существующую) таблицу для хранения результатов, сам запрос выполняется как "треггер" и перед вставкой в основную таблицу пишет эти данные в таблицу MV

Не, вопрос был репликацию MV.

Повторю вопрос. Есть ReplicatedMergeTree таблица t1. Хосты A и B - на них её реплики. Нужно сделать MV для t1. Хотел просто создать MV на каждом хосте: думал INSERT INTO t1 на хосте A привезёт блок данных на B, а там сработает триггер и данные вставятся в тамошний MV. Выше сказали что так оно не работает. Хотя это не логично. Пытаюсь понять логику. Надо что, создать MV на движке ReplicatedMergeTree? Тогда путь данных будетA:t1 -> B:t1 и параллельно A:MV -> B:MV ? То есть B:MV никак не триггерится появлением данных в B:t1? Т.е. происходит вот что: 1) insert into A:t1 2) trigger A:MV (данные льются в A:MV) 3) на хосте B сервер понимает что надо скачать кусок A:t1 -> B:t1 4) на хосте B сервер понимает что надо скачать кусок A:MV -> B:MV, никакого триггера на B не срабатывает?

Подскажите, пожалуйста, какой статус у версии 1.1.54318? Здесь она отмечена как релизная: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md Но в чейнджлоге в ветке stable последний релиз - 1.1.54304 https://github.com/yandex/ClickHouse/blob/stable/CHANGELOG.md Это просто чейнджлог в ветке не обновили?

Повторю вопрос. Есть ReplicatedMergeTree таблица t1. Хосты A и B - на них её реплики. Нужно сделать MV для t1. Хотел просто создать MV на каждом хосте: думал INSERT INTO t1 на хосте A привезёт блок данных на B, а там сработает триггер и данные вставятся в тамошний MV. Выше сказали что так оно не работает. Хотя это не логично. Пытаюсь понять логику. Надо что, создать MV на движке ReplicatedMergeTree? Тогда путь данных будетA:t1 -> B:t1 и параллельно A:MV -> B:MV ? То есть B:MV никак не триггерится появлением данных в B:t1? Т.е. происходит вот что: 1) insert into A:t1 2) trigger A:MV (данные льются в A:MV) 3) на хосте B сервер понимает что надо скачать кусок A:t1 -> B:t1 4) на хосте B сервер понимает что надо скачать кусок A:MV -> B:MV, никакого триггера на B не срабатывает?

Еще раз, под MV обычная таблица и именно она реплицируется или нет в зависимости от движка. MV навешивает "триггер" которые выполняет запрос перед вставкой в целевую таблицу. PS: создавайте реплицируемые MV

Повторю вопрос. Есть ReplicatedMergeTree таблица t1. Хосты A и B - на них её реплики. Нужно сделать MV для t1. Хотел просто создать MV на каждом хосте: думал INSERT INTO t1 на хосте A привезёт блок данных на B, а там сработает триггер и данные вставятся в тамошний MV. Выше сказали что так оно не работает. Хотя это не логично. Пытаюсь понять логику. Надо что, создать MV на движке ReplicatedMergeTree? Тогда путь данных будетA:t1 -> B:t1 и параллельно A:MV -> B:MV ? То есть B:MV никак не триггерится появлением данных в B:t1? Т.е. происходит вот что: 1) insert into A:t1 2) trigger A:MV (данные льются в A:MV) 3) на хосте B сервер понимает что надо скачать кусок A:t1 -> B:t1 4) на хосте B сервер понимает что надо скачать кусок A:MV -> B:MV, никакого триггера на B не срабатывает?

на B не срабатывает триггера, потому что там нет инсертов, данные туда попадают с помощью зукипера

Подскажите, пожалуйста, какой статус у версии 1.1.54318? Здесь она отмечена как релизная: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md Но в чейнджлоге в ветке stable последний релиз - 1.1.54304 https://github.com/yandex/ClickHouse/blob/stable/CHANGELOG.md Это просто чейнджлог в ветке не обновили?

Она релиз, но говорят там есть проблемы с репликацией

если на B будет реплицированная MV, то в нее приедут данные из A:MV

на B не срабатывает триггера, потому что там нет инсертов, данные туда попадают с помощью зукипера

Вот так понятнее. Не хватало понимания, что триггеры триггерятся только INSERT-ами, а не привозом данных другими путями.

именно

я так тоже сначала не понимал

А в ZooKeeper физически что хранится? Не сами же данные, а какие-то позиции реплика-логов или чего-то такого? Я так понимаю просто перечисления блоков. Блоки сольются - инфа про старые блоки = фтопку, запишется инфа про новые. Или запишется некая команда "слей такие-то блоки" и сервер B независимо сделает ту же операцию, не скачивая данных с A?

ну как я понимаю, зукипер физически реплицирует, а не логически

дальше не копал

Немного оффтоп, а в чём фишка юзать именно ZooKeeper, почему не какой-нибудь другой простейший key=value? Запилили бы некий режим в clickhouse-server, который умеет key=value и юзали бы его в качестве зоокипера.

Она релиз, но говорят там есть проблемы с репликацией

Спасибо. А не подскажете ещё, кто говорит, и что за проблемы? В этом чатике?

Лучше переехать, но в 54318 обнаружены довольно серьёзные ошибки с репликацией (впрочем, кажется, они присутствуют и в 54310). Сейчас готовим фиксы.

Немного оффтоп, а в чём фишка юзать именно ZooKeeper, почему не какой-нибудь другой простейший key=value? Запилили бы некий режим в clickhouse-server, который умеет key=value и юзали бы его в качестве зоокипера.

запилите :) там же не просто переброска данных, реплики сами умеют понимать, что данных у них не хватают, сами подсасывают что надо, восстаналиваются... тут недавно гифка была, "сложно б..ть, сложно", вот ее сюда

Кстати да, @ztlpn что за проблемы с репликацией ? Просто мы как пару недель на 54318 и нас пока не зацепило, но т.к. скоро рождественские каникулы не очень хочется чтоб что-то внезапно накрылось )

@Shegloff ну я так понимаю, каждая реплика просто раз в секунду долбится в zookeeper и говорит "давай новости". Тот ей список актуальных блоков. Реплика смотрит - оба, а вот этого блока у меня ещё нет, пойду стяну с других.

может быть оно так и есть, я не в курсе просто

я когда не настроил автоочистку в зукипере, там были сотнит гигов, вряд ли это просто номера блоков

Хм, а эти "проблемы" не приводят к "дублированию " и "потере" данных даже при переливке данных внутри КХ?

Мы уже третий день на крайней версии пытаемся понять куда исчезают данные

Причём количество потерь прямо пропорционально скорости вставки

А ваши потери в detached не падают случаем?

Ну вот сейчас очередной раз экспериментируем со структурой таблицы посмотрим

у нас объём около 8 миллиардов строк, теряется от 10 миллионов до 50 тысяч

https://github.com/yandex/ClickHouse/issues/1504 я похоже тоже наблюдал

Кстати да, @ztlpn что за проблемы с репликацией ? Просто мы как пару недель на 54318 и нас пока не зацепило, но т.к. скоро рождественские каникулы не очень хочется чтоб что-то внезапно накрылось )

Иногда реплика может посчитать, что у неё нет куска, которого в неё только что вставили, а если совсем не повезёт, и удалить его через некоторое время. Есть ли проблема, можно понять, поискав в логе Part <имя_куска> from own log doesn't exist. (это плохо), и Part <имя_куска> exists in ZooKeeper but not locally. Removing from ZooKeeper and queueing a fetch. (это хуже - после этого кусок через некоторое время попадает в detached).

Похоже именно на это мы наткнулись

и сидим мы на 1.1.54318

Фикс на этой неделе постараемся зарелизить (до каникул уж точно :))

Фикс на этой неделе постараемся зарелизить (до каникул уж точно :))

Спасибо ) Не терпится уползти с Вертики

Иногда реплика может посчитать, что у неё нет куска, которого в неё только что вставили, а если совсем не повезёт, и удалить его через некоторое время. Есть ли проблема, можно понять, поискав в логе Part <имя_куска> from own log doesn't exist. (это плохо), и Part <имя_куска> exists in ZooKeeper but not locally. Removing from ZooKeeper and queueing a fetch. (это хуже - после этого кусок через некоторое время попадает в detached).

У нас такого нет, пока везёт

@ztlpn А почему так бывает? Есть какие-то условия чтоб не влететь на них ?

Если ответ от ZK затупит, то может случиться. Обычный race condition.

Тогда странно что нас не заафектило, у нас редко, но бывают проблемы с ZK

@Shegloff ну я так понимаю, каждая реплика просто раз в секунду долбится в zookeeper и говорит "давай новости". Тот ей список актуальных блоков. Реплика смотрит - оба, а вот этого блока у меня ещё нет, пойду стяну с других.

Примерно так и происходит. В ZooKeeper хранится информация о наборе кусков на репликах (собственно сами имена кусков и чексуммы, данные естественно не хранятся) и очередь заданий на репликацию вида "скачай новый кусок", "сделай мерж вот такого набора кусков", на которую подписываются реплики. Ситуация осложняется тем, что иногда выгоднее скачать сразу покрывающий кусок, а не маленький, и не мержить самому, а скачать готовый кусок с реплики (но не всегда). Поллинга там нет, так как в ZK есть механизм вотчей - можно подписываться на изменения по ключам и получать уведомления. Почему именно ZK - это сторадж, который даёт сильные гарантии (http://zookeeper.apache.org/doc/current/zookeeperOver.html#Guarantees), необходимые для координации распределённых процесов. Например, какая-нибудь монга таких гарантий не предоставляет. Разумеется, ZK не один такой, просто он один из самых старых и battle-tested.

я надеюсь вы запилите другие движки типа etcd/consul

тем более есть уже библиотеки типа libkv

просто для запуска в том же kubernetes ( где есть etcd уже по дефолту) станет сильно легче, а то сейчас надо городить кластер zookeeper сначала

ага, на го

хипсторы вообще долбанулись со своими странными языками

с этим невозможно жить

а zookeeper на ява

Для реалтайма у нас суммирующие матвьюхи для последнего дня

А когда данные нужно вытащить за последний день и за еще 6 дней последних, в сумме отсортировав их, вы как поступаете? Или таких задач не было?

вопрос не в технологии под капотом, а в том что etcd пилят постоянно и качество его растет

я когда не настроил автоочистку в зукипере, там были сотнит гигов, вряд ли это просто номера блоков

ZK с дефолтными настройками вечно хранит снапшоты данных - а он их делает периодически :) То есть данные фактически хранятся по многу раз, отсюда и сотни гигов.

А когда данные нужно вытащить за последний день и за еще 6 дней последних, в сумме отсортировав их, вы как поступаете? Или таких задач не было?

SELECT * FROM (SELECT * FROM realtime UNION SELECT * FROM ...) ORDER BY как-то так

Скажите, такой вопрос: у нас сейчас стоит версия КХ - без возможности указания ключа партиционирования, если мы обновим все ноды, можно ли будет у существующих таблиц - сменить ключ партиционирования?

Скажите, такой вопрос: у нас сейчас стоит версия КХ - без возможности указания ключа партиционирования, если мы обновим все ноды, можно ли будет у существующих таблиц - сменить ключ партиционирования?

нет, только пересоздав

тем более есть уже библиотеки типа libkv

Libkv на го, поэтому нам её будет сложно использовать :) Ну и когда используешь абстрактную обёртку над стораджами, к багам в стораджах добавляются баги в обёртке и становится в 2 раза веселее. К ZK у меня лично чуть больше доверия, достаточно сравнить https://aphyr.com/posts/291-call-me-maybe-zookeeper и https://aphyr.com/posts/316-call-me-maybe-etcd-and-consul, хотя сейчас наверняка большинство багов у них уже поправлено. В общем, какой сервис распределённой координации использовать это старый флейм и мы про него помним и помним, что не всем ZK удобен.

я понимаю что это процесс долгий, но вдруг вы потихоньку подпиливаете внутренние интерфейсы в сторону их унификации чтоб потом можно было поменять storage

по крайней мере без zoo шаблоны для быстрого развертывания в кластерах станут сильно проще

Добрый день , есть забавная задача. Вот сама таблица CREATE TABLE IF NOT EXISTS trade_history ( EventDate Date, Timestamp UInt64, Exchange String, Pair1 String, Pair2 String, Price Float64, Amount Float64, Time DateTime ) ENGINE = MergeTree(EventDate, (Exchange, Timestamp, Pair1, Pair2, Price, Amount, Time), 8192); К ней есть запрос типа SELECT MAX(Price), MIN(Price), SUM(Amount), Pair1, Pair2 FROM trade_history WHERE (EventDate >= '2017-11-23' AND EventDate <= '2017-11-30') AND (Timestamp >= 1511447283790628020 AND Timestamp <= 1512052083790628020) GROUP BY toStartOfHour(Time), Pair1, Pair2 Вопрос как получить первый Price и последний Price к каждой группе toStartOfHour(Time), Pair1, Pair2 Надо построить график OHLCV(Японские свечи). Для этого надо 5 параметров O - Open(Первый Price в временном промежутке) H - High(Самый высокий Price за весь промежуток) L - Low (Самый низкий Price за временной промежуток) C - Close (Последний Price за временной промежуток) V - Volume (Сума всех Amount) Хотелось бы сделать все в один запрос чтоб не гонять дата сет в 1.5 ккк записей.

Первую можно как-то так: where rowNumberInAllBlocks() = 1 order by time

Добрый день , есть забавная задача. Вот сама таблица CREATE TABLE IF NOT EXISTS trade_history ( EventDate Date, Timestamp UInt64, Exchange String, Pair1 String, Pair2 String, Price Float64, Amount Float64, Time DateTime ) ENGINE = MergeTree(EventDate, (Exchange, Timestamp, Pair1, Pair2, Price, Amount, Time), 8192); К ней есть запрос типа SELECT MAX(Price), MIN(Price), SUM(Amount), Pair1, Pair2 FROM trade_history WHERE (EventDate >= '2017-11-23' AND EventDate <= '2017-11-30') AND (Timestamp >= 1511447283790628020 AND Timestamp <= 1512052083790628020) GROUP BY toStartOfHour(Time), Pair1, Pair2 Вопрос как получить первый Price и последний Price к каждой группе toStartOfHour(Time), Pair1, Pair2 Надо построить график OHLCV(Японские свечи). Для этого надо 5 параметров O - Open(Первый Price в временном промежутке) H - High(Самый высокий Price за весь промежуток) L - Low (Самый низкий Price за временной промежуток) C - Close (Последний Price за временной промежуток) V - Volume (Сума всех Amount) Хотелось бы сделать все в один запрос чтоб не гонять дата сет в 1.5 ккк записей.

А ещё вот эту функцию посмотрите: https://clickhouse.yandex/docs/ru/single/#argmax-arg-val

Первую можно как-то так: where rowNumberInAllBlocks() = 1 order by time

Да, вот это даже не нужно тут