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

Хороший вариант, работает. Можно еще через снапшот, но очень аккуратно, чтобы КХ ничего не успел дописать после создания снапшота

Привет! У меня вопрос по формату выходных данных. В документации сказано, что в формате TabSeparated значения NULL передаются как \N. Но я заметил, что если возвращаются Tuple'ы, в которых есть Nullable значения, то в них все равно пишется NULL, за место \N. Так и должно быть? Например после выполнения запросов: > CREATE TABLE t (a Nullable(UInt8), b Tuple(Nullable(UInt8), UInt8)) ENGINE = Memory > INSERT INTO t VALUES (NULL, (NULL, 1)) > SELECT * FROM tВернется строка \\N\t(NULL,1)\n

Хороший вариант, работает. Можно еще через снапшот, но очень аккуратно, чтобы КХ ничего не успел дописать после создания снапшота

Спасибо, буду пробовать

Привет! У меня вопрос по формату выходных данных. В документации сказано, что в формате TabSeparated значения NULL передаются как \N. Но я заметил, что если возвращаются Tuple'ы, в которых есть Nullable значения, то в них все равно пишется NULL, за место \N. Так и должно быть? Например после выполнения запросов: > CREATE TABLE t (a Nullable(UInt8), b Tuple(Nullable(UInt8), UInt8)) ENGINE = Memory > INSERT INTO t VALUES (NULL, (NULL, 1)) > SELECT * FROM tВернется строка \\N\t(NULL,1)\n

А, разобрался, нашел в открытых issues.

Привет! У меня вопрос по формату выходных данных. В документации сказано, что в формате TabSeparated значения NULL передаются как \N. Но я заметил, что если возвращаются Tuple'ы, в которых есть Nullable значения, то в них все равно пишется NULL, за место \N. Так и должно быть? Например после выполнения запросов: > CREATE TABLE t (a Nullable(UInt8), b Tuple(Nullable(UInt8), UInt8)) ENGINE = Memory > INSERT INTO t VALUES (NULL, (NULL, 1)) > SELECT * FROM tВернется строка \\N\t(NULL,1)\n

Вы можете сделать select ... format TSV

И там увидите как эта штука пишется

И там увидите как эта штука пишется

Да, именно так и делал, в примере забыл указать

подскажите, пожалйуста, в каком файле нужно прописать max_bytes_before_external_sort, max_memory_usage, max_bytes_before_external_group_by ? я так понимаю задать нужно для пользователя? просто в наших конфигах есть только параметр max_memory_usage, хотя ClickHouse этого года

и нужно ли сервак рестартить?

в профайл в users.xml

рестартить не надо

Вопрос к уважаемой команде разработки. Сам новый релиз не пробовал, но имею вопрос. Использование group by wirh rollup реализовано хардкорно, или перформанс будет схож с Array join массивов с комбинациями колонок?

Имеет ли смысл под значения с id использовать int если стринги все равно хешируются, и уникальных значений этих Id планируется пару десятков. В общем,у меня вопрос цены удобства 1345 или "Вася"?

рестартить не надо

Спасибо. Разобрались, у клика не было прав читать созданные препрцессед файлы

Имеет ли смысл под значения с id использовать int если стринги все равно хешируются, и уникальных значений этих Id планируется пару десятков. В общем,у меня вопрос цены удобства 1345 или "Вася"?

Звучит как сценарий для LowCardinality(String)

Вопрос к уважаемой команде разработки. Сам новый релиз не пробовал, но имею вопрос. Использование group by wirh rollup реализовано хардкорно, или перформанс будет схож с Array join массивов с комбинациями колонок?

rollup реализован так: столбцы по-очереди заполняются дефолтными значениями и блок доагрегируется по оставшимся колонкам.

Вопрос к уважаемой команде разработки. Сам новый релиз не пробовал, но имею вопрос. Использование group by wirh rollup реализовано хардкорно, или перформанс будет схож с Array join массивов с комбинациями колонок?

Будет работать лучше, чем arrayJoin - и быстрее и меньше памяти расходуется.

Наши аналитики тоже сейчас делают через arrayJoin, но это получается неудобно - надо писать несколько arrayJoin-ов и куча времени тратится на размножение строк. GROUP BY WITH ROLLUP позволяет этого избежать.

Наши аналитики тоже сейчас делают через arrayJoin, но это получается неудобно - надо писать несколько arrayJoin-ов и куча времени тратится на размножение строк. GROUP BY WITH ROLLUP позволяет этого избежать.

У нас запросы пишут роботы для роботов) Но ввиду сказанного, будем резко переделывать на rollup

Подскажите, пожалуйста - в доке написано, что SELECT ... FROM table FINAL работает только для CollapsingMergeTree. Это правда? Проверить в данный момент нет возможности, а информация нужна. У меня есть ощущение, что всё работало и для ReplacingMergeTree, но я не уверен.

У нас запросы пишут роботы для роботов) Но ввиду сказанного, будем резко переделывать на rollup

SELECT arrayJoin([RegionID, 0]) AS k1, arrayJoin([SearchEngineID, 0]) AS k2, count() FROM test.hits GROUP BY k1, k2 ORDER BY count() DESC LIMIT 10 242 мс. SELECT RegionID AS k1, SearchEngineID AS k2, count() FROM test.hits GROUP BY k1, k2 WITH ROLLUP ORDER BY count() DESC LIMIT 10 43 мс. Правда первое - это всё-таки аналог WITH CUBE, которого ещё нет.

Подскажите, пожалуйста - в доке написано, что SELECT ... FROM table FINAL работает только для CollapsingMergeTree. Это правда? Проверить в данный момент нет возможности, а информация нужна. У меня есть ощущение, что всё работало и для ReplacingMergeTree, но я не уверен.

Неправда. Работает для всех таблиц, для которых слияние делает какие-то вычисления.

Неправда. Работает для всех таблиц, для которых слияние делает какие-то вычисления.

Значит, косяк в документации

спасибо

SELECT arrayJoin([RegionID, 0]) AS k1, arrayJoin([SearchEngineID, 0]) AS k2, count() FROM test.hits GROUP BY k1, k2 ORDER BY count() DESC LIMIT 10 242 мс. SELECT RegionID AS k1, SearchEngineID AS k2, count() FROM test.hits GROUP BY k1, k2 WITH ROLLUP ORDER BY count() DESC LIMIT 10 43 мс. Правда первое - это всё-таки аналог WITH CUBE, которого ещё нет.

Да, я скорее cube имел в виду

Создал issue https://github.com/yandex/ClickHouse/issues/3105

>Возможность использования дублирующихся столбцов в секции USING для JOIN #3006 а как эту возможность отключить? :) джойны поломались с апдейтом

>Возможность использования дублирующихся столбцов в секции USING для JOIN #3006 а как эту возможность отключить? :) джойны поломались с апдейтом

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

такой вот запрос `SELECT * FROM ( SELECT MainID, COUNT() AS cnt FROM table1 GROUP BY MainID ) ANY LEFT JOIN ( SELECT MainID, AddField1, AddField2 FROM table2 ) USING (MainID)` выдает таблицу со структурой MainID, cnt, MainID, AddField1, AddField2 раньше (на 18.04) было MainID, cnt, AddField1, AddField2

такой вот запрос `SELECT * FROM ( SELECT MainID, COUNT() AS cnt FROM table1 GROUP BY MainID ) ANY LEFT JOIN ( SELECT MainID, AddField1, AddField2 FROM table2 ) USING (MainID)` выдает таблицу со структурой MainID, cnt, MainID, AddField1, AddField2 раньше (на 18.04) было MainID, cnt, AddField1, AddField2

Ставьте asterisk_left_columns_only = 1.

а это в каком конфиге? не вижу в доках пока

Настройка уровня пользователя. Сначала проверьте запрос в клиенте командной строки с помощью SET.

В старой версии такой запрос должен был выдавать MainID, cnt

да, сработало, спасибо

@milovidov_an у нас была беда с сервером и в папке distributed таблицы лежат папочки типа default@10%2E20%2E116%2E11:9000,default@10%2E20%2E117%2E9:9000 - как их дописать в таблицу?

а как сделать селект без этой настройки, но чтобы было в одном экземпляре? перечислить явно без *?

а как сделать селект без этой настройки, но чтобы было в одном экземпляре? перечислить явно без *?

Без этой настройки всё работает так же, как раньше (как в предыдущей версии 18.10.3 и раньше). Да, перечислять явно.

ну да, я просто с 18.4 обновился

@milovidov_an у нас была беда с сервером и в папке distributed таблицы лежат папочки типа default@10%2E20%2E116%2E11:9000,default@10%2E20%2E117%2E9:9000 - как их дописать в таблицу?

В этих директориях находятся файлы с данными для отправки на удалённые серверы. Файлы .bin. Distributed таблица берёт файлы из этой очереди и пытается отправить. Если их не получается отправить, об этом будут сообщения в логе сервера. Надо посмотреть, в чём там проблема. Типичные проблемы: - изменился IP адрес сервера - надо исправить его в имени директории и перезапустить clickhouse-server; - файл побился на файловой системе - можно отложить его в сторону, чтобы остальные файлы отправились.

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

И distributed тоже на всякий случай пересоздали, предварительно "сбекапив" эти временные куски

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

Проверил права - все принадлежит clickhouse пользователю. Алгоритм был такой: Скопировали /var/lib/clickhouse/data/DB/TABLE/* в отдельную папку Удалили папку с таблицей, удалили все мета-данные, при этом зукипер был абсолютно пустой Создали таблицу Положили файлики туда где они и были, т.е. в /var/lib/clickhouse/data/DB/TABLE/* В логах сейчас пусто, т.е. КХ будто бы не видит эти папки вообще.

Проверил права - все принадлежит clickhouse пользователю. Алгоритм был такой: Скопировали /var/lib/clickhouse/data/DB/TABLE/* в отдельную папку Удалили папку с таблицей, удалили все мета-данные, при этом зукипер был абсолютно пустой Создали таблицу Положили файлики туда где они и были, т.е. в /var/lib/clickhouse/data/DB/TABLE/* В логах сейчас пусто, т.е. КХ будто бы не видит эти папки вообще.

Просто подложить файлы с кусками данных в директорию таблицы - не работает. Надо положить их в директорию detached, затем выполнить запросы ALTER TABLE ... ATTACH PARTITION для каждой партиции.

Да, мы так и сделали, но есть директории типа default@IP:PORT...

аттач мы делали для merge tree таблицы, там все ок и все взлетело, а вот distributed - беда

аттач мы делали для merge tree таблицы, там все ок и все взлетело, а вот distributed - беда

Проблема в том, что Distributed таблица не видит данные, которые вы для неё подложили? Возможно, что она всё-таки не обновляет список файлов без перезагрузки. Чтобы не перзагружать сервер, можно сделать DETACH TABLE и ATTACH TABLE для этой таблицы. Также стоит проверить, что имена директорий соответствуют конфигурации кластера.

Проблема в том, что Distributed таблица не видит данные, которые вы для неё подложили? - да. Файлы, которые должны разлететься по шардам. Detach и attach таблицы не помог ( В логах пусто (

Проблема в том, что Distributed таблица не видит данные, которые вы для неё подложили? - да. Файлы, которые должны разлететься по шардам. Detach и attach таблицы не помог ( В логах пусто (

Сделайте вставку в эту Distributed таблицу, посмотрите где создастся файл, как он отправится. Возможно, что что-то перепутано в путях.

Сделайте вставку в эту Distributed таблицу, посмотрите где создастся файл, как он отправится. Возможно, что что-то перепутано в путях.

Все, прошло! Видимо он "подвис" ) Данные проглотились после детача и атача! Спасибо!

Просто он почему-то не сразу их вписал

Там есть exponential backoff при ошибках - время повтора увеличивается до 30 сек.

Ну вобщем оно прошло, но после детача и не моментално, а спустя какое-то время

Hello here на сколько хорошо работает JSONEachRow при вставке большого обема данных?

к примеру 50-100 тыс строк за вставку

Количество данных, вставляемых за один раз - это не проблема. В целом по throughput формат менее эффективен чем CSV, TSV - за счёт парсинга имён полей. При достаточно большом размере пачки throughput (количество строк в секунду) не зависит от объёма данных, отправляемых за один раз.

а на сколько он менее эффективен?

Приблизительно пропорционально объёму данных в текстовом виде. Например, файл в JSONEachRow весит в два раза больше, чем CSV - будет примерно в два раза медленнее. Но возможны вариации в зависимости от конкретных типов данных. Обычно разница менее чем пропорциональная.

если буду писать по 500 тыс строк раз в 5-10 секунд то деградации производительности не сильно будет заметно?

если буду писать по 500 тыс строк раз в 5-10 секунд то деградации производительности не сильно будет заметно?

Размер пачки - Ок. Вставка в JSONEachRow менее эффективна, чем в CSV или TSV. Впрочем, если у вас уже есть данные в JSONEachRow, то вставка их сразу в этом формате, будет более эффективной, чем предварительная конвертация.

Также иногда форматирование в JSONEachRow на стороне своих программ оказывается более эффективным, чем в CSV или TSV.

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

Добрый утро, коллеги Требуются консалтинговые услуги по CH Кому интересно пишите в личку Спасибо

если деньги есть то вам к альтинити

если нет то проще тут поспрашивать

Поначалу пока проект только стартует достаточно будет иметь человека имеющего опыта для решения оперативных вопросов

Альтинити не гуглится, можно ссылку?

Альтинити не гуглится, можно ссылку?

https://www.altinity.com/clickhouse/

Спасибо

Но мы приоритет отдаем сейчас отдельным кадрам с опытом

Доброе утро! Подскажите, пожалуйста, что за ошибка? Как пофиксить? default.{table} (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 235, e.displayText() = DB::Exception: Part 20180409_2_4_1 (state Committed) already exists, e.what() = DB::Exception

Всем привет! Наблюдается проблема с обновлением внешних словарей (из постгреса), проверял в версиях 18.12.5 - 18.12.13 Словари создаются/обновляются при старте кликхауса (это можно увидеть в колонке creation_time в таблице `system.dictionaries`). При следующих попытках обновления (через 5 минут, согласно настройкам) падает исключение (колонка last_exception той же таблицы): Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found В логах:``` 2018.09.12 05:28:11.448817 [ 52 ] <Error> ExternalDictionaries: Cannot update external dictionary 'bundle_ids', leaving old version: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found ` Доступ к БД постгреса есть - проверял из консоли клиентами psql и isql (последний с явным указанием настроек ODBC как для кликхауса). Выполнение запроса SYSTEM RELOAD DICTIONARIES; нормально обновляет словари (!), но спустя 5 минут проблема возвращается... Что я делаю не так?

Всем привет. Есть ли возможность из jdbc следить за статусом (процентом исполнения) запроса? Есть идеи?

Всем привет

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

реплика дает копию данных на другой машине. Если одна машина может к примеру 100 запросов в секунду, то 2 смогут 200. Вывод = SELECT условно ускоряет репликация

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

Реплика позволяет больше запросов обработать

Ускоряет запросы шардинг

реплика дает копию данных на другой машине. Если одна машина может к примеру 100 запросов в секунду, то 2 смогут 200. Вывод = SELECT условно ускоряет репликация

У вас запрос быстрее работать не станет. Их просто больше в единице времени можно будет обработать

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

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

Это делается в случае шардинга

но номинально можно дубасить в каждую реплику по 100 условных запросов и получить 200

окей. А если я хочу на двух серверах иметь полную копию данных - что делать?

подымать локально два инстанса кликхауса?

Ну смотрите. У вас запрос выполняется 5 секунд. Вы за минуту можете обработать допустим 12 таких запросов. В какой-то момент вам требуется обрабатывать 24 запроса в минуту. Вы поднимаете вторую реплику и запросы у вас так и будут выполняться по 5 секунд, просто каждая из реплик может обработать по 12 запросов.

Вот полная копия данных - это реплика. У нас 8 машин. 4 шарда по 2 реплики.

нету 8 машин. Есть две машины - на которых хочется собраться и отказоустойчивость и увеличить скорость

единстыенный выход, который я вижу - ставить в параллель два инстанса кликхауса на одной машине.

А если вас не устраивает время запроса в 5 секунд и вы хотите его уменьшить, скажем до 2.5, то вы шард добавляете и у вас запрос работает 2.5 секунды вместо 5.

А если вас не устраивает время запроса в 5 секунд и вы хотите его уменьшить, скажем до 2.5, то вы шард добавляете и у вас запрос работает 2.5 секунды вместо 5.

да, это я понял

нету 8 машин. Есть две машины - на которых хочется собраться и отказоустойчивость и увеличить скорость

Можно и одним обойтись. У альтинити вроде была статья на тему кросс-репликации

Можно и одним обойтись. У альтинити вроде была статья на тему кросс-репликации

ссылочку не найдете?

Сейчас постараюсь

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

условно имеется сервер с 72 ядрами и кучей ОЗУ. разницы по времени запроса с сервером с 2 ядрами и 64ГБ ОЗУ я не заметил