Поставьте в users.xml в profiles/default <background_pool_size>2</background_pool_size> Может быть в будущем сделаем, чтобы сервер сам подстраивался под инсталляции с очень маленьким объёмом оперативки.

помогло СПАСИБО

ORDER BY сейчас не использует индекс

Пичалька. Как жить?

Если уже данные уже отсортированы в нужно порядке, вставка будет быстрее. Но специально сортировать мало смысла - вряд ли это получится эффективнее, чем в ClickHouse

но наверное имеет смысл, если ты можешь, готовить данные сразу в правильном порядке )

именно так :)

Пичалька. Как жить?

Поддерживаю вопрос. Очень туго живется без ORDER BY.

Подождите, вроде order by тут ни при чем

ORDER BY сейчас не использует индекс

Там в запросе where по индексу

Как я понимаю, он не работает

А order by по индексу в большинстве случаев не будет давать ожидаемого профита, как я понимаю. Следствие организации хранения данных в merge tree.

Подумал ещё немного. Будет, но зависит от данных и запроса. Не так как в классических базах с каким-нибудь btree.

Ребята, вы можете обновить benchmark? Например, там сравнение с очень старой версией MemSQL. Сейчас 5.8, а начиная с 4.0 columnstore существенно переработан и ускорен

Ребята, вы можете обновить benchmark? Например, там сравнение с очень старой версией MemSQL. Сейчас 5.8, а начиная с 4.0 columnstore существенно переработан и ускорен

А какое отношение MemSql имеет к КХ?

Там же написано - benchmark

https://clickhouse.yandex/benchmark.html

Надо обновить. Для MemSQL даже не так сложно, потому что сохранилась пошаговая инструкция. Сделаем, если найдём время.

Я все вертику жду обновления, уже версия 8.1 в проде бегает ?

С Вертикой не будет принципиальной разницы в зависимости от версий

Всем, привет, подскажите, пожалуйста, куда копать: При добавлении записи с таблицу с движком ReplicatedMergeTree ZooKeeper выкидывает ошибку NoNode for ...

Добрый день! Как-то проблема решилась? Тоже самое наблюдаю, все норм работает. INFO. Но все же. Сыпятся постоянно такие сообщения..

Добрый день! Как-то проблема решилась? Тоже самое наблюдаю, все норм работает. INFO. Но все же. Сыпятся постоянно такие сообщения..

Это вообще не ошибка. Это говорит о том, что мы спросили у ZK данные о каком-то узле, но узла нет. С точки зрения приложения, и с точки зрения самого ZK, это нормальная ситуация. Можете понизить уровень логгирования в ZK.

ок, спс

Надо обновить. Для MemSQL даже не так сложно, потому что сохранилась пошаговая инструкция. Сделаем, если найдём время.

есть такой человек Andy Pavlo, он хорошо знает ребят из MemSQL, может они сами захотят прогнать?

Смысл в том, что все системы проходят тесты на одинаковых серверах. А вообще было бы хорошо. Сейчас для этого не хватает генератора тестовых данных.

Всем привет. Кто-нибудь пробовал использовать odbc драйвер на windows? У вас он хоть с какой-нибудь программой начал отрабатывать?

Мы пробовали spss моделлер, excel 2013, tableau 10.3 - где-то видит только таблицы, где-то еще видны поля. но селект нигде не получилось сделать. эксель просто не подлкючился

Всем привет. Кто-нибудь пробовал использовать odbc драйвер на windows? У вас он хоть с какой-нибудь программой начал отрабатывать?

пока не получается настроить табло чтобы подцепить кх https://community.tableau.com/message/629589#629589

Здравствуйте! Система генерирует поток событий. У события есть время появления, уникальный идентификатор и текстовое представление события. Структура таблицы для хранения событий: CREATE TABLE IF NOT EXISTS test_data (CounterID UInt32, EventDate Date, Payload String) ENGINE = MergeTree(EventDate, (CounterID, EventDate), 8192) Я хочу использовать кликхаус в качестве хранилища событий с возможностью запуска аналитики и с возможностью последующей выгрузки в другие системы. Записал в таблицу примерно 0.5*10^9 таких событий и пытаюсь перегружать их по мере пеступления во внешнего клиента таким запросом: SELECT CounterID,EventDate,Payload FROM test_data WHERE CounterID > 5 ORDER BY CounterID LIMIT 5 FORMAT JSON Запрос выполняется 50 минут. Всего строк COUNT()=623171850 "statistics": { "elapsed": 3094.789434725, "rows_read": 623171850, "bytes_read": 430075954723 } Аналогично для запроса SELECT CounterID,EventDate,Payload FROM test_data WHERE CounterID > 623171000 ORDER BY CounterID LIMIT 5 По какой причине в этом запросе происходит чтение всех строк и не используется индекс? Есть ли правильный способ перегружать данные из таблицы во внешнюю систему по мере поступления событий или clickhouse в принципе не предназначен для таких задач? версия clickhouse 1.1.54236

Судя по вчерашнему общению на тему order by, то он вроде как не использует индекс

И возможно так долго данные читаются как раз таки из-за order by, но я могу ошибаться ) Лучше дождаться ответа от разработчиков

Хотя...скорее всего у вас слишком большая гранулированность CounterID

И получается так, что особого профита от индекса по этой колонке нет

Получается аналогично фулскану

Можно добавить еще колонку какую то типа eventBatch и класть туда например пометку о каждых 10 миллионах записей

И вместо CounterID включить ее в индекс

Например на батчи в диапозоне 623 170 000 - 623 171 000 значение eventBatch будет 623 170 000

Тогда можно будет делать запрос типа prewhere eventBatch > 623 170 000 where CounterID > 623 171 000

Вот тут есть очень развернутый ответ Алексея на тему того как работает первичный ключ: https://groups.google.com/forum/#!topic/clickhouse/eUrsP30VtSU

А нет ли желания рассказать про ClickHouse на https://smartdataconf.ru/ ?

Вот тут есть очень развернутый ответ Алексея на тему того как работает первичный ключ: https://groups.google.com/forum/#!topic/clickhouse/eUrsP30VtSU

Спасибо, интересно

Про Excel.

В 2016 запрос через odbc - работает. 2013 ещё надо найти.

А нет ли желания рассказать про ClickHouse на https://smartdataconf.ru/ ?

Можем. Организаторы заинтересованы в нашем докладе?

Здравствуйте! Система генерирует поток событий. У события есть время появления, уникальный идентификатор и текстовое представление события. Структура таблицы для хранения событий: CREATE TABLE IF NOT EXISTS test_data (CounterID UInt32, EventDate Date, Payload String) ENGINE = MergeTree(EventDate, (CounterID, EventDate), 8192) Я хочу использовать кликхаус в качестве хранилища событий с возможностью запуска аналитики и с возможностью последующей выгрузки в другие системы. Записал в таблицу примерно 0.5*10^9 таких событий и пытаюсь перегружать их по мере пеступления во внешнего клиента таким запросом: SELECT CounterID,EventDate,Payload FROM test_data WHERE CounterID > 5 ORDER BY CounterID LIMIT 5 FORMAT JSON Запрос выполняется 50 минут. Всего строк COUNT()=623171850 "statistics": { "elapsed": 3094.789434725, "rows_read": 623171850, "bytes_read": 430075954723 } Аналогично для запроса SELECT CounterID,EventDate,Payload FROM test_data WHERE CounterID > 623171000 ORDER BY CounterID LIMIT 5 По какой причине в этом запросе происходит чтение всех строк и не используется индекс? Есть ли правильный способ перегружать данные из таблицы во внешнюю систему по мере поступления событий или clickhouse в принципе не предназначен для таких задач? версия clickhouse 1.1.54236

Если читается много строк - значит получается, что много строк подходят под условие CounterID > 5 или CounterID > 623171000. При этом ORDER BY CounterID LIMIT 5 уже не помогает, так как ORDER BY не использует индекс. Чтобы было эффективнее, можно поставить условие на CounterID сверху, как-то наугад: CounterID > 5 AND CounterID < 500. Понятное дело, что так не всегда возможно. ORDER BY не использует индекс. Но это было бы хорошо реализовать. Ещё не реализовано, потому что требуется несколько другой способ распараллеливания запроса (разделения задач по потокам) - более "последовательный", чем когда известно, что мы будем читать весь диапазон. И такая логика просто ещё не разработана.

Можем. Организаторы заинтересованы в нашем докладе?

Затрудняюсь ответить. Я пока только посетитель конференций, проводимых JUG.ru.

ну хоть кто-то здесь не ненавидит яву=)

Вспомнил, что у нас уже есть предварительная договорённость о конференции от Jug.ru как раз в это время. Думаю, это она и есть. Значит будем.

про использование order by понял, спасибо

Существует ли возможность смерджить одноуровневые массивы? Например, для структуры: Key UInt32 | Value Array(UInt32) поулчить все уникальные значения элементов массива Value для определенного ключа?

Существует ли возможность смерджить одноуровневые массивы? Например, для структуры: Key UInt32 | Value Array(UInt32) поулчить все уникальные значения элементов массива Value для определенного ключа?

Где то видел модификаторы агрегатных функций ForEach

Которые по массиву топают

Существует ли возможность смерджить одноуровневые массивы? Например, для структуры: Key UInt32 | Value Array(UInt32) поулчить все уникальные значения элементов массива Value для определенного ключа?

Можно воспользоваться агрегатной функцией groupUniqArrayArray. На вход принимает массивы. На выходе будет массив со всеми уникальными значениями. Название необычное, потому что это - агрегатная функция groupUniqArray, к которой ещё приписали комбинатор -Array.

Можно воспользоваться агрегатной функцией groupUniqArrayArray. На вход принимает массивы. На выходе будет массив со всеми уникальными значениями. Название необычное, потому что это - агрегатная функция groupUniqArray, к которой ещё приписали комбинатор -Array.

спасибо!

Расскажите, пожалуйста, по-подробнее, что такое seek-и. Откуда возникают и что влияет на их количество. Что с их помощью оценить​ - есть в документации, но не понимаю откуда они.

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

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

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

нет :)

это относительно постоянная величина в районе 4-9 мс

она зависит сугубо от расстояния между дорожками (чем дальше - от центра - данные на диск легли - тем дольше)

ну и как следствие, чем больше обращений с паттерном "рандом read / write", когда чтение запись идет не последовательно, а в разные файлы (как следствие размещенные в физически разных местах жесктого диска) идет этот самый seek

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

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

Ясно, спасибо! Смутил тот факт, что при выполнении select event, value from system.events where event == 'Seek' возвращает 1621052. Бывает увеличивается скачками немного, не уменьшается и не понятно в каких попугаях измеряется.

я почти уверен, что - в штуках :)

Ясно, спасибо! Смутил тот факт, что при выполнении select event, value from system.events where event == 'Seek' возвращает 1621052. Бывает увеличивается скачками немного, не уменьшается и не понятно в каких попугаях измеряется.

В штуках с момента запуска сервера. Это количество системных вызовов для seek.

т.е. это не seek шпинделя?

И смысл такого счётчика тоже, пожалуйста)

С реальным перемещением головок связано косвенно. Смысл счётчика - количество мест, с которых мы читали файлы. Например, если после обработки запроса, счётчик увеличился на 10 - значит было 10 разных мест, начиная с которых мы делали чтения файлов.

удобная штука для отладки

Ребят, а есть какие нибудь костыли против broken pipe до релиза новой версии?

Ребят, а есть какие нибудь костыли против broken pipe до релиза новой версии?

Вот такое только что придумал.

Можно в каждом шарде задублировать реплику

и не забыть выставить везде internal_replication = true

то есть было так: <remote_servers> <test_cluster> <shard> <replica> <host>remote</host> <port>9000</port> </replica> </shard> </test_cluster> </remote_servers>

стало так: <remote_servers> <test_cluster> <shard> <internal_replication>true</internal_replication> <replica> <host>remote</host> <port>9000</port> </replica> <replica> <host>remote</host> <port>9000</port> </replica> </shard> </test_cluster> </remote_servers>

И так для каждого шарда

А если у меня виртуалки? Я могу просто склонировать три шарда и сделать их репликами? Данные будут переналиваться или лучше чистый инстанс кх поднимать?

Должно помочь :)

Должно помочь :)

Чет не совсем понимаю, а как оно поможет?

А если у меня виртуалки? Я могу просто склонировать три шарда и сделать их репликами? Данные будут переналиваться или лучше чистый инстанс кх поднимать?

Плохо объяснил наверно. Реплики существуют только в конфиге

По факту сервера остаются теми же, просто их надо внести в конфиг два раза

Чет не совсем понимаю, а как оно поможет?

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

Посколько при internal_replication=true вставка будет производиться только на одну из "реплик", дублирования данных не будет.

При запросе в distributed таблицу запрос тоже направляется только на одну из "реплик" шарда.

То есть всё будет работать как надо

очень интересное решение