а вот я смотрю в https://github.com/yandex/ClickHouse/blob/master/libs/libmysqlxx/include/mysqlxx/PoolWithFailover.h и вижу там * <mysql_metrica> * <host>mtstat01c*</host> * <port>3306</port> * <user>metrica</user> * <password></password> * <db>Metrica</db> * </mysql_metrica> а как сослаться на этот mysql_metrica в xml-е словаря?

<mysql_metrica> - это устаревший пример из Метрики. Вот у вас есть xml со словарём, и там параметры находятся внутри <source> <mysql>

т.е. если у меня 5000 словарей, то я напишу 5000 раз хост, порт и т.д. в 5000 xml файлов?

Можно все словари объявить в одном xml файле.

не догоняю, можно ли пароль и пользовтель один раз описать, что за подстановки? https://clickhouse.yandex/docs/ru/dicts/external_dicts/ <!--Необязательный элемент, имя файла с подстановками--> <include_from>/etc/metrika.xml</include_from>

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

Уже есть DateTime(TZ)

где? Не вижу на их сайте в доках (

Улучшена поддержка часовых поясов. В типе DateTime может быть указана таймзона, которая используется для парсинга и отображения данных в текстовом виде. Пример: DateTime('Europe/Moscow'). При указании таймзоны в функциях работы с DateTime, тип возвращаемого значения будет запоминать таймзону, для того, чтобы значение отображалось ожидаемым образом.

а где это найти в документации?

Наверное отсутствует.

есть ли более актуальная, чем на https://clickhouse.yandex/docs/ ?

Нет.

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

Workaround — писать (u)int (32|64) вместо timestamp. Хотя, прошу прощения, ClickHouse-graphite я пока не ковырял

Вчитался в документацию. Правильно ли я понимаю, что отсутствие буферизации при штучном инсерте решается через https://clickhouse.yandex/docs/ru/table_engines/buffer/ и проблемы вообще никакой нет?

Вчитался в документацию. Правильно ли я понимаю, что отсутствие буферизации при штучном инсерте решается через https://clickhouse.yandex/docs/ru/table_engines/buffer/ и проблемы вообще никакой нет?

выше обсуждали, что и в Buffer лучше пачками вставлять

точнее, буфер решает, если инсертов максимум несколько сотен в секунду.

/stat@combot

combot.org/chat/-1001080295593

Мы немного допилили драйвер для себя. Проблема ошибок в табло в большинстве случаев из-за ODBC-запросов, которые содержат нереализованные пока функции. Смысл в том, чтобы научить парсер ODBC-драйвера понимать новые функции и отдавать их соотвествующим функциям кликхауса (если они есть, что не всегда) вместе с параметрами.

Мы немного допилили драйвер для себя. Проблема ошибок в табло в большинстве случаев из-за ODBC-запросов, которые содержат нереализованные пока функции. Смысл в том, чтобы научить парсер ODBC-драйвера понимать новые функции и отдавать их соотвествующим функциям кликхауса (если они есть, что не всегда) вместе с параметрами.

а есть где то ваш форк в github?

не делали коммитов, но сейчас сделаем

почему бы и нет

combot.org/chat/-1001080295593

а где это найти в документации?

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md

/stat@combot

combot.org/chat/-1001080295593

а есть где то ваш форк в github?

fork - vstep0 (сделали в феврале) Допилили для себя только то, что нужно было для нашех текущих репортов. Встречали проблему - фиксили, системного подхода не было. Поэтому например LTRIM реализован, а RTRIM нет. Немного пересеклись с основной веткой (EXTRACT и CURRENT_TIMESTAMP), пока что не мержили, потому что нам функциональности нашей версии хватает. Также тупо(try-catch) заставили ODBC не приводить к крешу, когда Poco не мог сконвертить NaN в числа. Еще один важный момент: при использовании в Tableau кострукции CASE-WHEN-THEN нельзя использовать неконстантные выражения после THEN. Лучше заменить на IF-ELSEIF-THEN (это из-за деталей реализации в самом кликхаусе, мы туда не залазили и решили просто обойти пока что).

https://github.com/vstep0/clickhouse-odbc

Мы у себя используем: props.values[indexOf(props.name, 'country_code')] прям сосвсем человечно :)

Подскажите пожалуйста какое железо подойдет под следуюший проект: одна таблица, данных 5 млн строк в день (пик иногда до 10), одна строка занимает 24 байта, используются datetime, int64, float32. Основная нагрузка формирования онлайн-отчетов для пользователей с агрегацией (ожидаемая нагрузука 300 запросов в минуту). Спасибо!

Подскажите пожалуйста какое железо подойдет под следуюший проект: одна таблица, данных 5 млн строк в день (пик иногда до 10), одна строка занимает 24 байта, используются datetime, int64, float32. Основная нагрузка формирования онлайн-отчетов для пользователей с агрегацией (ожидаемая нагрузука 300 запросов в минуту). Спасибо!

Вам подойдет PostgreSQL/MySQL в вашем случае брать ClickHouse - это перебор и лишние проблемы

зато модно :)

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

Вам подойдет PostgreSQL/MySQL в вашем случае брать ClickHouse - это перебор и лишние проблемы

Postgres тестировали - чтобы построить необходимый отчет из сырых данных приходится как на картинке уходить чайку попить, КН менее чем за минуту справляется. Да можно извернуться, а смысл?

Подскажите пожалуйста какое железо подойдет под следуюший проект: одна таблица, данных 5 млн строк в день (пик иногда до 10), одна строка занимает 24 байта, используются datetime, int64, float32. Основная нагрузка формирования онлайн-отчетов для пользователей с агрегацией (ожидаемая нагрузука 300 запросов в минуту). Спасибо!

насколько большая выборка будет попадать в аналитику (150М записей в месяц получается?), насколько быстро должен выполняться 1 запрос?

Postgres тестировали - чтобы построить необходимый отчет из сырых данных приходится как на картинке уходить чайку попить, КН менее чем за минуту справляется. Да можно извернуться, а смысл?

Что за запрос такой, при ваших 5 млн строк в день, что на ClickHouse у вас в пределах минуты считается?

насколько большая выборка будет попадать в аналитику (150М записей в месяц получается?), насколько быстро должен выполняться 1 запрос?

запрос с самыми большими выборками - это по популярному event_id за годовой период, данных там примерно окло 1300 Мб получается - хотелось бы в 10 сек уложиться

запрос с самыми большими выборками - это по популярному event_id за годовой период, данных там примерно окло 1300 Мб получается - хотелось бы в 10 сек уложиться

А записей за год по этому event_id сколько?

и count() означает что, количество раз которое была такая комбинация url,name,value?

да, именно так. но считать хочется не отдельные кортежи, а массивы кортежей например есть такие исходные данные: date1,url1,Nested([[name1,name2,badName1],[value1,value2,value3]]) date2,url1,Nested([[name1,name2,badName1],[value1,value2]]) date1,url1,Nested([[name3,name4],[value1,value2]]) date1,url1,Nested([[name3,name4],[value1,value2]]) date1,url2,Nested([[name1,name2,name4],[value5,value6,value1]]) date1,url2,Nested([[name1,name2,name4,badName2],[value5,value6,value1,value4]]) результат хочется такой url p my_count url1 [(name1=value1),(name2=value2)] 2 url1 [(name3=value1),(name4=value1)] 2 url2 [(name1=value5),(name2=value6),(name3=value1)] 2 я придумал только в лоб собирать кортежи arrayMap select url, count() my_count arrayFilter(x -> tupleElement(x,1) not in ['badName1,badName2'], arrayMap(x,y -> tuple(x,y),params.Name,params.Value)) p group by url, p

Что за запрос такой, при ваших 5 млн строк в день, что на ClickHouse у вас в пределах минуты считается?

Это из-за тестового vds с 1 проц и памятью 500 мегов.

запрос с самыми большими выборками - это по популярному event_id за годовой период, данных там примерно окло 1300 Мб получается - хотелось бы в 10 сек уложиться

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

А записей за год по этому event_id сколько?

Около 100 млн получается.

Вам подойдет PostgreSQL/MySQL в вашем случае брать ClickHouse - это перебор и лишние проблемы

а какие проблемы от кх?)

а какие проблемы от кх?)

Его, как минимум, надо админить и если что-то пошло не так то уметь решить. В этом плане с PostgreSQL/MySQL проще, пока что. Поэтому если данных не много и можно обойтись без КХ какими-либо привычными инструментами то так и стоит делать

Около 100 млн получается.

Это не сильно много для PostgreSQL

а тоесть PostgreSQL/MySQL не надо админить?

а тоесть PostgreSQL/MySQL не надо админить?

Обычно они уже есть и понятно как с ними жить

а если вот новый проект

нет ничего)

понятно что какойнить документоборот

не получится на кх сделать

нет ничего)

Т.е. в новый проект вы входите как в "Час расплаты" стирая себе память? Так или иначе выбирают, обычно, инструмент/технологию исходя из опыта и применимости данной технологии под задачу, не всегда нужно забивать микроскопом гвозди.

а потом когда надо будет в огромном проекте вставить кликхаус срочно, сидеть и бится головой об стену?)

когда данных резко миллиарды станет

когда данных резко миллиарды станет

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

но прогнозы не всегда сбываются :)

бывает

5 лет никто не следит за сервисом

и все)

5 лет никто не следит за сервисом

Это решается удалением никому ненужных данных за эти 5 лет

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

наномолоток?

я вот не вижу никаких сложностей с кх

мы его поставили и практически забыли

в постгресе намного чаще ковырятся надо

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

в инете видел цитату от разработчиков Eliptics

"если у вас нет трех стоек в двух дата центрах, то отойдите и не мешайте работать"

вот тут наверно все на такомже принципе идет

ну если так посмотреть, то у нас на проекте есть postgres mssql clickhouse и cassandra

но при этом у нас нет 3х стоек)

Eliptics - это немного про другое. И, для Eliptics - это справедливо.

Это не сильно много для PostgreSQL

Может быть - но нас это не устраивает. Поэтому интересуют советы в плане железа под CH

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

Может быть - но нас это не устраивает. Поэтому интересуют советы в плане железа под CH

не рассматриваете агрегацию данных в отдельную таблицу по используемому измерению на том же КХ? За счет места решаем проблему со скоростью.

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

не рассматриваете агрегацию данных в отдельную таблицу по используемому измерению на том же КХ? За счет места решаем проблему со скоростью.

а если измерений станет штук 100?)

а если измерений станет штук 100?)

вы постановку задачи читали?

Может быть - но нас это не устраивает. Поэтому интересуют советы в плане железа под CH

Вы под ваши данные хотите именно железо брать ? Если да, то оно при ваших данных будет очень комфортно себя чувствовать при ~8 Гб памяти и 4-х ядрах, но такой сервер еще поискать надо, проще в контейнере/виртуалке запустить

а ну да

тут можно заранее все общитать

и положить

не рассматриваете агрегацию данных в отдельную таблицу по используемому измерению на том же КХ? За счет места решаем проблему со скоростью.

К сожалению предаггрегация по ряду причин не возможно, поэтому запросы к сырым данным.

Вы под ваши данные хотите именно железо брать ? Если да, то оно при ваших данных будет очень комфортно себя чувствовать при ~8 Гб памяти и 4-х ядрах, но такой сервер еще поискать надо, проще в контейнере/виртуалке запустить

Спасибо. Вопрос - а через 3 года, когда данных будет под 10 млрд и эти все эти данные будут нужны для отчета?

Коллеги, а подскажите способы ускорения INSERT SELECT, выполняемого с целью очистки от "мусора". Изначально таблица реплицированная, после очистки ожидается что такой и останется. Пробовали INSERT в несколько MergeTree, и конвертацию в Replicated потом, но наткнулись на коллизию имён партов. Пробовали параллельный INSERT разных диапазонов данных на разных репликах шарда - стали натыкаться на too many parts. Настройку "не ругаться" подняли, но есть всё равно свободный CPU, а тот что занят - занимается мёржами. В диск/RAM также не упирались. Из того, что сам надумал: 1.) Может есть способ "отключить" мёржи для таблицы, чтобы они не стопорили процесс заливки, а стартовали в конце? 2.) Может мы недоглядели какие-то настройки, которые позволят в одном INSERT SELECT генерить парты крупнее/эффективнее?

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

Спасибо. Вопрос - а через 3 года, когда данных будет под 10 млрд и эти все эти данные будут нужны для отчета?

Либо железяку проапгрейдить, либо поставить 2-ю рядом.

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

CockroachDB - отличный пример того как надо делать тулинг, чем то подобным я понемногу занимаюсь для КХ )

Добрый день. Подскажите, пожалуйста, правильно ли я делаю выборку товара по последней дате изменения (таблица ReplacingMergeTree) SELECT unitHashId, lastTime, price /* параметры */ FROM products WHERE (unitHashId, lastTime) IN (SELECT unitHashId, MAX(lastTime) FROM products WHERE lastTime > '2018-04-17 12:56:35' GROUP BY unitHashId) ORDER BY price ASC LIMIT 0,20 кстати как вы в Яндекс.Маркете работаете с товарами, которые обновляют цены

Добрый день. Подскажите, пожалуйста, правильно ли я делаю выборку товара по последней дате изменения (таблица ReplacingMergeTree) SELECT unitHashId, lastTime, price /* параметры */ FROM products WHERE (unitHashId, lastTime) IN (SELECT unitHashId, MAX(lastTime) FROM products WHERE lastTime > '2018-04-17 12:56:35' GROUP BY unitHashId) ORDER BY price ASC LIMIT 0,20 кстати как вы в Яндекс.Маркете работаете с товарами, которые обновляют цены

Из вопроса делаю вывод что у вас товары это не внешнаяя таблица и не справкочник . Хранить OLTP таблицу в КХ неправильно.

Но сам запрос вроде верный

Из вопроса делаю вывод что у вас товары это не внешнаяя таблица и не справкочник . Хранить OLTP таблицу в КХ неправильно.

Может быть таблица с движком mysql

я пока эксперементирую, база в mysql 1.18 billion rows

Может быть таблица с движком mysql

я под внешней таблицей это и подразумевал

нет mysql я в CH использую только как справочник, данные о товарных изменениях в CH кидаю пачками в реальном времени и пытаюсь их как-то получать, на холодном кэше разогнать CH быстрее 1.5 сек. не получается ?

Добрый день. Подскажите, пожалуйста, правильно ли я делаю выборку товара по последней дате изменения (таблица ReplacingMergeTree) SELECT unitHashId, lastTime, price /* параметры */ FROM products WHERE (unitHashId, lastTime) IN (SELECT unitHashId, MAX(lastTime) FROM products WHERE lastTime > '2018-04-17 12:56:35' GROUP BY unitHashId) ORDER BY price ASC LIMIT 0,20 кстати как вы в Яндекс.Маркете работаете с товарами, которые обновляют цены

Сделайте ORDER BY lastTime DESC LIMIT 1 BY unitHashId и получите последние unitHashId