Кстати, а можно как-нибудь получить SHOW CREATE TABLE в таком же симпатичном формате, в котором clickhouse-client его выводит, собственно, при создании таблицы (или VIEW): в несколько строчек, с отступами и подсветкой?

https://github.com/yandex/ClickHouse/blob/master/dbms/include/DB/Interpreters/Settings.h#L118

спасибо!

По результатам замеров json* значительно медленнее tsv & CSV для Format

@the_real_jkee

?

Ну, ничего удивительного как бы

проверяли сегодня. выгребка данных в CSV - 5 секунд, в JSON - 24 секунды

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

Локально?

Во что упирается

Выглядит очень странно

Только http?

результат получившихся файлов, для csv - 7mb, json - 12 mb

да. проверяли клиентом локально с сервером

Клиентом? Почему клиентом?

wget

А. Интересно

Надо смотреть, посмотрим

Хочу стикеры clickhouse и митап в Москве ;)

Хочу стикеры clickhouse! :)

Хочу стикеры clickhouse! :)

плюсую. с гордостью повешаю на ноут

Вот смотрю на эксперимент - aggregation_memory_efficient_merge_threads = 2 работает, сильно быстрее, чем с 1, но память прям на пределе.

Потребление оперативки пропорционально зависит от aggregation_memory_efficient_merge_threads: чем больше потоков делают мерж, тем пропорциоально больше требуется оперативки. Недавно эта настройка была выставлена в 1 по-умолчанию, так как параллельный мерж был недоработан. Но сейчас он работает корректно и количество потоков выбирается по количеству ядер. Алгоритм мержа промежуточных данных таков, что при мерже потребляется количество оперативки, примерно в 256 раз меньше, чем размер всего состояния, умножить на число потоков для мержа. Проще говоря, данные разбиваются на 256 партиций, и соответствующие партиции мержатся по отдельности. Конечно, для очень больших состояний такого разбиения может быть недостаточно. При распределённой обработке запроса, также следует выставить настройку distributed_aggregation_memory_efficient. Грубо говоря, она означает: при распределённой обработке запроса, читать данные и мержить по кусочкам, а не всё сразу.

Спасибо

В реальности у меня не получилось работать при коэффициенте больше 1. Память всегда превышала Maxmem.

глядя на https://github.com/yandex/ClickHouse/compare/v1.1.54112-stable...v1.1.54127-stable?diff=split&name=v1.1.54127-stable думается мне что https://github.com/yandex/ClickHouse/commit/599308aef03bdfcf49778845dc69d2403b0b08ea могло быть не лучшей идей. хотя я тот еще чтец с++

Это сделано для упрощения сборки. Раньше людям приходилось отдельно ставить библиотку-клиента для MongoDB. Причём, эта библиотека уже была объявлена устаревшей. Также, так как эта библиотека с C++ интерфейсом, то при изменении опций сборки, связанных с C++ ABI, требовалась пересборка этой библиотеки. Было много вопросов от внешних пользователей и для удобства её пришлось убрать, когда представилась возможность.

Борюсь с запросами, где group by по десятку полей, часть из которых вызов словарей и, возможно, джойны. Вертика их как семечки щелкает, а кликхаус уходит в астрал

А тут нужно конкретное сравнение с примерами запросов и описанием данных.

О, а я уронил clickhouse. Прибил по Ctrl-C в clickhouse-client создание VIEW. debian, clickhouse-{client,server-{base,common}}-1.1.54159 http://pastebin.com/eXEumprX

Спасибо. Информации из стек трейса, надеюсь, достаточно.

Кстати, а можно как-нибудь получить SHOW CREATE TABLE в таком же симпатичном формате, в котором clickhouse-client его выводит, собственно, при создании таблицы (или VIEW): в несколько строчек, с отступами и подсветкой?

А подсветка в каком виде требуется? Если просто с отступами, то копированием из терминала...

проверяли сегодня. выгребка данных в CSV - 5 секунд, в JSON - 24 секунды

Я раньше оптимизировал это место (например, валидацию UTF-8, которая выполняется при записи JSON), но видимо недостаточно. Кстати, это просто JSON, JSONCompact или JSONEachRow?

Хочу стикеры clickhouse и митап в Москве ;)

Митап в Москве, наверное, следующий после Санкт-Петербурга. Ориентировочно конец марта или начало апреля. Но точные даты пока ещё неизвестны. Да, хотим сделать что-нибудь интересное :)

А подсветка в каком виде требуется? Если просто с отступами, то копированием из терминала...

SHOW CREATE TABLE выводит без отступов. То есть, я хочу в симпатичном виде стуктуру для старых таблиц. Если я умный и скопировал вывод когда делал сам CREATE TABLE, то это слишком просто. Вообще выглядит так, как будто clickhouse-client умеет форматировать запросы и красиво их выводить когда их делает. Вот бы попросить его делать то же самое с тем, что вернулось в SHOW CREATE TABLE.

Друзья, а с чего можно начать обучение работе с кх? Может курс какой есть на курсере ? Дока официальная сложной кажется, нужно что - то фундаментальное ))

фундаментальное - как раз дока. Если уж кликхаус кажется сложным, то хз что посоветовать. Тот кто хоть немного знаком с mysql/pgsql/oracle (да и в целом с каким-нибудь диалектом sql) въехать обычно вообще не составляет труда. Другое дело, что пока из-за ограниченных возможностей sql-подобного языка приходится постоянно костылить что-то в запросах. Я не разраб и то въехал за пару-тройку дней не напрягаясь. На хабре есть статьи, есть квик старт на офиц странице, этого более чем, чтобы начать, а дальше только дока.

Спасибо , буьу копать )

Привет всем. Есть такая конструкция. У меня 4 сервера. И 3 шарда. Каждый шарда это 2 реплики - один сервер разный а один одинаковый. Т.е. Один сервер содержит данные для каждого шарда.Подскажите как правильно создавать таблици на сервере под три реплики. С конфигурационым файлом вроде все просто.

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

Привет всем. Есть такая конструкция. У меня 4 сервера. И 3 шарда. Каждый шарда это 2 реплики - один сервер разный а один одинаковый. Т.е. Один сервер содержит данные для каждого шарда.Подскажите как правильно создавать таблици на сервере под три реплики. С конфигурационым файлом вроде все просто.

А зачем такая сложная конструкция. Почему не сделать просто 2 шарда, 2 реплики?

Это конструкция упрощенная от той которую мы разворачиваем. Но суть такая же. Три сервера с быстрыми винтами, а один с медленными, но объем большой. Рассудит так что быстрые дадут скорость,а медленные сохранность данных

Рассудили*

А, не понял сразу схему. Тогда все просто на первых трёх реплицируемые таблицы с одинаковым именем и номерами шардов 1, 2, 3 и своими именами реплик. На 4м три реплицируемые таблицы с разными именами

На первых трёх distributed таблица поверх 3 быстрых серверов

На 4м если надо делать запросы, то обернуть Merge таблицей

Т.е. имена таблиц на репликацию никак не влияют, влияют настройки таблиц (в т.ч. ключ в ЗК)

Рассудили*

Кстати в телеграмма можно редактировать сообщения

Ага.спасибо сейчас попробую.

На 4м если надо делать запросы, то обернуть Merge таблицей

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

Значит создать Merge таблицу которая будет указывать на 3 локальных таблицы с данными

спасибо. сейчас попробуем

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

Да, участников уже больше чем наше помещение :) Надеемся, будет трансляция.

Да, участников уже больше чем наше помещение :) Надеемся, будет трансляция.

Но один из них регистрировался после меня....(((((

А, не понял сразу схему. Тогда все просто на первых трёх реплицируемые таблицы с одинаковым именем и номерами шардов 1, 2, 3 и своими именами реплик. На 4м три реплицируемые таблицы с разными именами

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

Если писать напрямую в одну из 3х реплицируемых таблиц на нем - будет

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

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

Если писать напрямую в одну из 3х реплицируемых таблиц на нем - будет

А можно еще вопрос, а можно решить так что бы сервер на котором лежат все реплики мог принимать данные, так что бы шарда не выпадала, в случае если писат через distributed таблицу?

А вставка через distributed таблицу реально нужна?

думаю да. мы механизмов для вставки посредсвенно в таблици не реализовывали.

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

Да, лучше

Если таблицы обычные MergeTree то вставлять через Distributed смысла нет

Если Replacing, Aggregatingи т.д. то уже надо

да такие

Там все просто на самом деле. Каждая вставка - это новая партиция, которую серверу потом мержить + запись в ЗК для реплицируемых таблиц

Алексей на митапе от 21.11.2016 говорил что функционал, который мы хотим есть. вот только как это делается я не нашел, может не знаю где искать

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

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

Я не пробовал никогда, Но разве не делается распределенная поверх реплицируемой?

Если нужно иметь функционал вставки и запросов на все машины, мне видится вариант поднять три кх на одном сервере (в каком-нибудь докере) и наставить кластер как полноценные 3 шарда и 2 реплики

Я не пробовал никогда, Но разве не делается распределенная поверх реплицируемой?

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

Указать три реплики и сделать реплицируемую таблицу?

я к стати попробовал, сделать как вы писали. У меня получается 7 серверов, два из них медленных. получаеться что один шард это три сервера, один всегда разный два повторяются. все шардов пять на медленных серврах, сделал таблици с разными именами, всего пять таблиц. создал одну распеределенную таблицу, влил чучуть данных. все поделилось четко между реплецируемыми таблицами. фигня в том что кода первый раз сделал запрос к распределенной - то оно сказало нет таблиц на медленных, которые оно должно смотреть\обращатся. Я создал Merge таблицу, которая смотрит сразу в пять реплецируемых и когда делаю подсчет строк, через распределенную таблицу - то колю строк в таблице всегда разное.

мне кажется проблема в том что Merge смотрит сразу в пять реплецируемы таблиц

Будет кому-то это полезно если я заведу тему в ГуглГруппах?

Ох, вот это схема. Я правильно понимаю, что есть 5 быстрых серверов = 5 шардов и 2 медленных?

да)

Распределенная таблица должна смотреть только на 5 быстрых шардов

Если нужно делать запросы к медленным, то на них надо создать по Merge таблицы и Distributed поверх только Merge уже на этих двух

Но я лично сильно не рекомендую такие сложные схему. На этом фоне докер смотрится куда лучше

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

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

Да и это не важно

Этот конфиг просто говорит Dist таблице, как делать запросы

И что у этой таблици есть копия на другом сервере

Но этот конфиг вообще никак не влияет на репликацию

Вот пример создания таблицы из доки ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)

Что бы сделать реплику надо создать таблицу с аналогичным ключом в ЗК (первый параметр) и другим {replica}

Кстати не обязательно указывать переменные из macroc, можно просто задать руками

Т.е. условно таблыцы выглядят так (на примере 3х машин: fast1, fast2 и slow1) Сервер fast1 ReplicatedMergeTree('/clickhouse/tables/1/hits', 'fast1', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) Сервер fast2 ReplicatedMergeTree('/clickhouse/tables/2/hits', 'fast2', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) Сервер slow1 ReplicatedMergeTree('/clickhouse/tables/1/hits', 'slow1', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192) ReplicatedMergeTree('/clickhouse/tables/2/hits', 'slow1', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)

Надеюсь понятно объяснил

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

Но правда лучше подумать о докере и делать по виртуальной slow на каждый fast. Это позволит нормально работать с Dist таблицами

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

Я раньше оптимизировал это место (например, валидацию UTF-8, которая выполняется при записи JSON), но видимо недостаточно. Кстати, это просто JSON, JSONCompact или JSONEachRow?

да, JSON медленнее всего - 24 секунды. JSONEachRow - 6 секунд, CSV - 5. но мы исправили оплошность в коде поменяв на TabSeparated

Доброе утро! Правильно ли я понимаю, что <remote_servers incl="clickhouse_remote_servers" /> смотри в clickhouse_remote_servers.xml?

да

Нет.

?

Подстановки, указанные в incl="..." достаются из файла с подстановками (по-умолчанию, /etc/metrika.xml), из элемента с указанным именем. Для примера, в /etc/metrika.xml может быть написано: <yandex> <clickhouse_remote_servers> <double> <node> <host>127.0.0.1</host> <port>9000</port> </node> <node> <host>127.0.0.2</host> <port>9000</port> </node> </double> </clickhouse_remote_servers> </yandex>

Нужно будет прямо в конфиге это прокомментировать, иначе может быть не очевидно. В документации это описано здесь: https://clickhouse.yandex/reference_ru.html#%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5%20%D1%84%D0%B0%D0%B9%D0%BB%D1%8B

Xml в мобильном браузере еще ужаснее.