В общем верно я услышал что в таком подходе ничего криминального нет и кликхаус будет эффективно работать в таком случае. Т.е. в случае когда для кажлого заказа хранится вся история его версий (изменений). Но запросы в 99% будут к выборке по последней его версии? Получается эффективным индексом в таком случае будет offer_id, order_id, date, datetime?

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

Я бы date для ключа партиционирования брал из даты изменения, что бы можно было потом старые логи изменения заказов архивировать и выкидывать

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

Приведу может еще 1 пример чтобы стало понятнее. У нас в системе в месяц поступает порядка 1 000 000 заказов с большим количеством колонок. По ним нужно очень много всяких статистических выборок и с агрегацией и без. Соответсвтвенно предлагается в кликхаус хранить на каждый заказ еще всю историю его изменений, к примеру на каждый заказ в среднем по 10 записей, получается 10 000 000 записей в месяц. Но все выборки, 99% нужно будет выбирать из представления с ORDER by datetime LIMIT 1 BY order_id чтобы обращаться к последней версии заказа.

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

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

Скорее всего JOIN будет очень медлено работать

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

Он не всегда будет там "один"

Он не всегда будет там "один"

не всегда, но меньше чем в основной таблице

Скорее всего JOIN будет очень медлено работать

я имел в виду оставить таблицу log и завести такую же таблицу ReplacingMergeTree которая будет схлопываться со временем по orderid

и использовать ее для 99% запросов

я имел в виду оставить таблицу log и завести такую же таблицу ReplacingMergeTree которая будет схлопываться со временем по orderid

В таблице типа Log всегда читаются все данные, там нет такой оптимизации как в семействе движков *MergeTree

Зачем нужна такая таблица с Log?

Стоит ли Materialized View использовать для такого? Или лучше вставлять данные отдельно в 2 таблицы, т.к. не поддерживается Alter?

я имел в виду оставить таблицу log и завести такую же таблицу ReplacingMergeTree которая будет схлопываться со временем по orderid

В таблице типа Log всегда читаются все данные, там нет такой оптимизации как в семействе движков *MergeTree

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

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

Зачем нужна такая таблица с Log?

Стоит ли Materialized View использовать для такого? Или лучше вставлять данные отдельно в 2 таблицы, т.к. не поддерживается Alter?

я бы в 2 таблицы писал =)

я бы в 2 таблицы писал =)

+1. В Яндекс.Метрика так и сделано, одна из двух таблиц содержит часть данных другой

Спасибо. И еще такой кейс, что клик хаус предполагает что записи в таблицу происходят большими пачками 1000+ штук. А тут они могут происходить как пачками (выгрузки по Апи, Импорт Excel и т.п.) а также и менеджеры часто правят заказы штучно.. Это не страшно?

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

Спасибо. И еще такой кейс, что клик хаус предполагает что записи в таблицу происходят большими пачками 1000+ штук. А тут они могут происходить как пачками (выгрузки по Апи, Импорт Excel и т.п.) а также и менеджеры часто правят заказы штучно.. Это не страшно?

Смысл вставки пачками в том, что после вставки ClickHouse в фоне что-то ещё делает с этими данными. Если вставка "поштучно" идёт не часто, раз в несколько часов - проблем не будет

Но как только пойдет вставка по 1-10 запись каждую секунду - фоновые процессы слияний начнут "грузить" систему и скорость обработки запросов кратно упадёт

Смысл вставки пачками в том, что после вставки ClickHouse в фоне что-то ещё делает с этими данными. Если вставка "поштучно" идёт не часто, раз в несколько часов - проблем не будет

Ну как правило да - штучно не часто правка происходит, только когда "Что то несходится" при сверках. Спасибо.

Коллеги, добрый день, у меня начала вылезать ошибка DB::Exception: Checksum doesn't match: corrupted data

Это не очень просто сделать. Сначала нужно посмотрерть на имена кусков в data/database/table. Далее в запрос можно добавить поля _part и _part_index. _part - имя куска, из которого читается строка, _part_index - некий номер куска в запросе. В частности, если при добавлении в запрос условия where _part = '...' происходит падение, то нужный кусок найден. Угадывать номер куска можно путем добавления условий на дату и _part_index. Также, если имя куска написано в _part, то он успешно прочитался. Далее, сделать detouch куска и проверить, что запрос стал работать.

Это не очень просто сделать. Сначала нужно посмотрерть на имена кусков в data/database/table. Далее в запрос можно добавить поля _part и _part_index. _part - имя куска, из которого читается строка, _part_index - некий номер куска в запросе. В частности, если при добавлении в запрос условия where _part = '...' происходит падение, то нужный кусок найден. Угадывать номер куска можно путем добавления условий на дату и _part_index. Также, если имя куска написано в _part, то он успешно прочитался. Далее, сделать detouch куска и проверить, что запрос стал работать.

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

Так будет намного проще :)

под кристал есть норм драйвер?

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

Не могли бы Вы еще посмотреть в логе стектрейс ошибки?

Не могли бы Вы еще посмотреть в логе стектрейс ошибки?

Если объясните как это сделать по шагам - то смогу

Если объясните как это сделать по шагам - то смогу

если запрос падает, то в /var/log/clickhouse-server/clickhouse-server.err.log должно писаться список из чего-то вроде 0. clickhouse-server(StackTrace::StackTrace()+0x16) ... нужно запустить запрос а потом посмотреть, есть ли что-то похожее там. например: sudo tail -n 100 /var/log/clickhouse-server/clickhouse-server.err.log

если запрос падает, то в /var/log/clickhouse-server/clickhouse-server.err.log должно писаться список из чего-то вроде 0. clickhouse-server(StackTrace::StackTrace()+0x16) ... нужно запустить запрос а потом посмотреть, есть ли что-то похожее там. например: sudo tail -n 100 /var/log/clickhouse-server/clickhouse-server.err.log

0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x30d6226] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x137053f] 2. clickhouse-server(DB::CompressedReadBufferBase::readCompressedData(unsigned long&, unsigned long&)+0x3d2) [0x30f9012] 3. clickhouse-server(DB::CompressedReadBuffer::nextImpl()+0x33) [0x3100183] 4. clickhouse-server() [0x2a6a080] 5. clickhouse-server(DB::LogBlockInputStream::readData(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::IDataType const&, DB::IColumn&, unsigned long, unsigned long, bool)+0x416) [0x3220f56] 6. clickhouse-server(DB::LogBlockInputStream::readImpl()+0x575) [0x32224b5] 7. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 8. clickhouse-server(DB::FilterBlockInputStream::readImpl()+0x1f4) [0x33b4ad4] 9. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 10. clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x340f46d] 11. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 12. clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x340f46d] 13. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 14. clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::loop(unsigned long)+0x152) [0x3209972] 15. clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x77) [0x320a047] 16. clickhouse-server() [0x3eca42f] 17. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f445e4016ba] 18. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f445da223dd]

0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x30d6226] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x137053f] 2. clickhouse-server(DB::CompressedReadBufferBase::readCompressedData(unsigned long&, unsigned long&)+0x3d2) [0x30f9012] 3. clickhouse-server(DB::CompressedReadBuffer::nextImpl()+0x33) [0x3100183] 4. clickhouse-server() [0x2a6a080] 5. clickhouse-server(DB::LogBlockInputStream::readData(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::IDataType const&, DB::IColumn&, unsigned long, unsigned long, bool)+0x416) [0x3220f56] 6. clickhouse-server(DB::LogBlockInputStream::readImpl()+0x575) [0x32224b5] 7. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 8. clickhouse-server(DB::FilterBlockInputStream::readImpl()+0x1f4) [0x33b4ad4] 9. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 10. clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x340f46d] 11. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 12. clickhouse-server(DB::ExpressionBlockInputStream::readImpl()+0x2d) [0x340f46d] 13. clickhouse-server(DB::IProfilingBlockInputStream::read()+0x221) [0x2a46fc1] 14. clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::loop(unsigned long)+0x152) [0x3209972] 15. clickhouse-server(DB::ParallelInputsProcessor<DB::UnionBlockInputStream<(DB::StreamUnionMode)0>::Handler, (DB::StreamUnionMode)0>::thread(MemoryTracker*, unsigned long)+0x77) [0x320a047] 16. clickhouse-server() [0x3eca42f] 17. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f445e4016ba] 18. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f445da223dd]

Спасибо! У вас, оказывается, движок Log. То, что я писал, верно для *MergeTree. Moя ошибка.

Спасибо! У вас, оказывается, движок Log. То, что я писал, верно для *MergeTree. Moя ошибка.

Это я не уточнил сразу, да, Log - с него проще начинать знакомиться с системой, плнирую оперативно от него уходить

Это я не уточнил сразу, да, Log - с него проще начинать знакомиться с системой, плнирую оперативно от него уходить

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

Full day of ClickHouse talks. See you at Percona Live, 27 September, at Sky Suite 2 https://twitter.com/ClickHouseDB/status/912283066386780160

Ребятки, а есть где то реккомендации по железу, или по расчету железа для КХ?

Кое что тут есть https://clickhouse.yandex/docs/en/operations/tips.html

А подскажите такую штуку: если я делаю один большой запрос и постояно обращаюсь к одной и тойже таблице в нескольких подхапросах, используя одинаковые выражения первичного ключа для фильтрации, то прочитанные блоки передаются от подзапроса к подзапросу или каждый подзапрос все равно читает данные из таблицы?

А подскажите такую штуку: если я делаю один большой запрос и постояно обращаюсь к одной и тойже таблице в нескольких подхапросах, используя одинаковые выражения первичного ключа для фильтрации, то прочитанные блоки передаются от подзапроса к подзапросу или каждый подзапрос все равно читает данные из таблицы?

Каждый раз читает

Ок. Шустро работает в таком случае )

А нет планов добавить блок with для таких случаев?

https://clickhouse.yandex/docs/ru/introduction/performance.html?highlight=page#id2

А есть еще возможность как то сложить таблицу в память целиком? Т.е. есть у меня таблица, которая весит например 50 гигов, оперативы у меня 256 гигов. Можно как то затолкать ее в оперативу, что бы данные читать не с таблицы?

есть движок таблицы memory

Не, нужен MergeTree например

А нет планов добавить блок with для таких случаев?

Есть такое https://github.com/yandex/ClickHouse/blob/b7f8ac1f2db2553fb02779a2b13ee09e6e99c9af/dbms/tests/queries/0_stateless/00490_with_select.sql Но это не CTE

ну селектни ее, она в пейджкеше осядет:) а ты какую задачу этим хочешь решить?

А есть еще возможность как то сложить таблицу в память целиком? Т.е. есть у меня таблица, которая весит например 50 гигов, оперативы у меня 256 гигов. Можно как то затолкать ее в оперативу, что бы данные читать не с таблицы?

Первый запрос будет читать данные с диска, все последующие - из памяти

Привет! Ты где?

ну селектни ее, она в пейджкеше осядет:) а ты какую задачу этим хочешь решить?

У меня просто есть маленькая таблица в которой не много строк, но много nested строк в разных колонках. Я ее разворачиваю в разных подзапросах и бывает по многу раз )

У меня просто есть маленькая таблица в которой не много строк, но много nested строк в разных колонках. Я ее разворачиваю в разных подзапросах и бывает по многу раз )

Возможно вам поможет материализованная вьюха, она хранит данные на диске. Возможно в вашем случае это поможет

Запросы получаются по 700 строк в высоту ) Работает очень быстро на сервере под нагрузкой

А я так полагаю, что бы вот такое добро "IFNULL(IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') >= DATE_SUB(NOW(), INTERVAL 3 MONTH), 'До 3-х мес.', IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') >= DATE_SUB(NOW(), INTERVAL 1 YEAR), 'До года', IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') >= DATE_SUB(NOW(), INTERVAL 3 YEAR), 'До 3-х лет', IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') <= DATE_SUB(NOW(), INTERVAL 3 YEAR), 'Более 3-х лет', NULL)))), 'Прочее')" сунуть в словарь в качестве expression, нужно это завернуть в CDATA?

Динамические часовые пояса похоже не предусмотрены? toStartOfDay(date_field, dictGetString('customer_timezones', 'tz_name', toUInt64(customerid))) = DB::Exception: Illegal column ColumnString of second (time zone) argument of function toStartOfDay, must be constant string.

А я так полагаю, что бы вот такое добро "IFNULL(IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') >= DATE_SUB(NOW(), INTERVAL 3 MONTH), 'До 3-х мес.', IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') >= DATE_SUB(NOW(), INTERVAL 1 YEAR), 'До года', IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') >= DATE_SUB(NOW(), INTERVAL 3 YEAR), 'До 3-х лет', IF (STR_TO_DATE(position_date, '%d.%m.%Y %r') <= DATE_SUB(NOW(), INTERVAL 3 YEAR), 'Более 3-х лет', NULL)))), 'Прочее')" сунуть в словарь в качестве expression, нужно это завернуть в CDATA?

Собственно да :) Нужно завернуть в CDATA. Спасибо за expression! Без него было бы плохо )

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

Господа, подскажите мне очень интересно, а инсталляции clickhouse в яндексе в какой таймзоне работают? в MSK или в UTC?????

думаем какую бы TIME ZONE по дефолту поставить

Настройка - основные - Часовой пояс. я так думаю

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

Если у вас данные только приходят нужно ли перезаливать их? Почему недостаточно дописать дельту? Или писать в кх когда уже все устаканилось. Не очень понятно какую проблему решаете. Если бывают апдейты - посмотрите в сторону ReplacingMergeTree.

Ждать не хочется, потому что данные за вчера нужны уже сегодня, а устаканиться может только через пару дней. С дельтой попробую, спасибо, а ReplacingMergeTree не гарантирует отсутствия дупликатов(

Optimize final ‘table’ for partion ‘date’

Документация к сожалению не под рукой

Optimize final ‘table’ for partion ‘date’

OPTIMIZE TABLE xxxx PARTITION 201709 FINAL;

Спасибо!

Будет ли это более оптимально, чем если я удалю всю партицию и залью из уже имеющихся файликов?

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

Привет, поскажите пожалуйста, как внешние данные к запросу добавить? У меня странная ошибка Code: 62. DB::Exception: Syntax error: failed at position 1 (line 1, col 1): spark.ru hom, expected CHECK

Привет, поскажите пожалуйста, как внешние данные к запросу добавить? У меня странная ошибка Code: 62. DB::Exception: Syntax error: failed at position 1 (line 1, col 1): spark.ru hom, expected CHECK

Покажите запрос и describe table, кажется что тут пробоема не во внешних данных

cat data | clickhouse-client --user=xxx --password=xxx --host=xxx --external --file=- --name=_data --structure='host String'

$ cat data one two three

вот так работает

но мне надо каким-то макаром еще огромный запрос пропихнуть

cat data | clickhouse-client --user=xxx --password=xxx --host=xxx --external --file=- --name=_data --structure='host String' --query="select * from _data"

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

Не могу я создать таблицу) Нет прав)

https://clickhouse.yandex/docs/ru/table_engines/external_data.html

попробуйте запрос передвинуть в начало, перед external

да с запросом все работает

Есть дурацкии вопрос, но что-то я подзавис. Есть таблица с 2мя столбцами: value и key. Мне надо чтобы если key=1 считало AVG(value), а если key=2 то SUM(value), ну тоесть 2 запроса как бы select avg(value) from MyTable where key=1; select sum(value) from MyTable where key=2; Хочется в 1 запрос (а значит и скан по диску) поститать. Рождается такое "кака" select avg(value) as avg, sum(value) as sum, key where key in (1, 2) group by key. Но тут получается мы считаем также sum для key=1 и avg для key=2 что также неоптимально. Можно что-то мудренее (чтобы работало быстрее и ресурсов тратило маньше) придумать?

но я хочу запрос постом передать

Есть дурацкии вопрос, но что-то я подзавис. Есть таблица с 2мя столбцами: value и key. Мне надо чтобы если key=1 считало AVG(value), а если key=2 то SUM(value), ну тоесть 2 запроса как бы select avg(value) from MyTable where key=1; select sum(value) from MyTable where key=2; Хочется в 1 запрос (а значит и скан по диску) поститать. Рождается такое "кака" select avg(value) as avg, sum(value) as sum, key where key in (1, 2) group by key. Но тут получается мы считаем также sum для key=1 и avg для key=2 что также неоптимально. Можно что-то мудренее (чтобы работало быстрее и ресурсов тратило маньше) придумать?

В целом, нормально выглядит. Можно еще через countIf / sumIf написать. Но не должно быть заметно быстрее.

Понял. Спсб. Где-то внутри точит червячек, пока задавлю :)

Есть дурацкии вопрос, но что-то я подзавис. Есть таблица с 2мя столбцами: value и key. Мне надо чтобы если key=1 считало AVG(value), а если key=2 то SUM(value), ну тоесть 2 запроса как бы select avg(value) from MyTable where key=1; select sum(value) from MyTable where key=2; Хочется в 1 запрос (а значит и скан по диску) поститать. Рождается такое "кака" select avg(value) as avg, sum(value) as sum, key where key in (1, 2) group by key. Но тут получается мы считаем также sum для key=1 и avg для key=2 что также неоптимально. Можно что-то мудренее (чтобы работало быстрее и ресурсов тратило маньше) придумать?

а у вас этот запрос тормозит?

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

sum/avg это по процу достаточно дешево, а if в clickhouse считает обе свои части, ну и джампы/конвейеры. вот это все, еще неизвестно что дороже окажется. если у вас key в ключе и данные по нему локализованы, то может вообще быстрее будет два запроса сделать.

так а в чём проблема запроса с условными агрегатными функциями? если вот так сделать: select sumIf(val, key=1), avgIf(val, key=2) from MyTable два запроса - это 2 скана таблицы, один запрос - один скан понятно что условный агрегат скорее всего дороже безусловного, но если делать отдельными запросами - там тожебудут условия

sumIf и avgIf не видел. Похоже на то что надо. Что быстрее тоже интересно будет. Надо документацию перечитать, забывать стал

P R А версия какая? Эти опции кажется в 254 ввели или где то там. Не так что бы совсем давно.

ClickHouse client version 1.1.54245.

ClickHouse client version 1.1.54245.

у меня ClickHouse client version 1.1.54288. игнор ошибок работает нормально всегда... clickhouse-client --help | grep allow видит свойства по игнору ошибок? Вообще наверное лучше в любом случае проапдейтиться. Там много всяких фиксов было в промежутке.

Ок, попробую

Приветик! решил обновить CH atp upgrade (stable). Клиент обновился, сервер нет )

рестарт сделайте