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

Думаю, это плохая идея. Лучше используйте какой-нибудь хэш. Плохая, потому что при каждом мерже, rand() будет вычияться заново и давать новый результат...

Right Join еще же должен выдавать пересечение двух таблиц ?

чьерт с Inner попутал

Думаю, это плохая идея. Лучше используйте какой-нибудь хэш. Плохая, потому что при каждом мерже, rand() будет вычияться заново и давать новый результат...

Мне надо хэшировать несколько 64-битных полей. Выбрать одно из них для сэмплирование нельзя, т.к. в одной записи обычно только одно из этих полей ненулевое. Но наверное cityHash64 подойдет, т.к. эта функция принимает произвольное число аргументов.

Подойдёт. Но лучше сделать отдельное DEFAULT поле с хэшом, и его использовать для сэмплирования.

Потому что иначе выражение для сэмплирования будет вычисляться (и соответствующие столбцы будут читаться с диска) когда нужно сэмплирования.

Ясно, спасибо. Наверное только не DEFAULT, а MATERIALIZED, зачем мне иметь возможность задавать это поле.

Да, можно MATERIALIZED.

Потому что иначе выражение для сэмплирования будет вычисляться (и соответствующие столбцы будут читаться с диска) когда нужно сэмплирования.

Хм. Выходит, что сэмплирование не помогает читать меньше данных с диска, потому что в каждом блоке данных встретятся как данные, которые будут использоваться для выполнения запроса, так и данные, которые будут откинуты. Выходит, что для запросов, у которых основная нагрузка ляжет на диск, использование сэмплирования не принесет никакой пользы, а может принести и вред, т.к. придется еще и читать 0..n столбцов для проверки сэмплирования?

Хм. Выходит, что сэмплирование не помогает читать меньше данных с диска, потому что в каждом блоке данных встретятся как данные, которые будут использоваться для выполнения запроса, так и данные, которые будут откинуты. Выходит, что для запросов, у которых основная нагрузка ляжет на диск, использование сэмплирования не принесет никакой пользы, а может принести и вред, т.к. придется еще и читать 0..n столбцов для проверки сэмплирования?

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

господа, подскажите пожалуйста если таблицу визитов можно полностью получить из таблицы хитов (т.е. делаем её только для оптимизации, она примерно в 4 раза меньше получается) стоит ли использовать для этого MATERIALIZED VIEW с AggregatingMergeTree при создании такого materialized view с populate при большом объеме данных clickhouse падает (похоже по памяти, из-за использования argMin, без него срабатывает), но думаю при постепенной вставке хитов это будет работать вопрос в том - адекватно ли так делать, или все-таки руками строить CollapsingMergeTree ?

кстати, насчет падения не всегда одинаковое поведение. иногда это выглядит так: Exception on client: Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, ::1 Connecting to database stat at localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1) (сервер при этом умирает, приходится руками поднимать) а иногда честно говорит Code: 173. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Allocator: Cannot mmap., errno: 12, strerror: Cannot allocate memory. (тогда клиент не отваливается, все продолжает работать)

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

Не стоит вязать логику склейки на clickhouse на materialized

Спасибо за ответ, а почему? При выборке что из CollapsingMergeTree что в Aggregating все равно логику склейки в агрегатные функции засовывать (только в collapsing еще sign придется использовать и дополнительно что то вставлять)

@timurkar Добрый вечер! У меня тоже была аналогичная задача по группировке данных и тоже clickhouse падал когда обрабатывал большую таблицу в materialized. Я решил так: скрипт, который работал по крону группировал данные из одной таблицы и вставлял в другую через INSERT INTO ... SELECT.

Ага, это то падение я обойду, спасибо, мне вообще понять надо можно ли идти этим путем, и почему не стоит

а, видимо понял почему, первичный ключ получится слишком длинным (в него придется добавлять id посетителя)

хотя нет.. для CollapsingMergeTree ведь тоже придется его добавлять

может быть так не стоит делать потому, что агрегация данных происходит только в рамках блока вставляемых данных. Из документации: Запрос SELECT может содержать DISTINCT, GROUP BY, ORDER BY, LIMIT... Следует иметь ввиду, что соответствующие преобразования будут выполняться независимо, на каждый блок вставляемых данных. Например, при наличии GROUP BY, данные будут агрегироваться при вставке, но только в рамках одной пачки вставляемых данных. Далее, данные не будут доагрегированы. Исключение - использование ENGINE, производящего агрегацию данных самостоятельно, например, SummingMergeTree.

AggregatingMergeTree вроде должен входить в исключения

Кстати, насчёт так называемого "первичного ключа". Википедия утверждает, что это понятие включает в себя понятие уникального ключа, но в CH первичный ключ не уникальный. Тогда почему он так называется?

он так и не называется =)

Вот же: https://clickhouse.yandex/reference_ru.html#MergeTree

некорректное название, да

Не знаю, может надо поменять

Какой-то "ключ индексирования"

Кстати, насчёт так называемого "первичного ключа". Википедия утверждает, что это понятие включает в себя понятие уникального ключа, но в CH первичный ключ не уникальный. Тогда почему он так называется?

потому что в русской википедии, как обычно, написан треш.

unique и primary - разное

в целом, да, обычно - primary key уникален.

unique и primary - разное

"в русской википедии треш". английская редиректит с primary на unique

какой язык нужен чтобы не было треша?

какой язык нужен чтобы не было треша?

учебник нужен. а не википедия.

У нас действительно такое название - и в документации и в устной речи. Потому что этот ключ "первичный" - главный ключ таблицы. И чтобы не путать с другими ключами. Можно было бы назвать более корректно - кластерный ключ, ключ сортировки и т. п.

я на всякий случай поясню свою позицию. В википедии написано определение первичного ключа для реляционных баз данных. Поэтому применение термина из википедии к Clickhouse не корректно. А треш - потому что в заголовке статьи, как обычно, не указана область применения.

Ок.

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

Ок. Но я сперва был сконфужен, читая доку, и только статья на хабре с данными про полёты убедила меня, что первичный ключ не уникальный.

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

Да, всё так работает. С мат. представлениями есть несколько тонкостей. 1. Трудности с выполнением ALTER над ними. 2. POPULATE сейчас может дать неконсистентный результат - пропустить данные, которые были вставлены во время его выполнения.

понятно, большое спасибо за ответ. у меня данных настолько немного (сотни миллионов строк, которые ваша штука обрабатывает с огромной скоростью) что эти проблемы не пугают populate я все-равно в этом виде не смогу использовать, а вместо альтера в крайнем случае пересчитаю полностью :) удобство использования перевешивает пока

Есть ли поддержка Pivot ? или надо писать страшные конструкции с умножением вывода ?

еще вопрос покажите пж. пример sql который подключает внешние справочники

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

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

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

Сформулируй плиз проблему, которую хочешь решить.

хочу что бы агрегаты выдавали точную цифру в копейку сразу после загрузки данных и не было расхождений из за того что данные не доехали на реплицируемый узел

хочу что бы агрегаты выдавали точную цифру в копейку сразу после загрузки данных и не было расхождений из за того что данные не доехали на реплицируемый узел

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

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

Кхм... Если всех "друзей" натравить на одно хранилище , то что им реплицировать ?

еще вопрос покажите пж. пример sql который подключает внешние справочники

Такого sql не, сожалению. , как я понял (специалисты пусть поправят) невозможно даже простым запрсом показать словарь. Словари подключаются конфигами. А используются -- специальными функциями в селекте к таблице фактов.

Кхм... Если всех "друзей" натравить на одно хранилище , то что им реплицировать ?

Репликацию ты сам настраиваешь, указывая сколько копий данных делать.

Репликацию ты сам настраиваешь, указывая сколько копий данных делать.

не хочу ничего реплицировать ) - пуска все читают , то что один пишет

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

А текущая, исходя из контекста в котором делали ЯКХ, должна быть share nothing -- какждый сервр работает со своей копией данных, чтобы масштабироваться без узких мест в диске.

Да можно и на один диск

Надежности только не будет

Работать будет ок, гарантии соблюдаться будут

Ого!

Один сервер пишет в файл, а многие читают?

Надежности только не будет

Надежность в энтерпрайзе делается сверх дорогими схд'шками. Для не очень больших данных с очень большим кол-вом параллельных селектов -- почему бы и нет.

Вылетают они на больших объемах в любом случае

Но если немного то вполне ок

Вылетают они на больших объемах в любом случае

Вылетают статистически, исходя из опыта? Или архитектура ЯКХ'виновата'?

> @essbase Есть ли поддержка Pivot ? Используйте конструкции с sumIf() и countIf() - очень удобные для этого > @essbase выдавали точную цифру в копейку сразу Про особенность поля Float32, в котором 1.12 + 1.31 =!= 2.43 Будьте с этим осторожны )

Да можно и на один диск

А решается при этом задача, которую Женя Расюк озвучил -- если несколько ЯКХ'ов смотрят на один файл данных, а пишет в него какой-нибудь один сервер, то смотрящие сразу увидят изменения и начнут их использовать в запросах?

Кхм... Если всех "друзей" натравить на одно хранилище , то что им реплицировать ?

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

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

clear

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

Зачем сразу фарш :) Есть же базы, которые так работают. Типа Oracle на Exadata. А вообще вот описание двух подходов к хранению данных для кластеризуемых баз: http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/

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

кхм.. да вот вопрос - есть ли возможность "читателей" перевести в режим read-only ?

кхм.. да вот вопрос - есть ли возможность "читателей" перевести в режим read-only ?

Ну без этого оно и не взлетит :)

кхм.. да вот вопрос - есть ли возможность "читателей" перевести в режим read-only ?

хотя бы на уровне операционки - подмонтировать общий каталог как RO , то ноды подхватят ?

Там не отлько в RO дело, но еще и в оповещениях читателей об изменениях.

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

Вот и интересно, рассмтривали ли разработчики всерьез такой сценарий или нет — от этого зависит его работоспособность :)

Может я что то упустил , но как вы собираетесь хранить деньги в CH ?

Так, ответы

1. Диски вылетают статистически, кликхаус тут не виноват

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

3. Деньги надо хранить не в Float а в Int

1. Диски вылетают статистически, кликхаус тут не виноват

Тут имели в виду не совсем диски в чистом виде, а какое нибудь большое дорогое хранилище и iscsi например

Умноженные на что-нибудь

А, ну тогда наверное ОК, но зачем несколько кликхаусов всё равно непонятно

А, ну тогда наверное ОК, но зачем несколько кликхаусов всё равно непонятно

Они по чтению и записи паралелятся хорошо.

Скажите, почему DISTINCT работает в несколько раз медленнее, чем GORUP BY с тем же результатом? :) SELECT DISTINCT ev_type FROM events; SELECT DISTINCT ev_type FROM events ┌─ev_type─┐ │ 0 │ │ 1 │ │ 10 │ └─────────┘ 3 rows in set. Elapsed: 6.101 sec. Processed 1.80 billion rows, 1.80 GB (294.82 million rows/s., 294.82 MB/s.) :) SELECT ev_type, count() FROM events GROUP BY ev_type; SELECT ev_type, count() FROM events GROUP BY ev_type ┌─ev_type─┬────count()─┐ │ 0 │ 1361463625 │ │ 1 │ 4366468 │ │ 10 │ 432952206 │ └─────────┴────────────┘ 3 rows in set. Elapsed: 0.955 sec. Processed 1.80 billion rows, 1.80 GB (1.88 billion rows/s., 1.88 GB/s.)

Про нагрузку вроде ясно. Не очень понятно как сейчас кликхаус себя поведет если поднять ещё несколько в RO, пока что видится, что не очень хорошо

Про DISTINCT выглядит как баг

Откроете issue?

OK

Это тоже баг в форматировании? :) SELECT DISTINCT ev_type FROM events; SELECT DISTINCT ev_type FROM events ┌─ev_type─┐ │ 10 │ │ 0 │ └─────────┘ ┌─ev_type─┐ │ 1 │ └─────────┘ 3 rows in set. Elapsed: 5.903 sec. Processed 1.80 billion rows, 1.80 GB (304.72 million rows/s., 304.72 MB/s.)

FORMAT PrettyCompactMonoBlock

это какая-то оч странная особенность поблочного чтения

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

https://github.com/yandex/ClickHouse/issues/118

Ясно-понятно.

И еще небольшой типа наброс... мне кажется, что сервер версии 1.1.54046 (из пакета) работает процентов на 10 медленнее версии 1.1.53981 (из пакета). Запускаю то один, то другой, тыкаю запросы, и первый обычно медленнее слегка.

3. Деньги надо хранить не в Float а в Int

т.е. либо во Float но без вещественной части ?

Ну это как-то странно