Но это тоже небыстро

Вопрос снимается... Нашел в гуглгрупс

Вопрос снимается... Нашел в гуглгрупс

Нашел? Поделись!)

а кто-нибудь для умных домов уже приделывал clickhouse?

Но зачем

Дом умнее от этого не станет, мне кажется

Или для сенсоров?

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

для сенсоров конечно

Нашел? Поделись!)

https://groups.google.com/forum/#!topic/clickhouse/VixyOUD-K68

Добрый вечер!

Скажите, что за ошибка? https://yadi.sk/i/uzwRmaJH3HJrB2

у меня было ощущение, что где-то описывался функционал "дедубликации батчей/кусков при в ставке". Сейчас найти не могу (неужели это мне приснилось?). Идея была такая: при в ставке батча может произойти сбой на клиенете или в сети, и клиент еще раз повторит вставку батча. И вот такое поведение вроде как-то невилировалось в MergeTree. или это только мои фантазии?

Для реплицированных таблиц через zk работает

Скажите, что за ошибка? https://yadi.sk/i/uzwRmaJH3HJrB2

Вероятно одно (или несколько) выражений в скобках пустое, а так быть не должно

Скажите, что за ошибка? https://yadi.sk/i/uzwRmaJH3HJrB2

https://github.com/yandex/ClickHouse/blob/master/dbms/src/Parsers/ExpressionElementParsers.cpp#L87

Для реплицированных таблиц через zk работает

В доке точно есть

т.е. работает только при механизме репликации?

а для клиентских инсертов такого нет?

работает для ReplicatedMergeTree, для обычных MergeTree - нет

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

чтоб механизм сработал

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

Нет

В любой

на любую из реплик?

на любую из реплик?

Да

ок

мудрененько придется мутить конфигурацию и загрузку

Блоки данных дедуплицируются. При многократной записи одного и того же блока данных (блоков данных одинакового размера, содержащих одни и те же строчки в одном и том же порядке), блок будет записан только один раз

Ну и далее по доке

да нашел, спасибо

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

У меня есть мысли просто попробовать сделать конвертер из influxdbшного input формата в кликхаус, но пока дальше идеи не продвинулось

Его формат оч простой же

Его формат оч простой же

в общем да

Его формат оч простой же

у них есть библиотека родная для парсинга их формата, не факт что очень эффективная, но для Proof of concept сойдет

telegraf просто хорош тем что умеет брать большого количества разных источников, и понимает самые распространенные форматы (инфлюкс, графит, json). Короче я понял, пойду книженцию по go читать ))

telegraf просто хорош тем что умеет брать большого количества разных источников, и понимает самые распространенные форматы (инфлюкс, графит, json). Короче я понял, пойду книженцию по go читать ))

ну proof of concept написать - часа 4-5

и еще пару недель добиваться адекватной производительности и внешнего вида

a small matter of programming :-D

А сравнительные тесты ифлюкса против кликхауза никто не делал? Я то интуитивно догадываюсь что кликхауз инфлюкс рвёт, но хотелось бы доказательств...

рвет...... еще как рвет :)

у меня запись батчами

CH - 10% проц

InfluxDB - 270%

на том же потоке

influxDB вообще неадекватная штука, имхо. удобно когда данных мало, если много - это кошмар и неадекват.

Ок, спасибо, значит будем плавно мигрировать в сторону КХ

но у CH с визулизацией не так хорошо, пока что

драйвер для инфлакса довольно старый и отполированый, а для CH надо пока тягать из репо) но если проект для себя - ваще класс)

я сейчас тестирую кх для переезда своего проекта и возник такой вопрос - а какой подход есть для такой задачи - подсчет статистики за большой период (несколько месяцев\год)? Количество записей - несколько миллиардов, в память не помещается. Сейчас в текущем сторадже мы делаем предъагрегацию, но я так понял это не clickhouse-way?

Мы итерируемся по дням/неделям/месяцам, делая несколько запросов, и на клиенте финализируем тренд и график. Или у вас неаддитивные показатели?

Это если данные совсем большие. Еще надо обязательно порекомендовать свежий рассказ Алексея про "как избежать memory limit при groupby", на ютубе

спасибо, пошел смотреть

показатели аддитивные

а кто-нибудь для умных домов уже приделывал clickhouse?

Бггг iot+bigdata=startup ?

я сейчас тестирую кх для переезда своего проекта и возник такой вопрос - а какой подход есть для такой задачи - подсчет статистики за большой период (несколько месяцев\год)? Количество записей - несколько миллиардов, в память не помещается. Сейчас в текущем сторадже мы делаем предъагрегацию, но я так понял это не clickhouse-way?

Есть еще прием с MATERIALIZED VIEW на движке AgregatingMergeTree. Натравливаешь его на таблицу, и при поступлении сырых данных, они автоматически агрегируются так как задано в настройках VIEW. Но у такого метода есть минусы. Если вдруг нужно добавить столбец или изменить параметры агрегации то придется пересчитывать все заново. А это может быть затратно по памяти.

Есть еще прием с MATERIALIZED VIEW на движке AgregatingMergeTree. Натравливаешь его на таблицу, и при поступлении сырых данных, они автоматически агрегируются так как задано в настройках VIEW. Но у такого метода есть минусы. Если вдруг нужно добавить столбец или изменить параметры агрегации то придется пересчитывать все заново. А это может быть затратно по памяти.

спасибо, это запасной вариант. Кстати, а к примеру если мне нужно будет создать Materialzied view из другой вьюшки (которая в свою очередь может быть создана из третьей вьюшки) - сильно будет проседать скорость записи?

спасибо, это запасной вариант. Кстати, а к примеру если мне нужно будет создать Materialzied view из другой вьюшки (которая в свою очередь может быть создана из третьей вьюшки) - сильно будет проседать скорость записи?

Оно все в фоне считается при мержах. Т.е. прямого влияния на insert вроде как быть не должно.

Оно все в фоне считается при мержах. Т.е. прямого влияния на insert вроде как быть не должно.

огромное спасибо, буду тестировать

а как лучше настроить обмен данными между postgres и clickhouse?

и есть ли какие-нибудь решения по переносу данных из biqguery в clickhouse?

Очень популярный вопрос по переносу. Самый простой вариант это дамп в TSV и загрузка с клиента. Ну или кастом решения в виде потоковой загрузки напрямую, хотя не уверен что будет быстрее

по postgres - сильно зависит от вашей ситуации * тут может быть и классический ETL, где CH в качестве DWH; * а можно попробовать и на logical decoding с репликацией посмотреть (возможно с промежуточным приземлением в kafka). Типа такого https://github.com/confluentinc/bottledwater-pg

и главное не понятно, вам нужно одноразово перенести/мигрировать или нужно из OLTP БД данные подтягивать

в общем очень абстрактные постановки задачи

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

А зачем, если не секрет?

и есть ли какие-нибудь решения по переносу данных из biqguery в clickhouse?

Ребят, вот такая ошибка, это ок или все же что-то поломалось? 2017.04.25 13:29:21.203722 [ 20 ] <Error> void DB::BackgroundProcessingPool::threadFunction(): Code: 84, e.displayText() = DB::Exception: Directory /var/lib/clickhouse/data/default/data/19700101_19700131_153290_156523_9 already exists, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x1e293b6] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x106bcdf] 2. clickhouse-server(DB::MergeTreeDataMerger::mergePartsToTemporaryPart(std::vector<std::shared_ptr<DB::MergeTreeDataPart const>, std::allocator<std::shared_ptr<DB::MergeTreeDataPart const> > >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::MergeListEntry&, unsigned long, long, DB::DiskSpaceMonitor::Reservation*)+0x40b4) [0x1ff7c54] 3. clickhouse-server(DB::StorageMergeTree::merge(unsigned long, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)+0x47e) [0x1f43bbe] 4. clickhouse-server(DB::StorageMergeTree::mergeTask()+0x197) [0x1f44ba7] 5. clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x3dc) [0x1fdb85c] 6. clickhouse-server() [0x35bc8ef] 7. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7faac48ab6ba] 8. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7faac3ecc82d]

А зачем, если не секрет?

У нас тоже ожидается такая задача :) Зачем нам — вытащить сырые данные из Google Analytics Premium.

а, вам ретроспектива нужна, хит дубликатор давно уже написали?

А зачем, если не секрет?

Изначально историю браузинга собирали в bigquery (с заполнением userid), в Я.М начали передавать позже. вот теперь думаем перенести и объединить/сопоставить.

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

Интересное поведение. Если делать drop table то в processlist поле memory_usage отрицательное. Но как говорится, на скорость не влияет))

чет я затупил. есть у кого пример файлов в conf.d/ ?

там должны быть xml с той же структурой? /yandex/* ? или как?

и вот эта часть немного сбивает с толку: <remote_servers incl="clickhouse_remote_servers" /> <!-- If element has 'incl' attribute, then for it's value will be used corresponding substitution from another file. By default, path to file with substitutions is /etc/metrika.xml. It could be changed in config in 'include_from' element. Values for substitutions are specified in /yandex/name_of_substitution elements in that file. -->

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

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

в целом у incl логика такая: <yandex><b incl="c"><default/></b></yandex> + <yandex><c><custom/></c></yandex> = <yandex><b><custom/><default/></b></yandex>

извините, не могу сказать, что помогло

файлы в подкаталогке conf.d/ работают? Можно минимальный пример такого файла?

можно минимальный пример файла /etc/metrika.xml ?

когда правильней/удобней использовать подстановку, а когда conf.d/* ?

Подстановки, указанные в 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>

вот... кажется начал улавливать... но все равно как-то это все не очень очевидно в документации IMHO

вот... кажется начал улавливать... но все равно как-то это все не очень очевидно в документации IMHO

пример из боя cat /etc/clickhouse-server/config.d/graphite.xml <yandex> <use_graphite>true</use_graphite> <graphite> <host>127.0.0.1</host> <use_fqdn>true</use_fqdn> <port>42000</port> <root_path>one_min</root_path> <timeout>0.1</timeout> </graphite> </yandex>

просто кусок конфига, который будет вмерджен в /etc/clickhouse-server/config-preprocessed.xml

*Оффтоп* Вроде бы не пятница, а захотелось извращений SELECT MAX(if(Channel = 'native_cpm', Bid * 1000, Bid)) AS Maxbid, MIN(if(Channel = 'native_cpm', Bid * 1000, Bid)) AS MinBid, AVG(if(Channel = 'native_cpm', Bid * 1000, Bid)) AS avgBid FROM impressions WHERE EventDate = '2017-04-25'

И ведь что характерно - не тормозит!)

А, кстати, когда КХ по двум колонкам бежит, то как он не убивает диск по иопсам? Колонки же разного размера из-за сжатия и смещения конкретных строк внутри колонок разгын. Буферизирует одну колонку в памяти, пока не найдет в ней соответствующую строку нужную во второй колонке?