у нас только реплика

Если только реплика - всё ок

Для распределенных запросов можно тоже указать пароль

Указывается вот так <replica> <host>HOST</host> <port>9000</port> <user>user</user> <password>passwd</password> </replica>

спасибо!

Следующий митап в Санкт-Петербурге, 28 февраля: https://events.yandex.ru/events/meetings/28-february-2017/ Ещё есть возможность зарегистрироваться.

Следующий митап в Санкт-Петербурге, 28 февраля: https://events.yandex.ru/events/meetings/28-february-2017/ Ещё есть возможность зарегистрироваться.

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

Ещё не начали присылать. Наверное, на следующей неделе.

А как в словаре корректно описать, чтобы null value могло быть null?

их там 2-е, какой именно ?

вот этот https://github.com/roistat/go-clickhouse

вроде бы был, если вы про https://github.com/roistat/go-clickhouse/issues/14, то да, драйвер работает поверх http и такая возможность должна быть echo "(IPv4StringToNum('192.0.2.1'))" | POST 'http://localhost:8123/?query=INSERT INTO stats.tt VALUES' :) select * from tt; SELECT * FROM tt ┌─────────ip─┐ │ 3221225985 │ └────────────┘

> @milovidov_an Алексей, добрый день! Мы обновили CH до версии: 1.1.54140. Перестали загружаться встроенные гео-словари со следующей ошибкой: <Error> EmbeddedDictionaries: Cannot load dictionary! You must resolve this manually.: Code: 0, e.displayText() = DB::Exception: Region id is too large: 1000006, should be not more than 1000000 Судя по коду: https://github.com/yandex/ClickHouse/blob/master/dbms/src/Dictionaries/Embedded/RegionsHierarchy.cpp#L41 https://github.com/yandex/ClickHouse/blob/master/dbms/src/Dictionaries/Embedded/RegionsNames.cpp#L59 это ограничение: const size_t max_size = 1000000; Но наши словари опираются на базу geonames.org, на которую, в т.ч., опирается поставщик данных MaxMind, где максимальный geoname_id (в терминах CH - это region_id), который используется нами - это 11073439. Появилось это в этом коммите https://github.com/yandex/ClickHouse/commit/f9eb536825ae3cfab65b1d8d37a2bdd67c58010d С чем связанно такое ограничение max_size ? Можно ли предложить PR по увеличению этого лимита до 20 млн ?

вроде бы был, если вы про https://github.com/roistat/go-clickhouse/issues/14, то да, драйвер работает поверх http и такая возможность должна быть echo "(IPv4StringToNum('192.0.2.1'))" | POST 'http://localhost:8123/?query=INSERT INTO stats.tt VALUES' :) select * from tt; SELECT * FROM tt ┌─────────ip─┐ │ 3221225985 │ └────────────┘

не полуается сделать такое из библитеки

> @milovidov_an Алексей, добрый день! Мы обновили CH до версии: 1.1.54140. Перестали загружаться встроенные гео-словари со следующей ошибкой: <Error> EmbeddedDictionaries: Cannot load dictionary! You must resolve this manually.: Code: 0, e.displayText() = DB::Exception: Region id is too large: 1000006, should be not more than 1000000 Судя по коду: https://github.com/yandex/ClickHouse/blob/master/dbms/src/Dictionaries/Embedded/RegionsHierarchy.cpp#L41 https://github.com/yandex/ClickHouse/blob/master/dbms/src/Dictionaries/Embedded/RegionsNames.cpp#L59 это ограничение: const size_t max_size = 1000000; Но наши словари опираются на базу geonames.org, на которую, в т.ч., опирается поставщик данных MaxMind, где максимальный geoname_id (в терминах CH - это region_id), который используется нами - это 11073439. Появилось это в этом коммите https://github.com/yandex/ClickHouse/commit/f9eb536825ae3cfab65b1d8d37a2bdd67c58010d С чем связанно такое ограничение max_size ? Можно ли предложить PR по увеличению этого лимита до 20 млн ?

Действительно. Выглядит как надуманное ограничение. Такое ощущение, что предполагалось, что вся геобаза будет лежать в виде недо-хэштаблицы (т.е. попросту массива размером миллион), где комфортно расположились бы все айдишники по порядку, почти без пропусков, видимо из какой-то внутренней яндексовской геобазы. Я нашёл вариант, как это "закостылить" и прикрутить сюда базу максмайнд: перенумеровать айдишники максмайнд и создать кастомный внешний словарь с отображением из одних id в другие (+скрипт для регулярного обновления получившегося дикта). Только так появляется возможность использовать встроенные в КХ геофункции. Разумеется, остаётся ещё вариант использовать собственные внешние словари, а не геофункции КХ. Но, конечно, я не оставляю надежды, что разработчики кх исправят этот недочет, и добавят возможность использовать обычные хэш-таблицы для хранения геобазы.

> @milovidov_an Алексей, добрый день! Мы обновили CH до версии: 1.1.54140. Перестали загружаться встроенные гео-словари со следующей ошибкой: <Error> EmbeddedDictionaries: Cannot load dictionary! You must resolve this manually.: Code: 0, e.displayText() = DB::Exception: Region id is too large: 1000006, should be not more than 1000000 Судя по коду: https://github.com/yandex/ClickHouse/blob/master/dbms/src/Dictionaries/Embedded/RegionsHierarchy.cpp#L41 https://github.com/yandex/ClickHouse/blob/master/dbms/src/Dictionaries/Embedded/RegionsNames.cpp#L59 это ограничение: const size_t max_size = 1000000; Но наши словари опираются на базу geonames.org, на которую, в т.ч., опирается поставщик данных MaxMind, где максимальный geoname_id (в терминах CH - это region_id), который используется нами - это 11073439. Появилось это в этом коммите https://github.com/yandex/ClickHouse/commit/f9eb536825ae3cfab65b1d8d37a2bdd67c58010d С чем связанно такое ограничение max_size ? Можно ли предложить PR по увеличению этого лимита до 20 млн ?

Если до этого всё работало нормально, то давай PR, и просто увеличим.

Но с такими id оно не оптимально - много оперативки впустую. Конечно лучше было бы сделать так, чтобы для больших id-ов конвертировалось в хэш таблицу.

Но с такими id оно не оптимально - много оперативки впустую. Конечно лучше было бы сделать так, чтобы для больших id-ов конвертировалось в хэш таблицу.

Да

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

Ну так, субъективно что-то вообще поменяется принципиально?

Даже без хэшей будет хэш-таблица, просто остаток от деления и последовательный поиск при разрешении коллизий

> @milovidov_an Если до этого всё работало нормально, то давай PR, и просто увеличим. Мы проблем не заметили на предыдущих версиях CH, но у нас всегда был словарь MaxMind и возможно оно быстрее и лучше работало используя мы дополнительное хеширования, предложу PR с 20М т.к. мне кажется - это уже проблема "пользователя" что он хочет загрузить 20М записей в словарь )) Еще доп. вопрос : Как отреагирует CH на __понижение__ версии сервера? Пробовали в Yandex в продакшене даунгрейд ? Или это сильно индивидуально, зависит от правок которые вносились в код между версиями. Мы думали как оперативно поправить проблему с этим geo, и варианта только два : даунгрейд или пересобрать из исходников deb. До этого мы использовали ваш репозиторий. Понижать стало страшно, вдруг данные потеряются )

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

Да, я это проверял, когда делал специализации для 8 и 16 битных ключей для GROUP BY. Числа не помню, но можно проверить заново. Стоит заметить, что когда id-ы сильно разреженные и их много, то плоский массив, наоборот, будет работать хуже хэш-таблицы.

Добрый вечер. Если у нас есть таблица, созданная CREATE TABLE test( Year UInt16, Name String ) ENGINE =...; то как сделать запрос INSERT INTO test FORMAT JSONEachRow { "Year": [1, 10], "Name":["a", "b"] }

Повторю вопрос :) Может в оживленной дискуссии не заметили: Было бы круто увидеть CH vs Kudu (https://kudu.apache.org/). Делал кто-нибудь интересно?

> @milovidov_an Если до этого всё работало нормально, то давай PR, и просто увеличим. Мы проблем не заметили на предыдущих версиях CH, но у нас всегда был словарь MaxMind и возможно оно быстрее и лучше работало используя мы дополнительное хеширования, предложу PR с 20М т.к. мне кажется - это уже проблема "пользователя" что он хочет загрузить 20М записей в словарь )) Еще доп. вопрос : Как отреагирует CH на __понижение__ версии сервера? Пробовали в Yandex в продакшене даунгрейд ? Или это сильно индивидуально, зависит от правок которые вносились в код между версиями. Мы думали как оперативно поправить проблему с этим geo, и варианта только два : даунгрейд или пересобрать из исходников deb. До этого мы использовали ваш репозиторий. Понижать стало страшно, вдруг данные потеряются )

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

Повторю вопрос :) Может в оживленной дискуссии не заметили: Было бы круто увидеть CH vs Kudu (https://kudu.apache.org/). Делал кто-нибудь интересно?

Я не припоминаю.

А как?

а какой у вас язык? можно ещё утилитой POST, wget, curl

на Питоне хорошо себя показал по скорости pycurl, несколько медленнее, но чуть удобнее requests, можно использовать ещё orm для clickhouse, созданную поверх requests, насколько я знаю https://github.com/Infinidat/infi.clickhouse_orm

Добрый вечер. Если у нас есть таблица, созданная CREATE TABLE test( Year UInt16, Name String ) ENGINE =...; то как сделать запрос INSERT INTO test FORMAT JSONEachRow { "Year": [1, 10], "Name":["a", "b"] }

К слову, у вас такой запрос не прокатит, ведь Year и Name — не массивы. Нужно передать в теле пост-запроса 2 отдельные строчки, одну {"Year": 1, "Name": "a"}, а другую аналогично, но для 10 и "b"

К слову, у вас такой запрос не прокатит, ведь Year и Name — не массивы. Нужно передать в теле пост-запроса 2 отдельные строчки, одну {"Year": 1, "Name": "a"}, а другую аналогично, но для 10 и "b"

Но вот так работает CREATE TABLE ontime ( s String, nest Nested( x UInt8, y UInt32), FlightDate Date ) ENGINE = MergeTree(FlightDate, (s, FlightDate), 8192); INSERT INTO ontime VALUES ('Hello', [1,2], [10,20], 34657), ('World', [3,4,5], [30,40,50],346572), ('Goodbye', [], [],3465736)

Ага

Ага

А в json никак?

Можно

Но вот так работает CREATE TABLE ontime ( s String, nest Nested( x UInt8, y UInt32), FlightDate Date ) ENGINE = MergeTree(FlightDate, (s, FlightDate), 8192); INSERT INTO ontime VALUES ('Hello', [1,2], [10,20], 34657), ('World', [3,4,5], [30,40,50],346572), ('Goodbye', [], [],3465736)

Здесь у вас получается аналогичный джсон для первой строки: {"s": "Hello", "nest.x": [1, 2], "nest.y": [10,20], "FlightDate": 34567}

Здесь у вас получается аналогичный джсон для первой строки: {"s": "Hello", "nest.x": [1, 2], "nest.y": [10,20], "FlightDate": 34567}

Спасибо!

А как в словаре корректно описать, чтобы null value могло быть null?

NULL в словарях не поддерживаются.

Здесь у вас получается аналогичный джсон для первой строки: {"s": "Hello", "nest.x": [1, 2], "nest.y": [10,20], "FlightDate": 34567}

получается, что классический json нельзя записать?

Какой классический?

А, не

Нужно его расплющить сперва

без полей вида nest.x

Из nested-вида сделать flat такой

жаль

мы рассматривали вариант размаппить объект в json и сразу записать

Ну так оно и внутри хранится, наверное поэтому выбран такой вид

Ну так оно и внутри хранится, наверное поэтому выбран такой вид

да, логично все, конечно, но жаль))

мы рассматривали вариант размаппить объект в json и сразу записать

Ну всё решается маленькой утилитарной функцией, которая расплющивает джсон

еще одну звезду на гитхабе до 2к!

пожалуйста... еще одна одна звезда - 2k

Повторю вопрос :) Может в оживленной дискуссии не заметили: Было бы круто увидеть CH vs Kudu (https://kudu.apache.org/). Делал кто-нибудь интересно?

Добрый день! мы планируем сделать в ближайший месяц... только не в чистом виде kudu а impala + kudu

Коллеги вопрос а не предполагается ли выложить опенсорс софт для управлением кластером ....

У нас к сожалению нет такого софта, который можно было бы выложить.

Есть разный набор скриптов в нескольких частях компании

Если основная боль - это применение ддл, то это есть в планах

Коллеги, в чем может быть проблема? DB::Exception: Unknown function decodeURLComponent

в том, что у вас старая версия сервера?)

есть такое предположение)

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

а когда функция появилась?)

> Aleksey Коллеги вопрос а не предполагается ли выложить опенсорс софт для управлением кластером .... На сколько мне известно, в открытом доступе только моя попытка сделать миграции в кластее, https://habrahabr.ru/company/smi2/blog/317682/

> Konstantin а когда функция появилась?) Можно проверить через select * from system.functions where name like '%deco%'

а "когда появилась" можно узнать на гитхабе https://github.com/yandex/ClickHouse/search?utf8=%E2%9C%93&q=decodeurlcomponent ~15-30 декабря. подробнее - с помощью git blame )

спасибо))

Коллеги подскажите, пожалуйста, в какой файл и в какое место прописать сервера zookeeper? из документации мне не очевидно :( <zookeeper-servers> ...</zookeeper-servers>

https://clickhouse.yandex/reference_ru.html#ReplicatedSummingMergeTree

Спасибо:) Там вроде zookeeper-servers было, а сейчас просто zookeeper. Странно, видимо уработался

можете посоветовать насчёт timeSlot

хочу вывести квадратики разных цветов, heatmap: когда была максимальная посещаемость

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

(toUnixTimestamp(intDiv(toUInt32(created_at), 86400) * 86400)) as date

можно просто toDate(created_at)

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

вместо 86400 может что-то другое быть, например час

вопрос про timeSlot — это прям прибито гвоздями 30 минут?

toHour же тоже есть, и toStartOf(Five)Minute

конечно все еще не так гибко

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

т.е. вдруг они дадут какой-то перфоманс, как было с переходом с регекспа на UUID функции

вообще да, было бы логично и клево

здравствуйте, подскажите пожалуйста(возможно оффтоп): использую go кдиент для вставки данных в CH, если делаю вставку батчами по 1000 то все ок, а если увеличиваю размер батча до 5к,10к, то получаю ошибку clickhouse error: [27] DB::Exception: Cannot parse input: expected , before..., причем если вставить эту row(на которой случилась ошибка) отдельн то все ок. Это ведь всего в go клиенте? Данные для вставки всегд одинаковые

да, похоже на баг в клиенте

клиент какой?? roistat ??

судя по ошибке - да

Да, просите, забыл клиент указать(ошибочно думал что он один) roistat/go-clickhouse

попробуйте написать issue в их github

Селект дня select count(*), count(distinct application_key) from dw.dim_application final format Vertical; count(): 29295092 uniq(application_key): 29304655 И конечно, понятно почему так, но в исходном синтаксисе выглядит прикольно

а если позапускать - цифры меняются?)

нет, uniq детерминированный