Кому верить, и что делать, если схлопывания данных на практике не происходит, хотя на вид всё сконфигурировано правильно?

Верить коду и тестам. https://github.com/yandex/ClickHouse/blob/master/dbms/tests/integration/test_graphite_merge_tree/configs/graphite_rollup.xml Остальные источники могут ошибаться :)

@orantius, у вас в clickhouse.yandex/docs/en/formats в боковом баре есть пару битых ссылок. Например:

Там микрореволюция / уборка в документации происходила :) Вы как раз видимо угодили в момент актуализации - сейчас про форматы тут: https://clickhouse.yandex/docs/en/interfaces/formats/ Пуллреквест тут: https://github.com/yandex/ClickHouse/pull/2659

Привет! Подскажите, пожалуйста, а есть способ запустить clickhouse с readonly на все replicated-таблицы? Где-то находил в документации, а так же вот тут в исходниках https://github.com/yandex/ClickHouse/blob/master/dbms/src/Storages/StorageReplicatedMergeTree.cpp - что достаточно просто убрать из конфига описание zookeeper-кластера, но у меня он в таком режиме сигфолтится (версия 1.1.54388)

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

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

Попробую, спасибо!

С несуществующими машинками - падает с лаконичным 2018.07.19 18:05:24.948742 [ 1 ] <Error> Application: Host not found: blabla.net

С пустым элементом zookeeper - Cannot create table from metadata file /var/lib/clickhouse/metadata/dbname//table_name.sql, error: ZooKeeperImpl::Exception: No addresses passed to ZooKeeper constructor. (Bad arguments), stack trace: И тоже не стартует. Но без segfault'а, да :)

С несуществующими машинками - падает с лаконичным 2018.07.19 18:05:24.948742 [ 1 ] <Error> Application: Host not found: blabla.net

Хм. А если 127.0.0.1 + любой закрытый порт? :)

2018.07.19 18:46:19.802132 [ 1 ] <Error> Application: DB::Exception: Cannot create table from metadata file /var/lib/clickhouse/metadata/db_name//table_name.sql, error: ZooKeeperImpl::Exception: All connection tries failed while connecting to ZooKeeper. Addresses: 127.0.0.1:33533

Тоже не стартует

Есть опыт, какая из библиотек шустрее? официальная по верх http? https://github.com/housepower/ClickHouse-Native-JDBC https://github.com/yandex/clickhouse-jdbc

Есть опыт, какая из библиотек шустрее? официальная по верх http? https://github.com/housepower/ClickHouse-Native-JDBC https://github.com/yandex/clickhouse-jdbc

С помощью HTTP у нас получалось вставлять несколько Гбит/сек, причём даже в формате VALUES, а не RowBinary. Я думаю, в подавляющем большинстве случаев интерфейс не будет узким местом :).

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

clickhouse-jdbc держит HTTP коннекшен пул

Ребят, а у кого-то получалось запихнуть pd.DataFrame со столбцом из списков в ClickHouse, где под это дело есть колонка типа Array(String)?

clickhouse-jdbc держит HTTP коннекшен пул

нужна какая то тонкая настройка? есть пример?

нужна какая то тонкая настройка? есть пример?

нет, он просто работает, главное пул не закрывать :)

так а как пул создать. я через датасоурс работаю

так а как пул создать. я через датасоурс работаю

он там создается, главное не закрывать конекшен

https://github.com/yandex/clickhouse-jdbc/blob/master/src/main/java/ru/yandex/clickhouse/ClickHouseConnectionImpl.java#L197

спасибо

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

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

Как мне кажется, на 2 из 3 нод всё должно работать нормально :). Но это если там правда их было 3

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

Господа, у меня такой вопрос возник. Вот у нас есть таблица с такой структурой: ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup') В ней хранятся графитовые метрики. В первичный ключ у нас входит строковое поле Path и время. Партиции, которые создал ClickHouse, выглядят следующим образом: 20180610_20180611_6676093_6700911_7 (партиций для каждого месяца по 20-30 штук) . Насколько я понимаю, для int'овых полей имя 6676093_6700911 означало бы диапазон первичного ключа 6676093 — 6700911, но что это означает для строковых полей? Вероятнее всего, берется хэш от строки, а значит запросы вида WHERE Path = 'моя_строка' и тем более WHERE Path = 'мой_префикс%' будут идти во все партиции? Или как это работает :)? Спрашиваю, потому что такие запросы выполняются неприлично долго, скорость чтения состаляет сотни тысяч строк в секунду вместо ожидаемых сотен миллионов :). Второй раз исполняется уже быстрее, но тоже долго. Хочется понять, почему так происходит и правильно ли я понимаю, как партиции разбиваются по файлам.

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

2 из трех не могут дать кворум, для кворума нужно чтоб половина машин + 1 ответили ОК

2 из трех не могут дать кворум, для кворума нужно чтоб половина машин + 1 ответили ОК

то есть минималкой можно считать 5?

нет - 4 там нужно чтоб 3-и ноды ответили ОК (4/2+1), но лучше 5 серверов, тогда 2 ноды могут "откинуться" на время

нет - 4 там нужно чтоб 3-и ноды ответили ОК (4/2+1), но лучше 5 серверов, тогда 2 ноды могут "откинуться" на время

это именно особенность зукипера? потому что в консуле 2х из 3х хватает для кворума

Привет, странный вопрос, полез сверять system.events а у меня на разных нодах разное количество типов евентов, например на 3 нодах есть а на одно нету LeaderElectionAcquiredLeadership - это хорошо или плохо ?

Это значит, что данный эвент на ноде ещё не произошёл

это именно особенность зукипера? потому что в консуле 2х из 3х хватает для кворума

Да, зукиперу нужно половина + 1. У ZK - ZAB, у Консула - Raft

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

2-х зукиперов из трёх должно хватать

2-х зукиперов из трёх должно хватать

ну вот не хватает, сваливается в RO

в недавних версиях был баг, что при отсыхании сессии ClickHouse переподключался не сразу

у вас долго ro продолжается?

(не сразу = 30 секунд)

ну вообще на некоторых инстансах может быть до рестарта

Там еще сам ZK должен лидера переназначить, если сервера вхардкожены в конфиг то, по идее, он будет думать что их 3 и 2 оставшихся большинство (не всегда это работает, но у нас ZK сейчас старый и в нем, судя по issue есть куча багов, надо обновлять), при динамической конфигурации при смерти одной ноды из 3-х он вполне может считать что их всего 2-е и тут точно кворума не будет

ну вообще на некоторых инстансах может быть до рестарта

на тех иснтансах все три ноды Зукипера прописаны? и оставшиеся две доступны?

прописаны все три

он в логи должен писать что делает и что не получилось

А нет ли случайно планов поддержать etcd?

Гугл говорит что SlowRead проставляется в 1 когда с диска медленее 1Mb\s читает, можно ему верить ?

Гугл говорит что SlowRead проставляется в 1 когда с диска медленее 1Mb\s читает, можно ему верить ?

Вроде есть такая настройка, как раз мегабайт там стоит

Интересно, а как КХ использует индекс если написать where toYYYYMM(поле_дата)= сканируется весь индекс? или разворачивается в нормальное условие >= начало <= конец ?

Интересно, а как КХ использует индекс если написать where toYYYYMM(поле_дата)= сканируется весь индекс? или разворачивается в нормальное условие >= начало <= конец ?

это же несложно проверить)))

привет, подскажите насколько зрела идея хранить финансовые транзакции в кх? какова вероятность что-то не записать на диск как например в монге

это же несложно проверить)))

ну да, код взять да и прочитать. (в смысле я знаю что индекс используется, но не могу понять каким образом, если идет скан всего индекса, то я буду продолжать писать условие >= начало <= конец)

привет, подскажите насколько зрела идея хранить финансовые транзакции в кх? какова вероятность что-то не записать на диск как например в монге

Очень плохо идея из за отсутствия транзакций.

Очень плохо идея из за отсутствия транзакций.

инсерт происходит частично в некоторых случаях?

идея апендонли для раздачи юзерам данных

@orantius, у вас в clickhouse.yandex/docs/en/formats в боковом баре есть пару битых ссылок. Например:

Спасибо, сейчас поправим.

Кому верить, и что делать, если схлопывания данных на практике не происходит, хотя на вид всё сконфигурировано правильно?

Есть настройка optimize_throw_if_noop. Выставите в 1 и сделайте OPTIMIZE. Он напишет причину.

В clickhouse нет случайно pointInPolygon, только для geography type как в Postgis?

В ClickHouse нет geography type - pointInPolygon работает для точек на плоскости.

Привет! Подскажите, пожалуйста, а есть способ запустить clickhouse с readonly на все replicated-таблицы? Где-то находил в документации, а так же вот тут в исходниках https://github.com/yandex/ClickHouse/blob/master/dbms/src/Storages/StorageReplicatedMergeTree.cpp - что достаточно просто убрать из конфига описание zookeeper-кластера, но у меня он в таком режиме сигфолтится (версия 1.1.54388)

Должно нормально работать и с полностью удалённой секцией zookeeper, Пришлите стек трейс, который вывелся в логе.

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

С двумя из трёх нод ZK работает нормально. Возможно временное (обычно десятки секунд) состояние readonly, если он был подключен к тому серверу, который выпал. После этого переподключится и всё будет Ок.

2 из трех не могут дать кворум, для кворума нужно чтоб половина машин + 1 ответили ОК

Тут неправда.

нет - 4 там нужно чтоб 3-и ноды ответили ОК (4/2+1), но лучше 5 серверов, тогда 2 ноды могут "откинуться" на время

Типичной инсталляцией ZK является 3 сервера. Увеличение количества серверов до 5 редко имеет смысл - так как кластер будет масштабироваться только по чтению, а по записи будет лишь деградировать.

С двумя из трёх нод ZK работает нормально. Возможно временное (обычно десятки секунд) состояние readonly, если он был подключен к тому серверу, который выпал. После этого переподключится и всё будет Ок.

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

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

Все три.

идея апендонли для раздачи юзерам данных

В ClickHouse нет полноценных транзакций, тем не менее, есть свойства транзакционности, которые позволяют записывать данные надёжно. Так, каждый INSERT атомарен (с размером батча до 1 млн. строк по-умолчанию).

Свойства репликации: https://yandex.github.io/clickhouse-presentations/rit2018/#23

Господа, у меня такой вопрос возник. Вот у нас есть таблица с такой структурой: ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup') В ней хранятся графитовые метрики. В первичный ключ у нас входит строковое поле Path и время. Партиции, которые создал ClickHouse, выглядят следующим образом: 20180610_20180611_6676093_6700911_7 (партиций для каждого месяца по 20-30 штук) . Насколько я понимаю, для int'овых полей имя 6676093_6700911 означало бы диапазон первичного ключа 6676093 — 6700911, но что это означает для строковых полей? Вероятнее всего, берется хэш от строки, а значит запросы вида WHERE Path = 'моя_строка' и тем более WHERE Path = 'мой_префикс%' будут идти во все партиции? Или как это работает :)? Спрашиваю, потому что такие запросы выполняются неприлично долго, скорость чтения состаляет сотни тысяч строк в секунду вместо ожидаемых сотен миллионов :). Второй раз исполняется уже быстрее, но тоже долго. Хочется понять, почему так происходит и правильно ли я понимаю, как партиции разбиваются по файлам.

6676093 - это последовательный номер вставки. Он говорит о том, что в таблицу, в данную партицию, было сделано примерно 6 676 093 INSERT-ов. Для хорошей производительности в WHERE надо указывать условия и на первичный ключ (например, Path = 'мой_префикс%') и на ключ партиционирования (например, Date >= '2018-07-20'). Если есть условия на Time, то условия на Date всё-равно нужны.

В ClickHouse нет полноценных транзакций, тем не менее, есть свойства транзакционности, которые позволяют записывать данные надёжно. Так, каждый INSERT атомарен (с размером батча до 1 млн. строк по-умолчанию).

партиции на репликах эквивалентны? то есть если я на мастере деатачу партицию Х и на репликах тоже самое я получу на репликах копию мастера?

партиции на репликах эквивалентны? то есть если я на мастере деатачу партицию Х и на репликах тоже самое я получу на репликах копию мастера?

Да. Реплики синхронизируются до побайтово идентичных данных в идентичных партициях. Запросы ATTACH/DETACH реплицируются.

то есть только с мастера можно партиции убрать и оно само догонит на репликах?

то есть только с мастера можно партиции убрать и оно само догонит на репликах?

Если выполнить DETACH PARTITION на одной реплике, то партиция будет detached на всех репликах.

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

И возможно ли это в принципе? Или может можно подключить R-ные библиотеки написанные на сях

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

Ещё никто не подключал, насколько мне известно. Есть наоборот - возможность из R работать с ClickHouse.

Из R уже работаем, полет отличный! Интересно, можно ли сделать обратно. В принципе, очень хочется иметь возможность писать полноценный код прямо в clickhouse. По аналогии с KDB.

и Q

например, чтобы можно было посчитать линейную регрессию не открывая питон или R

6676093 - это последовательный номер вставки. Он говорит о том, что в таблицу, в данную партицию, было сделано примерно 6 676 093 INSERT-ов. Для хорошей производительности в WHERE надо указывать условия и на первичный ключ (например, Path = 'мой_префикс%') и на ключ партиционирования (например, Date >= '2018-07-20'). Если есть условия на Time, то условия на Date всё-равно нужны.

Мы все указываем :). Но при чтении с диска на диапазоне данных в 1 год или даже 6 месяцев производительность очень низкая (даже в 30 сек запрос не укладывается иногда). На самом сервере диски не особо нагружены, CPU тоже.

Мы все указываем :). Но при чтении с диска на диапазоне данных в 1 год или даже 6 месяцев производительность очень низкая (даже в 30 сек запрос не укладывается иногда). На самом сервере диски не особо нагружены, CPU тоже.

Посмотрите в логе. Там написано Will read сколько-то ranges in сколько-то parts. Это пропорционально числу дисковых seek-ов.

например, чтобы можно было посчитать линейную регрессию не открывая питон или R

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

Тут неправда.

Да. Тут совршенно неправда) Если у ZK 3-и сервера, то 2 из 3-х - кворум, 3/2+1=2, но, в действительности это не всегда работает (у нас есть старый кластер ZK для кафки и ZK там какой-то совсем "лохматый из коробки" и ведет себя он, скажем так, не всегда адекватно). Что касаемо последней стабильной, я, если честно не проверял, оно пока просто работает, могу сегодня попробовать погасить сервера оставив минимум который должен дать кворум и посмотрю что будет, интересно стало.

Да. Тут совршенно неправда) Если у ZK 3-и сервера, то 2 из 3-х - кворум, 3/2+1=2, но, в действительности это не всегда работает (у нас есть старый кластер ZK для кафки и ZK там какой-то совсем "лохматый из коробки" и ведет себя он, скажем так, не всегда адекватно). Что касаемо последней стабильной, я, если честно не проверял, оно пока просто работает, могу сегодня попробовать погасить сервера оставив минимум который должен дать кворум и посмотрю что будет, интересно стало.

Проверял несколько раз плюс были даунтаймы в ДЦ, два их трёх дают кворум версия дефолтная из убунту 1604

Аналогично. Вообще, зк из трёх у меня полностью сломался только после переполнения диска на двух из трёх, после чего уменьшил интервал между логами и их количество на диске.

Проверял несколько раз плюс были даунтаймы в ДЦ, два их трёх дают кворум версия дефолтная из убунту 1604

OK, возможно у меня на 3-х была неведомая фигня как у @gtbear. Перепроверю на актуальных версиях и если все ОК буду спать еще крепче.

подскажите почему может появляться ошибка Code: 23, e.displayText() = DB::Exception: Cannot read from istream, e.what() = DB::Exception? Есть шард с двумя репликами. На одной реплике где то 1.5Т данных. На другой реплике данных нет. То есть организовали репликацию. Канал между репликами 10Гбит/с. Я почти уверен, что проблем с железом нет (не наблюдаю не ошибок, ничего). Данные начинают перетикать. В какой то момент трафик вырастает до 8Гбит/с и так это работать может дня два.. толку нуль. На дисках наблюдаю работу как при репликации на других шардах (на двух шардах репликация завершилась успешно в пределах полудня, данных так же 1.5Т). В system.replication_queue вижу очередь с типом GET_PART. Получается данные идут, но крайне мелкими порциями… Есть идеи?

6676093 - это последовательный номер вставки. Он говорит о том, что в таблицу, в данную партицию, было сделано примерно 6 676 093 INSERT-ов. Для хорошей производительности в WHERE надо указывать условия и на первичный ключ (например, Path = 'мой_префикс%') и на ключ партиционирования (например, Date >= '2018-07-20'). Если есть условия на Time, то условия на Date всё-равно нужны.

Кстати, а есть где-то статьи или хоть что-то что можно почитать на предмет - каким лучше делать индекс?

Кстати, а есть где-то статьи или хоть что-то что можно почитать на предмет - каким лучше делать индекс?

https://groups.google.com/forum/#!searchin/clickhouse/%D0%B8%D0%BD%D0%B4%D0%B5%D0%BA%D1%81%7Csort:relevance/clickhouse/eUrsP30VtSU/p4-pxgdXAgAJ

Спасибо!

Добрый день, коллеги. Помогите пожалуйста примонтировать папку для хранения БД с хостовой машины в докер контейнер. https://github.com/yandex/ClickHouse/issues/2690

Добавьте в volume еще папку логов КХ -v ${VOLUME}/logs:/var/log/clickhouse-server