офигеть!)

каждый раз сложный вопрос который донимает меня неделями уже решен в CH:) Супер!

Только надо быть осторожно, в ней мало гарантий и есть небольшой риск потерять данные

в целом это для моего типа данных приемлемо

Только надо быть осторожно, в ней мало гарантий и есть небольшой риск потерять данные

то есть, Buffer таблица как раз создана для того, чтобы в нее по 1 строке записывать а она сама сливает данные в основную таблицу?

доброго времени суток! я тупой, с линуксом на вы. расскажите как правильно развернуть CH на сервере, у которого нет доступа к интернету, или поделитесь полезной ссылкой. я попытался это сделать своими кривыми руками у меня ch-сервер не запускается и пишет ошибки: "No directory, logging in with HOME=/", "access to file denied: /opt/clickhouse/core" дерьмом кидаться разрешается, ибо очень хочу поюзать CH и вытерплю все.

дык скачайте пакет если ос debian-like руками

вот отсюда: http://repo.yandex.ru/clickhouse/trusty/pool/main/c/clickhouse/

так и сделал

и поставьте у себя как sudo dpkg -i <имя_пакета>

а как запускаете?

от рута?

от рута?

да

sudo service clickhouse-server start?

скачал эти файлы, потом с помощью dpkg-scanpackage сделал apt реп и добавил его в source.list

sudo service clickhouse-server start?

да

ну sudo stat /opt/clickhouse/core

sudo stat /opt/clickhouse

и наконец sudo stat /opt

А через interserver_http_port можно произвести какие-нить деструктивные действия с сервером? Удалить данные, заальтерить или еще чего?

@rlomonosov А вы к нему напрямую обращаетесь?

Я за него беспокоюсь. Он хоть и торчит во внутреннюю сеть, но мало ли

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

Я за него беспокоюсь. Он хоть и торчит во внутреннюю сеть, но мало ли

Через него можно скачать данные. Так что во внешнюю сеть торчать не должно.

залить можно данные в лююубю таблицу или толлько настреонную как ditributed?

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

> @milovidov_an Через него можно скачать данные. Так что во внешнюю сеть торчать не должно. Скачивание не беспокоит - он действительно торчит только во внутреннюю сеть. Но по ней шарятся всякие сканеры безопасности и любят тыкать куда не просят

Всем привет! Скажите по опыту, какой подход лучше? https://groups.google.com/forum/#!topic/clickhouse/D_XGEQ6DDNE Мне кажется, что 2-й, но вроде в Метрике что-то ближе к первому используется, а?

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

5 Nested структур меня смущают тем, что у них должно быть в каждой одинаковое количество элементов. Т.е. если у одного профиля 20 целей, то мне и для всех нужно сделать массив из 20 целей с нулевыми элементами, иначе будут проблемы при развертке. В принципе это похоже на вариант с большим количеством колонок

Вообще Nested выглядит больше синтаксическим сахаром над массивом, не давая какого-то решения. Сразу возникают вопросы о слиянии, например. Я не очень понимаю, как должны сливаться два массива, так как в CH нет сложения массивов или умножения массива на число

Интуитивно хотелось сделать как-то так сначала CREATE TABLE test.stat ( date Date, offer_id UInt64, ... profiles Nested ( id UInt64, ... ), goals Nested ( id UInt64, ... ) ) ENGINE = CollapsingMergeTree(date, (date, offer_id), 8192, sign); но на самом деле это не сработает, так как целей больше профилей, и, например, запрос с array join profiles as profile, goals as goal вернет ошибку и опять же проблема со слиянием

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

реляционная*

сейчас это лежит в Postgres, есть три таблички отдельные – со статистикой маркетплейса, со статистикой по профилям, со статисткой по целям при запросах это все довольно медленно джойнится

Citusdata пробовали?

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

выделять по несколько железок кажется пока жирновато)

ок ясно ну в том плане что в Цитусдата есть columnar storage cstore_fdw и оно может вам на join, group by как то ускорить без перехода на другую платформу но чего то такого советовать вам я боюсь =) в кликхаусе вместо таблиц измерений будут "словари" и в общем я не вижу проблем в случае если у вас "много пустых значений" и вроде как джойнить словари вполне себе нормальная затея и про ARRAY JOIN почитать наверное надо еще раз внимательнее насколько оно вам подходит

за cstore_fdw спасибо, для него тоже задачка у нас есть )

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

Привет! Есть задача: заранее завести побольше логических шардов, чтобы отсрочить решардинг. И есть 2 варианта решения: 1-й вариант: поднять под каждый шард отдельный инстанс ClickHouse. Т.е. изначально на каждом физическом сервере будет несколько инстансов, а при росте количества данных мы просто разнесём инстансы по разным машинам. 2-й вариант: в рамках одного инстанса завести несколько копий-"шардов" каждой таблицы, натравить на них Merge-таблицы, а Distributed-таблицы будут смотреть уже на эти Merge-таблицы. Первый вариант выглядит более правильным, но мы сразу получаем много инстансов, усложняется администрирование. Во втором варианте смущает связка двух сложных механизмов Merge+Distributed: есть опасения по поводу производительности. Что посоветуете? P.S. В Distributed не пишем, только читаем, т.е. шардированием управляем вручную.

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

ну денормализация для ClickHouse это правильный путь =)

Привет! Есть задача: заранее завести побольше логических шардов, чтобы отсрочить решардинг. И есть 2 варианта решения: 1-й вариант: поднять под каждый шард отдельный инстанс ClickHouse. Т.е. изначально на каждом физическом сервере будет несколько инстансов, а при росте количества данных мы просто разнесём инстансы по разным машинам. 2-й вариант: в рамках одного инстанса завести несколько копий-"шардов" каждой таблицы, натравить на них Merge-таблицы, а Distributed-таблицы будут смотреть уже на эти Merge-таблицы. Первый вариант выглядит более правильным, но мы сразу получаем много инстансов, усложняется администрирование. Во втором варианте смущает связка двух сложных механизмов Merge+Distributed: есть опасения по поводу производительности. Что посоветуете? P.S. В Distributed не пишем, только читаем, т.е. шардированием управляем вручную.

Первый вариант имеет следующие недостатки: - много инстансов на одном сервере сложнее в эксплуатации: директории, порты, скрипты start/stop и т. п; - количество потоков для обработки запроса будет расчитываться неверно, придётся вручную ограничивать max_threads; - вообще, с распределением ресурсов между инстансами могут быть проблемы. Второй вариант имеет следующие недостатки: - при использовании Merge таблиц, отключается автоматический перенос в PREWHERE; В обеих вариантах, по сравнению с одной таблицей, будет чуть хуже распределение работы по ядрам.

А явно заданный PREWHERE в Merge будет работать?

Будет.

спасибо!

Чтобы состояние кластера показываел

это надо в core сделать, или можно через http интерфейс?

Лучше через HTTP интерфейс.

если бы кто написал небольшую спеку, я займусь

Здравствуйте. Скажите, а clickhouse поддерживает https из коробки, или проще поставить перед ним nginx ?

> проще поставить перед ним nginx

Окей )

А то шифрование как-то иначе не понятно как реализовать.

а что понимается под состоянием кластера? стандартный мониторинг не дает достаточно информации?

Я не знаю, что точно имел ввиду Виктор. Наверное, это картинка, где каждому серверу соответствует квадратик; наглядно представлены шарды и реплики, по цвету квадратика можно определить, жив ли сервер, посмотреть отставание реплик, какие-либо метрики производительности, а также system.processes и system.merges.

думаю, можно расширить https://github.com/f1yegor/clickhouse_exporter дополнительными запросами и на их основе построить дашборд в графане

или добавить поддержку кастомных запросов в бд, как это сделано в postgres exporter

@the_real_jkee ^

О, крутяк

Я попробую написать что хочется более детально

потому что да, часть инфы я уже собираю. https://grafana.net/dashboards/882 например replica leaders & read only replicas

к вчерашнему вопросу насчет Buffer и проблем построчной записи - добавил поддержку Buffer таблицы в проект для питона infi.clickhouse_orm, 50 тыс записей пока в течении минут 40 полет на ноутбуке нормальный, никаких проблем. если кто пользуется этой библиотекой, то вот тут код с поддержкой буфера https://github.com/Infinidat/infi.clickhouse_orm/pull/15

вы хотите сказать что 50к записей вставляются 40 минут?

или тестируете с 50к в секунду уже 40 минут?

возможно 50к записей это 20rps*40 минут.

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

Производительность при вставке данных. Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду. Что если вставлять более 1K строк чаще чем раз в секунду (большими инсертами). Как это будет сказываться на производительности? Оптимально ли это? Рекомендации указанные в руководстве относятся к инстансу/базе/таблице?

Buffer-таблицы https://clickhouse.yandex/reference_ru.html#Buffer добавляют к этому некоторые возможности.

Производительность при вставке данных. Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду. Что если вставлять более 1K строк чаще чем раз в секунду (большими инсертами). Как это будет сказываться на производительности? Оптимально ли это? Рекомендации указанные в руководстве относятся к инстансу/базе/таблице?

Батчи можно сделать больше. Например, 100k строк в секунду. В зависимости от данных, возможно до нескольких миллионов строк в секунду. Но увеличивать частоту вставок не стоит. Рекомендация относится к одной таблице. Но при наличии большого количества серверов, возможна слишком большая нагрузка на ZooKeeper, и это ограничивает частоту вставок на весь кластер.

вы хотите сказать что 50к записей вставляются 40 минут?

у меня просто такой поток реальных данных, примерно 30-100 сообщений в секунду. я их принимаю и записываю

Батчи можно сделать больше. Например, 100k строк в секунду. В зависимости от данных, возможно до нескольких миллионов строк в секунду. Но увеличивать частоту вставок не стоит. Рекомендация относится к одной таблице. Но при наличии большого количества серверов, возможна слишком большая нагрузка на ZooKeeper, и это ограничивает частоту вставок на весь кластер.

Большое количество серверов - имеется ввиду кластер из большого количества серверов?

Да.

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

Т.е. к примеру если имеем 1000 таблиц, следуем рекомендации - запись в каждую из них не чаще раз/сек, то каких-либо негативных последствий от общего количества вставок (1000/сек) ожидать не стоит?

Пытались собрать из f87ae68, не удалось скомпилировать dbms/src/Client/Client.cpp, line 254, не нашлась функция read_history. Кажется, строчкой выше написали #ifdef USE_READLINE, а имели в виду #if USE_READLINE.

А еще у вас больше 20Гб тестов, что съело место в разделе. Поправимо, то стало внезапностью.

Т.е. к примеру если имеем 1000 таблиц, следуем рекомендации - запись в каждую из них не чаще раз/сек, то каких-либо негативных последствий от общего количества вставок (1000/сек) ожидать не стоит?

Всё-таки при таком количестве таблиц могут быть проблемы с файловой системой. Если таблицы имеют одинаковую структуру, то лучше вместо этого писать всё в одну таблицу.

Пытались собрать из f87ae68, не удалось скомпилировать dbms/src/Client/Client.cpp, line 254, не нашлась функция read_history. Кажется, строчкой выше написали #ifdef USE_READLINE, а имели в виду #if USE_READLINE.

https://github.com/yandex/ClickHouse/commit/045fd6f55db37059c97c0c276e8914b096e1f6bb

Всё-таки при таком количестве таблиц могут быть проблемы с файловой системой. Если таблицы имеют одинаковую структуру, то лучше вместо этого писать всё в одну таблицу.

Еще раз спасибо! Точки над и расставлены.

https://github.com/yandex/ClickHouse/commit/045fd6f55db37059c97c0c276e8914b096e1f6bb

спасибо!

Подскажите, в коде CH нашли хеш-функции FarmHash-семейста, которые не описаны в документации: https://clickhouse.yandex/reference_ru.html#Функции хэширования SELECT farmHash64('hello') ┌─farmHash64(\'hello\')─┐ │ 14403600180753024522 │ Можем смело использовать в продакшене ? И что лучше FarmHash или CityHash ?

Подскажите, в коде CH нашли хеш-функции FarmHash-семейста, которые не описаны в документации: https://clickhouse.yandex/reference_ru.html#Функции хэширования SELECT farmHash64('hello') ┌─farmHash64(\'hello\')─┐ │ 14403600180753024522 │ Можем смело использовать в продакшене ? И что лучше FarmHash или CityHash ?

Farmhash вроде как прокачанный cityhash

Всем здрасьти в этом чяти

https://lonewolfer.files.wordpress.com/2015/01/hash-function-benchmark.png

murmurhash, милота

murmurhash, милота

Сити и ферма из него растут

Добрый день. Я верно понял, что репликация таблиц служит исключительно как failover и между репликами запросы не параллелятся? По крайней мере, у меня сложилось такое впечатление исходя из времени выполнения запроса на разных конфигурациях.

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

А есть ли надежды на то, что runningAccumulate когда-нибудь заработает не только в пределах блока?

А есть ли надежды на то, что runningAccumulate когда-нибудь заработает не только в пределах блока?

Такое в приципе можно сделать при max_threads=1

А есть ли надежды на то, что runningAccumulate когда-нибудь заработает не только в пределах блока?

Кстати сейчас есть такая особенность, что результат выполнения group by не дробится на блоки. Поэтому можно ожидать, что в текущей реализации runningAccumulate поверх агрегирующей функции будет работать "интуитивно", но на это не надо полагаться.

Анонс от Яндекс.Метрики: 14 февраля у нас будет вебинар по работе с Logs API Яндекс.Метрики и ClickHouse. Mariya Mansurova покажет, как на сырых данных строить кастомные модели атрибуции и считать Retention. Зарегистрироваться можно здесь - https://events.webinar.ru/10562/268557/

Кстати сейчас есть такая особенность, что результат выполнения group by не дробится на блоки. Поэтому можно ожидать, что в текущей реализации runningAccumulate поверх агрегирующей функции будет работать "интуитивно", но на это не надо полагаться.

При больших результатах GROUP BY, он всё-таки бъётся на блоки.

Подскажите, в коде CH нашли хеш-функции FarmHash-семейста, которые не описаны в документации: https://clickhouse.yandex/reference_ru.html#Функции хэширования SELECT farmHash64('hello') ┌─farmHash64(\'hello\')─┐ │ 14403600180753024522 │ Можем смело использовать в продакшене ? И что лучше FarmHash или CityHash ?

С имеющимися настройками, farmHash ничем не лучше cityHash. Также замечу, что результат farmHash не предназначен для сохранения куда-либо, использования для шардирования и т. п., так как по задумке должен работать по-разному в зависимости от конфигурации сборки.

> @milovidov_an С имеющимися настройками, farmHash ничем не лучше cityHash. Спасибо!