не -- recv, а --recv

убрал пробел - лучше не стало =(

ключ не прописался, вывод немного намекает на это

это я вроде понял, я не знаю как это вылечить

ключ не верный, внимательнее

Семь символов. В ключе восемь.

действительно, глаз замылился уже. Спасибо большое!!!

А как CREATE MATERIALIZED VIEW работает с ключом? Т.е у родительской таблицы есть колонки которые описаны в ключе для быстрой выборки, а в материализованном вью как будет?

И вообще вопрос про этот тип, как лучше - делать его или считать налету?

подскажите, пожалуйста, с чем может быть связана ошибка: Received exception from server: Code: 194. DB::Exception: Received from host1, IP. DB::Exception: Received from host2, IP. DB::Exception: Password required for user default. Появилась после апдейта CH, таблицы реплицируемые, выполняется альтер. На одной реплике отрабатывает, на другой всегда ругается, что нет пароля.

А как CREATE MATERIALIZED VIEW работает с ключом? Т.е у родительской таблицы есть колонки которые описаны в ключе для быстрой выборки, а в материализованном вью как будет?

Материлизованное представление наполняется тригеррами. Например есть у вас запрос типа select count() as result, date from table group by date. При вставке данных в таблицу table сработает триггер и на сколько я помню запрос будет применен на поступивший блок данных и результат запроса будет записан в материализованное представление.

Приветствую. Хочу понять, будет ли работать придуманная конфигурация. Условия задачи: 1.) Есть два датацентра, в каждом - инсталляция CH 2.) Хотим _в пределах дц_ репликацию между хостами (ReplicatedReplacingMergeTree) 3.) Хотим писать данные в каждом дц в Distributed таблицу над реплицированными 4.) Хотим читать данные с обоих дц через Distributed таблицу Конфигурация: https://gist.github.com/alex-krash/e33aafa298c6918565618c71cc53e8d7

еще 1 нубский вопрос =) есть таблица - в ней 1 столбец список ip в виде int, пытаюсь сделать select с другой таблицей где есть столбцы начало диапазона (int), конец диапазона(int), город. в mysql получается в CH нет. чтяднт?

SELECT list.ip, geo.city FROM list, geo WHERE list.ip BETWEEN geo.start AND geo.end выдает - Unknown indentifier: geo.start

Приветствую. А подскажите, вот на примере, скажем, Метрики. Есть таблица Визитов и Просмотров. Визиты как-то из Просмотров аггрегируются или пишутся отдельно, собираясь в каком-то менеджере сессий? Пробую делать подобную аггрегацию через MATERIALIZED VIEW и AggregatingMergeTree, но из-за того, что нужно делать доаггрегацию, работает все очень медленно. Идея в том, чтобы записывать только Просмотры, а представление их сразу в Визиты группировало и сохраняло.

О, я это уже спрашивал ?

В итоге мы храним в редисе кеш визитов

Заметил интересную фичу - если для генерации строчки password_sha256_hex использовать "echo pwd | sha256sum | tr -d '-'" (без -n, т.е. с символом новой строки на конце), то пароль в одном случае принимается - если делать GET запрос с basic http авторизацией

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

POST запрос уже не проходит авторизацию. ну и при указании логина/пароль в GET параметрах тоже не проходит. Вроде не баг, но с толку сбивает.

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

у нас были извращенцы другого толка ?

SELECT list.ip, geo.city FROM list, geo WHERE list.ip BETWEEN geo.start AND geo.end выдает - Unknown indentifier: geo.start

SELECT list.ip, geo.city, geo.start, geo.end FROM list, geo WHERE list.ip BETWEEN geo.start AND geo.end такой срабатывает?

Может кто сталкивался с подобной ситуацией. clickhouse-server в лог файле полностью не протоколирует большие SELECT-ы. Возможно данное ограничение отключить? Пробовал с различными настройками <logger><level>trace</level></logger> и <logger><level></level>debug</logger>. Например при размере SELECT-а более 100518 символов, запрос протоколируется и обрезается после 100518 символа.

Наткнулся на странное поведение. SELECT * FROM videoStatements ┌─learnerId─┬─videoId─┬─Range─┐ │ 1 │ test │ [0,3] │ └───────────┴─────────┴───────┘ ┌─learnerId─┬─videoId─┬─Range──┐ │ 1 │ test │ [6,10] │ └───────────┴─────────┴────────┘ 2 rows in set. Elapsed: 0.002 sec. :) select range(Range[1]) as fullRange from videoStatements SELECT range(Range[1]) AS fullRange FROM videoStatements ┌─fullRange─┐ │ [] │ └───────────┘ ┌─fullRange─────┐ │ [0,1,2,3,4,5] │ └───────────────┘

По идее должно быть две строки с [0,1,2] и [0,1,2,3,4,5]

SELECT Range[1] FROM videoStatements ┌─arrayElement(Range, 1)─┐ │ 0 │ └────────────────────────┘ ┌─arrayElement(Range, 1)─┐ │ 6 │ └────────────────────────┘

Движок Memory

Почему должно получаться [0,1,2] ?

Блин...мой косяк. Array indices is 1-based

Не знал про это )

Народ, кто-нибудь уже пробовал использовать Clickhouse, как источник данных для Tableau?

Да-да, а то у нас заказчик хочет Вертику, так как Tableau не работает с CH, а редаш его по интерфейсу не устроил.

Подскажите пожалуйста как суммировать точно флоаты А то каждый раз разный результат

суммировать флоаты "точно" - никак, храните интом

>> А то каждый раз разный результат а вот это подозрительно

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

кто-то проверял, работает ли кластер кх, когда узлы за натом?

Date DEFAULT "ЗНАЧЕНИЕ" https://clickhouse.yandex/docs/ru/query_language/queries.html?highlight=default

Date DEFAULT "ЗНАЧЕНИЕ" https://clickhouse.yandex/docs/ru/query_language/queries.html?highlight=default

как его правильно указать, ошибка выходит, если так: Date DEFAULT toDate(Date)

Date DEFAULT today()

Хотя возможно и без скобок сработает

Date DEFAULT today()

Добавить скобочки

Вот пример https://github.com/yandex/ClickHouse/blob/1d836b2bf8fef378d47258957ff74ed3a4aff136/dbms/tests/queries/0_stateless/00158_buffer_and_nonexistent_table.sql

Вот пример https://github.com/yandex/ClickHouse/blob/1d836b2bf8fef378d47258957ff74ed3a4aff136/dbms/tests/queries/0_stateless/00158_buffer_and_nonexistent_table.sql

спасибо

Всем привет, не подскажите, как через tabix csv-файл вставить в таблицу? Пробовала INSERT INTO ads.gender_urls FORMAT CSV gender_urls_result.csv предварительно загрузив файл, пишет DB::Exception: Cannot parse input: expected , at end of stream.: (at row 1)

SELECT list.ip, geo.city FROM list, geo WHERE list.ip BETWEEN geo.start AND geo.end выдает - Unknown indentifier: geo.start

ClickHouse не поддерживает такой синтаксис https://clickhouse.yandex/docs/ru/query_language/queries.html#select

При подключении к КХ через ODBC (версия драйвера от 24.08) возникает ошибка выполнения запроса CAST(Custom_SQL_Query.date AS DATE) AS tdy_date_ok похоже тип данных неверно подставляется, вместо Date пишет DATE

С недавних пор мы поддерживаем DATE как алиас для Date для совместимости.

и еще один вопрос, кликхаус за натом без проблем будет работать? Если я решу таким образом проблему смену IP у ноды

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

а если писать напрямую в шарды, то догонит? или я не правильно понял смысл пункта 2?

Если писать напрямую в шарды, то проблем нет - данные сразу попадают куда надо.

а проверить попадание точки в полигон?

Та самая штука, которую мы сейчас делаем - это и есть point in polygon :)

А как правильнее (ID) или (Date,ID) ?

По Date нет полноценного индекса - только min/max значения для отсечения целых кусков данных. Если в запросах будут условия на Date, то надо иметь её в первичном ключе, если нет - то бесполезно. Порядок тоже важен. (ID, Date) лучше, когда выбираете один ID и диапазон Date. Наоборот (Date, ID) лучше, когда выбираете одну Date и множество/диапазон ID.

И вообще вопрос про этот тип, как лучше - делать его или считать налету?

Если нет проблем с производительностью при подсчёте налету, или если иначе вам пришлось бы создавать очень много разных MAT. VIEW, то лучше считать налету.

А как CREATE MATERIALIZED VIEW работает с ключом? Т.е у родительской таблицы есть колонки которые описаны в ключе для быстрой выборки, а в материализованном вью как будет?

Работает с ключом ровно так, как вы пропишите в движке таблицы для MAT. VIEW. (Для MAT. VIEW можно прописать произвольный движок таблицы.)

Работает с ключом ровно так, как вы пропишите в движке таблицы для MAT. VIEW. (Для MAT. VIEW можно прописать произвольный движок таблицы.)

Хм, у меня исходная таблица - узкая, а конечная - широкая, вот я и думаю как лучше ...

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

Спасибо за ответ. Все муки из за попытки заставить работать отказоустойчивый кластер clickhouse в kubernetes

подскажите, пожалуйста, с чем может быть связана ошибка: Received exception from server: Code: 194. DB::Exception: Received from host1, IP. DB::Exception: Received from host2, IP. DB::Exception: Password required for user default. Появилась после апдейта CH, таблицы реплицируемые, выполняется альтер. На одной реплике отрабатывает, на другой всегда ругается, что нет пароля.

Если эта ошибка появилась после апдейта ClickHouse, то это значит, что при апдейте были изменены конфиги пользователей (users.xml) и в них как-то изменились права доступа. Хотя конфиг по-умолчанию из пакета разрешает доступ пользователю default без пароля. Можно посмотреть на конкретном сервере, откуда приходит ошибка, почему он не разрешает пользователю default соединиться. Кстати, для удобства обновлений, можно держать оригинальные конфиги из пакета без изменений, а все изменения прописывать в отдельных файлах в conf.d, users.d директориях. Так ещё и проще следить за множеством изменений.

Спасибо за ответ. Все муки из за попытки заставить работать отказоустойчивый кластер clickhouse в kubernetes

У нас в следующем релизе будет команда для сброса DNS кэшей (Запрос SYSTEM DROP DNS CACHE). (По SIGHUP пока не предусмотрено.)

Приветствую. Хочу понять, будет ли работать придуманная конфигурация. Условия задачи: 1.) Есть два датацентра, в каждом - инсталляция CH 2.) Хотим _в пределах дц_ репликацию между хостами (ReplicatedReplacingMergeTree) 3.) Хотим писать данные в каждом дц в Distributed таблицу над реплицированными 4.) Хотим читать данные с обоих дц через Distributed таблицу Конфигурация: https://gist.github.com/alex-krash/e33aafa298c6918565618c71cc53e8d7

Да, такая конфигурация возможна. Я только не понял, вы хотите чтобы разные ДЦ содержали разные данные (были "шардами") или одинаковые (были "репликами"). В зависимости от этого, нужно прописать конфигурацию в remote_servers для "unioned" кластера (в примере прописано как два шарда - это значит, что Distrbuted таблица при SELECT пойдёт в оба ДЦ, выберет в каждом по одной реплике, и объединит разные данные).

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

еще 1 нубский вопрос =) есть таблица - в ней 1 столбец список ip в виде int, пытаюсь сделать select с другой таблицей где есть столбцы начало диапазона (int), конец диапазона(int), город. в mysql получается в CH нет. чтяднт?

Да, такой JOIN сделать не получится. Но можно по-другому. Специально для работы с диапазонами IP адресов есть словарь ip_trie: https://clickhouse.yandex/docs/en/dicts/external_dicts.html#ip-trie

Приветствую. А подскажите, вот на примере, скажем, Метрики. Есть таблица Визитов и Просмотров. Визиты как-то из Просмотров аггрегируются или пишутся отдельно, собираясь в каком-то менеджере сессий? Пробую делать подобную аггрегацию через MATERIALIZED VIEW и AggregatingMergeTree, но из-за того, что нужно делать доаггрегацию, работает все очень медленно. Идея в том, чтобы записывать только Просмотры, а представление их сразу в Визиты группировало и сохраняло.

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

POST запрос уже не проходит авторизацию. ну и при указании логина/пароль в GET параметрах тоже не проходит. Вроде не баг, но с толку сбивает.

Это весьма необычно. Даже трудно предположить - неужели клиент пробует отправить пароль с добавленным символом перевода строки на конце. Разбираться пока не буду.

Может кто сталкивался с подобной ситуацией. clickhouse-server в лог файле полностью не протоколирует большие SELECT-ы. Возможно данное ограничение отключить? Пробовал с различными настройками <logger><level>trace</level></logger> и <logger><level></level>debug</logger>. Например при размере SELECT-а более 100518 символов, запрос протоколируется и обрезается после 100518 символа.

Так и есть. Настройка log_queries_cut_to_length по-умолчанию, 100000. Влияет как на логгирование в текстовый лог сервера, так и на query_log. Сделано, чтобы query_log не был слишком уж большим. Вы можете увеличить эту настройку по своему усмотрению. users.xml

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

Да, эту фичу ради эксперимента пробует делать сотрудник из другого отдела. Пока ничего нет.

Коллеги! Есть много csv файлов какой оптимальный способ загрузки? Неужели clickhouse-client --query=???

clickhouse-client --query="INSERT INTO table FORMAT CSV" весьма оптимально загружает данные, если рассматривать загрузку в один поток. Можно быстрее, если запустить несколько таких загрузок параллельно. Если файлы маленькие, то можно склеить с помощью cat.

clickhouse-client --query="INSERT INTO table FORMAT CSV" весьма оптимально загружает данные, если рассматривать загрузку в один поток. Можно быстрее, если запустить несколько таких загрузок параллельно. Если файлы маленькие, то можно склеить с помощью cat.

Спасибо, Алексей!

А уже выбрали инструмент, где можно выкладывать, такие вот советы и рекомендации. В чате их набралось уже достаточно

Нет, так и не выбрали.

А что нужно? Мне бы очень хотелось хоть чем то помочь )

Я могу развернуть на pythonanywhere )

Пока ещё не знаю. Главное - максимальное простое добавление новых Q&A, буквально парой кликов. Поэтому GitHub отпадает. Сейчас создал задачу Выбрать способ держать на официальном сайте базу вопросов и ответов. Требования: - максимальное простой способ добавления записи, буквально парой кликов (copy-paste из чата). Во вторую очередь: - возможность добавления записи пользователями; - теги, рейтинг и упорядочивание.

Приветствую. Хочу понять, будет ли работать придуманная конфигурация. Условия задачи: 1.) Есть два датацентра, в каждом - инсталляция CH 2.) Хотим _в пределах дц_ репликацию между хостами (ReplicatedReplacingMergeTree) 3.) Хотим писать данные в каждом дц в Distributed таблицу над реплицированными 4.) Хотим читать данные с обоих дц через Distributed таблицу Конфигурация: https://gist.github.com/alex-krash/e33aafa298c6918565618c71cc53e8d7

#faq

Для истории :)

Да, такая конфигурация возможна. Я только не понял, вы хотите чтобы разные ДЦ содержали разные данные (были "шардами") или одинаковые (были "репликами"). В зависимости от этого, нужно прописать конфигурацию в remote_servers для "unioned" кластера (в примере прописано как два шарда - это значит, что Distrbuted таблица при SELECT пойдёт в оба ДЦ, выберет в каждом по одной реплике, и объединит разные данные).

Спасибо за ответ! Каждый дц - сам себе шард. Ожидаемое поведение - как вы описали (мёрж результатов выборки из 2 дц)

Так и есть. Настройка log_queries_cut_to_length по-умолчанию, 100000. Влияет как на логгирование в текстовый лог сервера, так и на query_log. Сделано, чтобы query_log не был слишком уж большим. Вы можете увеличить эту настройку по своему усмотрению. users.xml

Алексей, спасибо! После добавления опции select-ы начали помещаются в log.

Да, такой JOIN сделать не получится. Но можно по-другому. Специально для работы с диапазонами IP адресов есть словарь ip_trie: https://clickhouse.yandex/docs/en/dicts/external_dicts.html#ip-trie

Алексей, спасибо за объяснение!

подскажите, пожалуйста, (со словарями еще не работал) такая структура правильная?

и должен ли тогда словарь сразу появится в КХ по запросу SELECT * FROM system.dictionaries?

да, почти сразу появится

если будет ошибка в конфиге, кликхаус напишет тебе в лог

так что пиши, не стесняйся, ничего не сломаешь

Ошибок нет. Но словарь не появляется =(

Привет. А можно ли как-то управлять лидер-репликами? Если лидер уходит в "медленный" датацентр, все встаёт колом.

Привет. Да, недавно сделали. https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md ... Added new settings for MergeTree engines (the merge_tree section in config.xml): ... replicated_can_become_leader can prevent a replica from becoming the leader (and assigning merges).

Ошибок нет. Но словарь не появляется =(

Можно проверить соответствие пути к файлу и параметру dictionaries_config в config.xml

То есть надо поставить replicated_can_become_leader в 0 на конкретной реплике, правильно я понял?

Да. config.xml, в <merge_tree>.

Господа, 9ый дебиан мимо да ?