Всем привет, столкнулись с проблемой в кластере (два шарда по две реплики) - данные в таблицы попадают с задержкой в несколько часов. Однако, если начать активно делать select запросы к этим таблицам, то еще не записавшиеся данные начинают быстро "доезжать" в них. Подскажите, пожалуйста, с чем может быть связана такая проблема и как с ней бороться?

Поэтому я и задал этот вопрос. Как в Метрике инетресно. Большая длиная строка фикированной длины или динаическая длина. Что на практике удачнее.

На практике удобнее String - с этим типом работают все функции и я бы поменял на него то, что когда-то сделал FixedString, но не уверен, что не сломаю что-то вне кх, если сделаю alter table... Вероятно, есть проблемы с быстродействием, но до них мне далеко - не тот объём данных.

На практике удобнее String - с этим типом работают все функции и я бы поменял на него то, что когда-то сделал FixedString, но не уверен, что не сломаю что-то вне кх, если сделаю alter table... Вероятно, есть проблемы с быстродействием, но до них мне далеко - не тот объём данных.

У меня сейчас String, но боюсь сделать неверное решение на начальном этапе

@kmarenov опишите подробнее проблему, что значит доезжать, почему раз в несколько часов .

@kmarenov опишите подробнее проблему, что значит доезжать, почему раз в несколько часов .

Данные оказываются в таблицах спустя несколько часов, но если активно делать select-запросы, то еще не записавшиеся данные начинают активнее попадать в таблицы, и разрыв между временем, когда сделана вставка, и временем, когда данные попали в таблицы, начинает быстро сокращаться.

А как вы их вставляете ?

Вставка там вообще мгновенная же, если сразу не миллиарды ложить

Данные оказываются в таблицах спустя несколько часов, но если активно делать select-запросы, то еще не записавшиеся данные начинают активнее попадать в таблицы, и разрыв между временем, когда сделана вставка, и временем, когда данные попали в таблицы, начинает быстро сокращаться.

А как вы проверяете, единичными SELECT-ами?

А как вы их вставляете ?

Единичными insert'ами. В разные таблицы с разной периодичностью, но сильные задержки наблюдаются например на таблице, куда делается менее двух вставок в секунду.

А как вы проверяете, единичными SELECT-ами?

да

а что за движок?)

а что за движок?)

ReplicatedMergeTree и Distributed

а вставляете блобами или по одной записи два раза в секунду ?

это прям спецом наперекор доке чтоль?)) В доке пишут, вставляйте пачками побольше, и в реплицированную таблицу не чаще раза в секунду, а вы по одной строчке несколько раз в секунду?

это как люди в монге начинают реляционность наводить)

это прям спецом наперекор доке чтоль?)) В доке пишут, вставляйте пачками побольше, и в реплицированную таблицу не чаще раза в секунду, а вы по одной строчке несколько раз в секунду?

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

миллион в час это немного, а 2 в секунду так нельзя)

и это может приводить к задержке вставки данных в несколько часов?

я вставляю пачками по 40к записей в среднем, и ниразу не видел таких проблем

и это может приводить к задержке вставки данных в несколько часов?

это особенность CH. Если не хотите делать буффер в приложении, воспользуйтесь BufferEngine у вас вставка тормозит на реиндексации, насколько я понимаю

Если вставлять по одной записи будет жопа, надо поискать слайд от разработчика, где он показывает чем мельче вставляешь данные, тем производительность падает сильнее, при чем в десятки, сотни и тысячи раз.

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

а так на слабельних машинах если одним блобом то где то за 2 часа вставляется 200 миллиардов записей, на быстрой за час

А правда, что в кликхаусе нет способа сконвертировать DateTime в UNIX Timestamp, кроме как CAST(field, Int32) ? Вот тут я не нашел нужной функции: https://clickhouse.yandex/docs/ru/functions/date_time_functions.html

toUnixTimestamp

Функция работает, но почему её нет в доке :)? В любом случае, спасибо.

N-timestamp? Я запилил обычный timestamp с миллисекундами в int64. Но вместе с ним есть ещё поля типа user ID и строка. И без сортировки 0.014ms, а с сортировкой 5s. И вот было бы круто если бы они "лежали в индексе" по убыванию даты. И выдавали те же миллисекунды, так как для логов это практически всегда самая актуальная сортировка по дефолту

Только кликхаус не выдает по умолчанию данные с сортировкой по первичному ключу. У него же много кусков, он без сортировки выдает просто какие-то данные, которые, скорее всего, будут отсортированы по первичному ключу, но не будут самыми свежими. Насколько я могу судить, оптимизации вида «отдать что-то уже отсортированное по первичному ключу» в ClickHouse нет

кликхаус же для расчета циферок

кликхаус же для расчета циферок

Да почему, для логов он тоже подходит. Но надо иметь в виду такие моменты :)

Создал 2 реплицируемые таблицы с движком ReplicatedAggregatingMergeTree. Навешиваю на них MATERIALIZED VIEW. Вопрос: необходимо ли указывать для VIEW тоже реплицируемый движок?

Если хотите их реплицировать то да, нужно

Если хотите их реплицировать то да, нужно

В том то и вопрос, необходимо ли мне их реплицировать? Вы мне советовали использовать при создании "TO" так вот view будут смотреть на реплицируемые таблицы. Если таблицы реплицируються то нужно ли для view тоже репликация.

Сервер1: table 1(ReplicatedMergeTree), table2(ReplicatedAggregatingMergeTree), view to table2 as select table 1

В том то и вопрос, необходимо ли мне их реплицировать? Вы мне советовали использовать при создании "TO" так вот view будут смотреть на реплицируемые таблицы. Если таблицы реплицируються то нужно ли для view тоже репликация.

Да, нужно

Да, нужно

Понял, спасибо

Коллеги, не подскажете, clickhouse-cpp собрать 4.4.7 компилятором реально или забыть про динозаврика этого? (штатный из centos7)

Да, нужно

И еще вопрос, а имя узла для таблицы в ZooKeeper, делать одинаковым и для table и для view? Или должно быть разным?

И еще вопрос, а имя узла для таблицы в ZooKeeper, делать одинаковым и для table и для view? Или должно быть разным?

Так, я просто невнимательно прочитал. Если вы изначально создали реплицируемые таблицы то при создании mat view с TO не нужно указывать ничего

Так, я просто невнимательно прочитал. Если вы изначально создали реплицируемые таблицы то при создании mat view с TO не нужно указывать ничего

отлично

Функция работает, но почему её нет в доке :)? В любом случае, спасибо.

простые toInt32 и toUInt32 тоже работают :) select updated from metrics limit 1; SELECT updated FROM metrics LIMIT 1 ┌─────────────updated─┐ │ 2018-02-19 12:34:51 │ └─────────────────────┘ 1 rows in set. Elapsed: 0.002 sec. :) select toUInt32(updated) from metrics limit 1; SELECT toUInt32(updated) FROM metrics LIMIT 1 ┌─toUInt32(updated)─┐ │ 1519043691 │ └───────────────────┘ 1 rows in set. Elapsed: 0.002 sec. :) select toInt32(updated) from metrics limit 1; SELECT toInt32(updated) FROM metrics LIMIT 1 ┌─toInt32(updated)─┐ │ 1519043691 │ └──────────────────┘ 1 rows in set. Elapsed: 0.002 sec.

Так, я просто невнимательно прочитал. Если вы изначально создали реплицируемые таблицы то при создании mat view с TO не нужно указывать ничего

Кирилл, не подскажете еще, CREATE TABLE t ( column1 AggregateFunction(uniq, UInt64) ... UInt64 это тип данных который будет поступать в агрегационную функцию или который будет хранится? Я создал таблицу с полем sum_field1 AggregateFunction(sum, UInt64) и потом делаю INSERT INTO table1 SELECT sumState(field1). Field1 имеет тип UInt8, там 0 или 1, но при агрегации там может быть число более UInt8. При вставке выдает ошибку: Types must be the same for columns at same position. Column sumState(field1) has type AggregateFunction(sum, UInt8), but column sum_field1 has type AggregateFunction(sum, UInt64).

Так, я просто невнимательно прочитал. Если вы изначально создали реплицируемые таблицы то при создании mat view с TO не нужно указывать ничего

Отвечать не надо, в доке написано "затем типы её аргументов" это значит что будет принимать

Да в документации многие моменты очень слабо описаны, было бы неплохо ее тоже в опенсоурс и пулреквесты принимать

вроде так и есть

Да в документации многие моменты очень слабо описаны, было бы неплохо ее тоже в опенсоурс и пулреквесты принимать

welcome https://github.com/yandex/ClickHouse/tree/master/docs

Так, я просто невнимательно прочитал. Если вы изначально создали реплицируемые таблицы то при создании mat view с TO не нужно указывать ничего

CREATE MATERIALIZED VIEW default.mview TO default.table2 AS SELECT ... FROM table1 Ругается на TO "Expected one of: ON, OpeningRoundBracket, ENGINE, POPULATE, AS, token"

Все таки ENGINE наверно нужно

Может попробовать сделать ATTACH ее

CREATE MATERIALIZED VIEW default.mview TO default.table2 AS SELECT ... FROM table1 Ругается на TO "Expected one of: ON, OpeningRoundBracket, ENGINE, POPULATE, AS, token"

Может быть версия старая и там ещё не поддерживается TO?

такой вопрос когда примерно ожидать в релизе появления запросов UPDATE/DELETE ?

Это сейчас в разработке, мы ориентируемся на Q2.

Может быть версия старая и там ещё не поддерживается TO?

1.1.54289

Доброе утро! 2 вопроса к разработчикам или опытным пользователям CH: 1) Какой тип лучше указывать для domain (динамическая длина или нет, если нет то какая используется в проектах Метрики)? Аналогично, насолько приемлимо хранить URL без указания длины? 2) Максимальный размер записи (все столбцы) около 1500 байт. Размер индекса 130 байт (не включает тектовые данные). Планируется получать данные, идущие подряд от 20 шт. Гранулированность индекса хочу задать 20 кб (всето по умолчанию 8кб). Таким образом, это должно снизить число поднимаемых кусочков, увеличить их рамзер и улучшить сжатие данных. Данный подход верный? Насколько большим можно задавать гранулированность индекса (на практике планиурется получение данных идущих подряд по 200 шт.)?

1. Используйте String. А FixedString стоит использовать лишь тогда, когда строка имеет фиксированную длину по естественным причинам. Пример: значение хэш-функции в бинарном виде; код языка, код валюты. Есть к сожалению распространённый случай, когда по ошибке используют, например, FixedString(1000) для URL. Это не оптимизация, а наоборот - станет только хуже.

1.1.54289

Это старая версия. Вам в любом случае стоит обновиться;)

Доброе утро! 2 вопроса к разработчикам или опытным пользователям CH: 1) Какой тип лучше указывать для domain (динамическая длина или нет, если нет то какая используется в проектах Метрики)? Аналогично, насолько приемлимо хранить URL без указания длины? 2) Максимальный размер записи (все столбцы) около 1500 байт. Размер индекса 130 байт (не включает тектовые данные). Планируется получать данные, идущие подряд от 20 шт. Гранулированность индекса хочу задать 20 кб (всето по умолчанию 8кб). Таким образом, это должно снизить число поднимаемых кусочков, увеличить их рамзер и улучшить сжатие данных. Данный подход верный? Насколько большим можно задавать гранулированность индекса (на практике планиурется получение данных идущих подряд по 200 шт.)?

2. Гранулированность индекса оставьте как рекомендуется - 8192. Это величина в числе строк. Кстати, гранулированность индекса почти не влияет на сжатие, так как для сжатия используются другие размеры. Если интересно, смотрите min_compress_block_size, max_compress_block_size в Settings.h. Менять их тоже не надо.

Привет всем. Кто-то знает, как заставить КХ слать короткий hostname в собственных метриках ?

Есть возможность в <graphite> указать hostname_in_path = false, root_path - нужный вам префикс имени метрики, включая имя хоста. То есть, указать имя вручную. Автоматически использовать короткое имя нет возможности.

Это старая версия. Вам в любом случае стоит обновиться;)

Вы серьезно, из-за этого может не поддерживаться TO. Или шутите?)) я просто почти день убил что бы перегнать стату в агрегированную таблицу и теперь на нее представление не навешивается

Вы серьезно, из-за этого может не поддерживаться TO. Или шутите?)) я просто почти день убил что бы перегнать стату в агрегированную таблицу и теперь на нее представление не навешивается

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%A0%D0%B5%D0%BB%D0%B8%D0%B7-clickhouse-1154310-2017-11-01

фича довольно новая

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%A0%D0%B5%D0%BB%D0%B8%D0%B7-clickhouse-1154310-2017-11-01

Уже лучу к админу

*лечу

Почему зукипер может жаловаться что не может удалить блоки

Got user-level KeeperException в логах ZooKeeper - это нормально и обращать внимание не нужно. Это сообщение возникает, когда мы удаляем ноду, но она не существует. Обычная ситуация, например, при ретраях при удалении ноды.

Всем привет, столкнулись с проблемой в кластере (два шарда по две реплики) - данные в таблицы попадают с задержкой в несколько часов. Однако, если начать активно делать select запросы к этим таблицам, то еще не записавшиеся данные начинают быстро "доезжать" в них. Подскажите, пожалуйста, с чем может быть связана такая проблема и как с ней бороться?

Задержки при репликации или после вставки в Distributed таблицу, никак не связаны с SELECT-ами. Разные данные на последовательно выполняемых одинаковых запросах, могут говорить о том, что запрос приходит на разные серверы - на разные реплики (это нормально, но выбор реплик можно настроить с помощью настройки load_balancing - например, чтобы чаще предпочиталась одна и та же реплика) или в случае неправильной конфигурации кластера может быть так, что в качестве реплик в Distributed таблице прописаны серверы разных шардов. Задержка в несколько часов нетипична. Скорее всего это говорит о накоплении очереди в Distributed таблице. Рекоменудется включить синхронную вставку в Distributed таблицу: insert_distributed_sync = 1, а также посмотреть на саму очередь в файловой системе и на ошибки при отправке данных в логах.

миллион в час это немного, а 2 в секунду так нельзя)

Два батча в секунду - это Ок.

Коллеги, не подскажете, clickhouse-cpp собрать 4.4.7 компилятором реально или забыть про динозаврика этого? (штатный из centos7)

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

Привет! Начал смотреть изучать возможности clickhouse, вопрос по функции sumMap и вообще насколько использование массива в данных выгоднее (или нет) плоской структуры? т.е.: вариант 1 '2018-02-19’, [11,22,33] вариант 2 '2018-02-19’, 1, 11 '2018-02-19’, 2, 22 '2018-02-19’, 3, 33

2. Гранулированность индекса оставьте как рекомендуется - 8192. Это величина в числе строк. Кстати, гранулированность индекса почти не влияет на сжатие, так как для сжатия используются другие размеры. Если интересно, смотрите min_compress_block_size, max_compress_block_size в Settings.h. Менять их тоже не надо.

Спасибо

Накатал больше для себя пост по ansible/aws с репкой на гитхабе. Заодно там в тренировочных целях билдится и ставится кликхауз с зукипером https://strangeqargo.net/2018/02/17/notes-on-ansible-and-aws/

Задержки при репликации или после вставки в Distributed таблицу, никак не связаны с SELECT-ами. Разные данные на последовательно выполняемых одинаковых запросах, могут говорить о том, что запрос приходит на разные серверы - на разные реплики (это нормально, но выбор реплик можно настроить с помощью настройки load_balancing - например, чтобы чаще предпочиталась одна и та же реплика) или в случае неправильной конфигурации кластера может быть так, что в качестве реплик в Distributed таблице прописаны серверы разных шардов. Задержка в несколько часов нетипична. Скорее всего это говорит о накоплении очереди в Distributed таблице. Рекоменудется включить синхронную вставку в Distributed таблицу: insert_distributed_sync = 1, а также посмотреть на саму очередь в файловой системе и на ошибки при отправке данных в логах.

Спасибо за ответ! Подскажите, пожалуйста, где можно очередь на ФС расположена?

Привет! Начал смотреть изучать возможности clickhouse, вопрос по функции sumMap и вообще насколько использование массива в данных выгоднее (или нет) плоской структуры? т.е.: вариант 1 '2018-02-19’, [11,22,33] вариант 2 '2018-02-19’, 1, 11 '2018-02-19’, 2, 22 '2018-02-19’, 3, 33

Это сложный вопрос и ответ зависит от ваших данных и того, какие запросы предполагаются. 1. Если в данных есть мелкие массивы, которые представляют собой какие-то отдельные свойства данных - то массивы как раз подойдут. Пример: список идентификаторов достигнутых целей. 2. Если в данных почти всё содержимое представляет собой массив, и часто нужно анализировать именно элементы этого массива. Например, ваши данные - это события пользователей. Вы рассматриваете следующие варианты: - каждый пользователь в отдельной строке, а свойства событий пользователей - в массивах. Или сделать таблицу, где каждая строка - отдельное событие одного пользователя. Лучше второй вариант - таблица с отдельными событиями.

Спасибо за ответ! Подскажите, пожалуйста, где можно очередь на ФС расположена?

/var/lib/clickhouse ... (path по-умолчанию) ... /data/database/table

Это сложный вопрос и ответ зависит от ваших данных и того, какие запросы предполагаются. 1. Если в данных есть мелкие массивы, которые представляют собой какие-то отдельные свойства данных - то массивы как раз подойдут. Пример: список идентификаторов достигнутых целей. 2. Если в данных почти всё содержимое представляет собой массив, и часто нужно анализировать именно элементы этого массива. Например, ваши данные - это события пользователей. Вы рассматриваете следующие варианты: - каждый пользователь в отдельной строке, а свойства событий пользователей - в массивах. Или сделать таблицу, где каждая строка - отдельное событие одного пользователя. Лучше второй вариант - таблица с отдельными событиями.

Спасибо! я примерно понял направление

Задержки при репликации или после вставки в Distributed таблицу, никак не связаны с SELECT-ами. Разные данные на последовательно выполняемых одинаковых запросах, могут говорить о том, что запрос приходит на разные серверы - на разные реплики (это нормально, но выбор реплик можно настроить с помощью настройки load_balancing - например, чтобы чаще предпочиталась одна и та же реплика) или в случае неправильной конфигурации кластера может быть так, что в качестве реплик в Distributed таблице прописаны серверы разных шардов. Задержка в несколько часов нетипична. Скорее всего это говорит о накоплении очереди в Distributed таблице. Рекоменудется включить синхронную вставку в Distributed таблицу: insert_distributed_sync = 1, а также посмотреть на саму очередь в файловой системе и на ошибки при отправке данных в логах.

Большое спасибо за столь развернутый ответ!

это особенность CH. Если не хотите делать буффер в приложении, воспользуйтесь BufferEngine у вас вставка тормозит на реиндексации, насколько я понимаю

В доках написано Снижения производительности не будет, если: Данные поступают в режиме реального времени.

Это как понимать? Это относится к однострочным данным или только в батчам?

Для примера - у вас есть события какой-то рекламной сети, например, клики и просмотры. Есть два варианта загрузки данных: 1. Каждый некоторый интервал времени (пример, секунда) загружаются данные примерно за этот интервал времени (возможно, с некоторой ограниченной по величине задержкой). То есть, данные записываются в базу с такой скоростью, с какой они появляются. Это называется загрузкой в реальном времени. 2. У вас есть дамп данных и вы решили загрузить его целиком. В этом случае, данные будут загружаться с максимальной возможной скоростью, какую позволяет база. Обычно быстрее реального времени.

Это сейчас в разработке, мы ориентируемся на Q2.

понял, спасибо

Всем привет. Есть база с collapsingmergetree таблицей, размером в 100 гигабайт. Появилась необходимость поднять реплику и возник вопрос - а как собственно происходит синхронизация? Как на реплику отправить 100гигабайт, которые уже есть на мастере?

Если у вас таблица уже имеет тип ReplicatedCollapsingMergeTree, то всё просто: добавление новой реплики делается запросом CREATE TABLE на новом сервере. В параметрах указывается тот же путь таблицы в ZK, но другой идентификатор реплики. После создания, реплика синхронизируется сама - идёт и скачивает все нужные данные. Если таблица просто CollapsingMergeTree (не Replicated) - то посмотрите раздел документации "Преобразование MergeTree в ReplicatedMergeTree".

благодарю! сейчас попробую

Для примера - у вас есть события какой-то рекламной сети, например, клики и просмотры. Есть два варианта загрузки данных: 1. Каждый некоторый интервал времени (пример, секунда) загружаются данные примерно за этот интервал времени (возможно, с некоторой ограниченной по величине задержкой). То есть, данные записываются в базу с такой скоростью, с какой они появляются. Это называется загрузкой в реальном времени. 2. У вас есть дамп данных и вы решили загрузить его целиком. В этом случае, данные будут загружаться с максимальной возможной скоростью, какую позволяет база. Обычно быстрее реального времени.

Спасибо большое! Движок Buffer оказалось умеет все что нужно

Коллеги, здравствуйте, а не подскажите можно ли провернуть следующую схему: 1) Сделать 1 multiif (или его аналог или case ) 2) при его сробатывании - делать не 1 новый столбец а несколько - через обращения к словарям Пример - у меня в таблице типы названия фруктов и его сорт в условии case я проверяю сорт, если он 1 - я забираю отребуты из словаря 1,2.4 Если сорт - 4 - то я забираю другое количество и другие атрибуты из другого словаря (не 1 запрос к словарю, а несколько)

Коллеги, здравствуйте, а не подскажите можно ли провернуть следующую схему: 1) Сделать 1 multiif (или его аналог или case ) 2) при его сробатывании - делать не 1 новый столбец а несколько - через обращения к словарям Пример - у меня в таблице типы названия фруктов и его сорт в условии case я проверяю сорт, если он 1 - я забираю отребуты из словаря 1,2.4 Если сорт - 4 - то я забираю другое количество и другие атрибуты из другого словаря (не 1 запрос к словарю, а несколько)

Штатного средства нет и сомневаюсь что вообще возможно черех sql. А зачем такие сложности?

Штатного средства нет и сомневаюсь что вообще возможно черех sql. А зачем такие сложности?

Что бы не писать много case’ов. Хочется более красивого решения

Что бы не писать много case’ов. Хочется более красивого решения

Так и не пишите. Если запрос должен вернуть разное кол-во столбцов, вармантов два: делать один большой запрос со всеми столбцами (часть из столбцов будет пустыми). Или несколько запросов. Всё таки это sql, разношестность данных это к nosql

Так и не пишите. Если запрос должен вернуть разное кол-во столбцов, вармантов два: делать один большой запрос со всеми столбцами (часть из столбцов будет пустыми). Или несколько запросов. Всё таки это sql, разношестность данных это к nosql

Очень жаль на самом деле, тк если бы ch так же генерировал столбцы но забивал данные нулами - это было бы идеально, тк сейчас я себе это вижу как портянку из 200 case :(

а ктото пробовал заливать данные через внешние словари, или это извращение?

а ктото пробовал заливать данные через внешние словари, или это извращение?

А зачем если можно подключить таблицу по MYSQL/odbc?

Очень жаль на самом деле, тк если бы ch так же генерировал столбцы но забивал данные нулами - это было бы идеально, тк сейчас я себе это вижу как портянку из 200 case :(

Ничего страшного :) у нас запросы портянками больше, чем по спецификации http дозволено )

Ничего страшного :) у нас запросы портянками больше, чем по спецификации http дозволено )

По моим прекидкам унифицированный запрос у меня будет в 10к строк и я не знаю норма ли это

Поправил сообщение выше :) не проснулся еще )

У нас и такие пролезают