Да, мы так и делаем

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

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

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

спасибо ?

А вы это кто? Если не секрет :) Мы это Контур)

https://www.percona.com/blog/2017/03/17/column-store-database-benchmarks-mariadb-columnstore-vs-clickhouse-vs-apache-spark/ очередное сравнение разных column store DB, в том числе Clickhouse

TL;DR: кликхаус порвал MariaDB ColumnStore и Apache Spark в щепки, зато у них оконные функции есть

А вы это кто? Если не секрет :) Мы это Контур)

Яндекс.Маркет

Если вдруг интересно, то вот https://events.yandex.ru/lib/talks/3715/

ага, спасибо ещё раз за ответ.

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

Если мне не изменяет память, то в такую таблицу вставлять нельзя

Но distributed таблицу легко пересоздать

Да, логично. Рандомное распределение при записи в distributed таблицу было бы сделать удобно на мой взгляд. Когда нет явного ключа шардированая но при этом кластер используется.

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

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

Т.к. вставка в распределенную таблицу порождает вставки на все шарды кластера, а вставка в конечную таблицу только одну

Для упрощения в такой конфигурации можно поднять над кластером балансер и работать только через него

Для упрощения в такой конфигурации можно поднять над кластером балансер и работать только через него

а есть что-то готовое? Что можно использовать для разрешения такой конфигурации записи?

Любой http балансер. Nginx, haproxy

Ребят, возможно тупой вопрос который не раз задавали, но ответа нарисерчить не можем. При вставке в дистрибьютед табличку кидает в лог эксепшн, ругаясь на материализованное поле date. стектрейс http://pastebin.com/dtC2im5T

Ребят, возможно тупой вопрос который не раз задавали, но ответа нарисерчить не можем. При вставке в дистрибьютед табличку кидает в лог эксепшн, ругаясь на материализованное поле date. стектрейс http://pastebin.com/dtC2im5T

https://groups.google.com/forum/m/#!topic/clickhouse/XEYRRwZrsSc

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

combot.org/chat/-1001080295593

День добрый, пытаюсь разобраться с индексами. Есть таблица

CREATE TABLE default.bounce ( date Date, reportDate DateTime, processedDate DateTime, userId Int64, type Int8, bounceEmail String, bounceDomain String, fromEmail String, fromDomain String, messageId String, subject String, code String, customField String) ENGINE = MergeTree(date, (userId, type, processedDate), 8192) и запрос вида: select bounceDomain, count() as total from bounce where type = 1 group by bounceDomain order by total desc limit 10 Нужно ли добавлять bounceDomain в индекс? При тестировании не заметил в разности в скорости.

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

С каким заработало, интересно

Бесплатный это какой?

CREATE TABLE default.bounce ( date Date, reportDate DateTime, processedDate DateTime, userId Int64, type Int8, bounceEmail String, bounceDomain String, fromEmail String, fromDomain String, messageId String, subject String, code String, customField String) ENGINE = MergeTree(date, (userId, type, processedDate), 8192) и запрос вида: select bounceDomain, count() as total from bounce where type = 1 group by bounceDomain order by total desc limit 10 Нужно ли добавлять bounceDomain в индекс? При тестировании не заметил в разности в скорости.

Нет. Т.к. запросу не нужна фильтрация по этому полю

Нет. Т.к. запросу не нужна фильтрация по этому полю

Спасибо. А если понадобится запрос с LIKE, то лучше включать поле в фильтр?

Привет всем. Подскажите насколько может быть оправдано добавление timestamp в первичный ключ. Для себя делаю такой вывод что это ускорит наши запросы так как в каждом из них будет учитыватся именно timestamp А сами данные будут разложены более эффективнее

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

Спасибо. А если понадобится запрос с LIKE, то лучше включать поле в фильтр?

Нет. В кх нету полнотекстовых индексов. Все равно будет фулскан

Бесплатный это какой?

Их много: Talend, Pentaho, Jaspersoft делают

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

CREATE TABLE default.bounce ( date Date, reportDate DateTime, processedDate DateTime, userId Int64, type Int8, bounceEmail String, bounceDomain String, fromEmail String, fromDomain String, messageId String, subject String, code String, customField String) ENGINE = MergeTree(date, (userId, type, processedDate), 8192) и запрос вида: select bounceDomain, count() as total from bounce where type = 1 group by bounceDomain order by total desc limit 10 Нужно ли добавлять bounceDomain в индекс? При тестировании не заметил в разности в скорости.

Тут есть вопрос к Яндексу. Если бы эта колонка стояла где-то в начале первичного ключа, то можно было бы существенно ускорить group by, так как данные уже частично отсортированы. Это называется pipelined group by. Насколько я понимаю, ClickHouse так не делает, хотя мог бы.

Тут есть вопрос к Яндексу. Если бы эта колонка стояла где-то в начале первичного ключа, то можно было бы существенно ускорить group by, так как данные уже частично отсортированы. Это называется pipelined group by. Насколько я понимаю, ClickHouse так не делает, хотя мог бы.

Да, хорошая идея. Из аналогичного еще обсуждался кейс ORDER BY по подмножеству первичного ключа.

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

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

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

Мы Airflow используем, пока используем связку BashOperator и clickhouse-client.

Интересное решение!

Добрый день! Кто нибудь юзает докер под мак? Поставил latest с хаба и не могу соединиться к порту 8123. Раньше все ок было. Если зайти в контейнер, то все ок с соединением

https://github.com/yandex/ClickHouse/pull/613/files

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

<listen_host>::</listen_host> в конфиг добавить или заменить

да, теперь по умолчанию он локальный

сделал пару экспериментов с первичным ключем 725млн данных, таблица 64 поля место первичный ключ время выполнения первого запроса 65G ./events_temp_tv11 timestamp, traffic_source_id, ch_date 9 сек 78G ./events_temp_1_tv11 traffic_source_id, ch_date 36 сек 95G ./events_temp_2_tv11 traffic_source_id, timestamp 12 запрос имеет условие WHERE (timestamp>=1483228800 AND timestamp<=1485907199) - полный январь месяц

А сколько ждали после заливки?

там со временем данные ужимаются

после последней заливки минут 5 это temp_2 первых две уже прошло два часа

да изменились показатели. 65G ./events_temp_tv11 65G ./events_temp_2_tv11 78G ./events_temp_1_tv11

Ребят, возможно тупой вопрос который не раз задавали, но ответа нарисерчить не можем. При вставке в дистрибьютед табличку кидает в лог эксепшн, ругаясь на материализованное поле date. стектрейс http://pastebin.com/dtC2im5T

Да, MATERIALIZED для Distributed таблиц плохо работает.

Добрый вечер! Как можно сделать выборку по периоду? В частности события до 9:30 утра, после 21:00.

Использовать toHour, toMinute?

Есть способы проще ?

Можно просто datetime <= '2017-03-20 09:30' Также можно использовать функцию toTime, чтобы оставить только время (дата приравнивается к фиксированной).

Если нужно выбрать события с 9:30 до 21:00 без учета дня, то лучше использовать toTime?

Если правильно понял

да, там всегда 1970-01-02 будет

кстати, почему не 1970-01-01? иначе это, типа, дата будет? (ну, по той же причине, по которой toDateTime(100) - это кол-во дней от unixtimestamp, а toDateTime(100000) - это уже кол-во секунд)

кстати, почему не 1970-01-01? иначе это, типа, дата будет? (ну, по той же причине, по которой toDateTime(100) - это кол-во дней от unixtimestamp, а toDateTime(100000) - это уже кол-во секунд)

у 01-01 бывают спецэффекты с временем до 03:00, с toMonday()

Да, MATERIALIZED для Distributed таблиц плохо работает.

Спасибо

Добрый день! Появился такой странноватый вопрос. Скажите, пожалуйста, если требуется хранить массивы заранее известного небольшого размера (например, 10 элементов), и за каждый запрос необходим только фиксированный N-ый элемент, то эффективнее хранить и запрашивать его, если он arr Array(String), или, если он, как китайский лапшекод: arr_0 String, arr_1 String ... arr_10 String?

И сразу вдогонку ещё вопрос. А какие есть варианты хранить вложенные массивы строк? как бы Array(Array(String)). Можно хранить в виде Array(String), где каждая String — строка с разделителем, но тогда почему-то запрос из ARRAY JOIN, GROUP BY и splitByString падает по памяти, причём запрос может быть самым простым и в итоге не требует хранить все строки

Очень мнго памяти ест, например даже такой запрос ест многие гигабайты памяти, хотя на выходе должен выдать всего несколько строк в ответе: matrix Nested( paths String -- каждая строка вида: 'A//B//C', 'A//B//D', 'D//E//F' ) SELECT length(splitByString('//', path)) AS path_len, count() FROM ch_table ARRAY JOIN matrix.paths AS path GROUP BY path_len ORDER BY path_len DESC LIMIT 100;

1. Много столбцов эффективнее (за исключением случая, когда их слишком много).

2. Уменьшите max_block_size, например, так: SET max_block_size = 8192 или постоянно - в users.xml в profiles #faq

Минимальное значение max_block_size, который имеет смысл указывать - это index_granularity вашей таблицы. Если в вашей таблице все строки толстые, то можете пересоздать её с меньшим index_granularity (это последний параметр для MergeTree). #faq

Спасибо большое! max_block_size — прикольный параметр, не знал про него)

Минимальное значение max_block_size, который имеет смысл указывать - это index_granularity вашей таблицы. Если в вашей таблице все строки толстые, то можете пересоздать её с меньшим index_granularity (это последний параметр для MergeTree). #faq

Алексей, можете в конце таких общего плана ответах указывать какой-нибудь поисковый тег типа # faq manual или howto. Так можно будет ваши полезные ответы потом быстро находить :)

Алексей, можете в конце таких общего плана ответах указывать какой-нибудь поисковый тег типа # faq manual или howto. Так можно будет ваши полезные ответы потом быстро находить :)

Спасибо, постараюсь не забыть :)

Спасибо, постараюсь не забыть :)

Спасибо! Вот так шикарно просто!

1. Много столбцов эффективнее (за исключением случая, когда их слишком много).

А слишком много это сколько? Каков порядок 100, 1000 или 10000 ?

Добрый день

Может кто подскажет. Использую версию сервера 1.1.53981 (докер yandex/clickhouse-server). Пробую подлючится через jdbc драйвер собранный отсюда: https://github.com/yandex/clickhouse-jdbc. Подключаю драйвер в Talend, указываю сборку clickhouse-jdbc-0.1-SNAPSHOT-jar-with-dependencies и при подключении происходит ошибка: Ошибка соединения. Вы должны изменить настройки базы данных. java.lang.RuntimeException: java.lang.RuntimeException: ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 46, host: localhost, port: 8123; Code: 46, e.displayText() = DB::Exception: Unknown function timezone, e.what() = DB::Exception, Stack trace..... Такой функции действительно нет. Подключался через clickhouse-client. То есть при подключении сам драйвер выполняет такой запрос select timezone(). Вот строка кода с этим запросом на github: https://github.com/yandex/clickhouse-jdbc/blob/master/src/main/java/ru/yandex/clickhouse/ClickHouseConnectionImpl.java#L64

В документации тут https://clickhouse.yandex/reference_ru.htm, тоже не встретил такой функции

Как будто ее и не существует

обновите ваш кликхаус

да, последняя версия драйвера работает с более поздними версиями сервера.

в чейнджлоге jdbc драйвера написано

0.1.18 NOTE: starting from this release server timezone is used by default. This will work with server version >= 1.1.54159. Set use_server_time_zone = false and use_time_zone to desired timezone name for using with earlier server versions.

в changelog написано, да.

0.1.18 NOTE: starting from this release server timezone is used by default. This will work with server version >= 1.1.54159. Set use_server_time_zone = false and use_time_zone to desired timezone name for using with earlier server versions.

А в URL строке подключения ведь можно это указать?

Спасибо

Друзья! Открылась регистрация на ClickHouse митап в Новосибирске 3 апреля. Регистрируйтесь и делитесь новостью с коллегами в сибирском регионе. https://twitter.com/ya_events/status/843771103441010689 https://vk.com/yandex.events?w=wall-17796776_5203 https://www.facebook.com/Yandex.Events/photos/a.207908329229296.53451.122612334425563/1475215179165265/?type=3&theater