- 01 December 2016 (78 messages)
-
Кроме ликвибейза есть еще куча вариантов, практически у каждого языка есть свой фаворит. Тащить джаву на сервак php-приложений не очень хорошо. -
zk всё равно на java, мне этот аргумент кажется несколько странным -
Joined. -
Разобрался с rollup'ами - я сам накосячил в конфиге и incl не include'ил делая пустую секцию с роллапами -
но теперь другие вопросы
-
ибо я вот подождал 12 часов при той же схеме (age=0, precision=1 -> age=3600, precision=60)
-
делаю селект:
echo "select Time from graphite where Path='haggar1.agent.0.metrics.0' and Time < toUInt32(now()-3*3600) order by Time limit 5" | clickhouse-client
ожидаю увидеть уже пороллапленные значения, а получаю посекундные. Методом тыка смог найти 2-3 интервала где они поролаплены -
Ролап происходит при мерже. Мерж происходит в фоне -
И вызывается по обычным правилам
-
С optimize final можно вызвать принудительно
-
ок, поставил делаться OPTIMIZE TABLE graphite_local PARTITION 201611 FINAL
-
посмотрим что станет
-
ага. FINAL нужен для того, что бы КХ переобрабатывал уже существующие партиции
-
но его как я понимаю имеет смысл выполнять только на что-то старше месяца?
-
Зависит от настроек ролапа
-
это не эксейпинг, afair -
Если я правильно понимаю, то ReplacingMergeTree основа для GraphiteMergeTree
-
который тоже не задокументирован
-
Медленно, если использовать select final (не рекомендуется)
-
Правильно писать все запросы с расчетом на то, что данные могут быть ещё не схлопнуты
-
т.е. например argMax() по версии использовать
-
кстати, а нет способа селектить из GraphiteMergeTree сразу накладывая правила агрегации как заданы в конфиге?
-
select final, но будет медленее
-
final не работает на GraphiteMergeTree -
А как вы сами обходите то что графитные данные нужно выавнивать и пр.
-
Видимо, запрос не использует индекс
-
Что ты имеешь ввиду под выравнивать?
-
графит ожидает данные выравненные по precision
-
timestamp-timestamp%precision
-
фактически
-
равными кусками
-
черер precision промежутки
-
Joined. -
Даже если бы был final, то это не помогло бы. Запрос на большой интервал может покрыть несколько маленьких с разным precision
-
Мы сейчас эту часть допиливаем, расскажу как будет. При формирование запроса мы выбираем один presision и запросом в КХ доагрегируем до него. Presision выбирается наиболее крупный из периода куда попадает запрос. Например если у нас минутная метрика и мы хотим данные за 10 последних дней, а начиная с недели происходит угрубление до 5ти минут мы весь запрос угрубляем до 5ти минут
-
Joined. -
Т.е. схема все равно у вас хранится и в клиенте тоже? Чтобы он константу мог выбрать
-
Вот мне тоже хочется такого - хотябы прямо в виде xml. Только не очень понятно что делать, если клиента натравят на distributed или merge таблицу
-
А в чем проблема?
-
Смержить правила из разных таблиц может оказаться нетривиальным занятием. Они могут оказаться противоречивыми. Но наверно вы это все уже продумали
-
Имхо это вообще не надо делать. Правила должны быть одинаковые
-
Joined. -
вроде разжатые, но я не уверен
-
Нет, так не бывает
-
Если фильтр такой есть, должно работать
-
а count() сколько, с фильтром и без фильтра? -
значит читает с использованием фильтра, а байты китайские.
-
Joined. -
Joined. -
при большой нагрузке CPU usage 300% максимум.
как заюзать больше ядер? -
В диск упирается наверное
- 02 December 2016 (82 messages)
-
Доброе утро! Я продолжу тему - больше 300% не ест, ио по нулям - файлы на ссд. Во что может упираться? Или ему нагрузки не приходит больше?
-
max_threads можно увеличить
-
Какой движок таблицы?
-
MergedTree
-
io по нулям по данным чего?
-
Ну и что за запрос
-
top, htop
-
куча запросов в большей массе - select
-
Ну это понятно. Какой паттерн запроса
-
И io лучше по iotop, я вообще не припомню чтобы top давал in
-
Io
-
iotop тоже нули показывает, write на уровне 100-200K/s
-
Joined. -
Привет. Подскажите пожалуйста, умеет ли кликхаус делать cumulative sum? То есть допустим есть табличка со строками (1,2,3) а хочется получить (1, 3, 6). На каком-нибудь MS SQL я бы сделал джойн таблички с самой собой по t1.id >= t2.id и просуммировал. Но CH так не умеет.
-
Не умеет пока что
-
но оконные функции это не отменяет... -
Понял. Спасибо. Жаль.
-
Найдите таск на гитхабе и поставьте лайк, например
-
В принципе, в CH тоже можно посчитать cumulative sum - не очень красиво, но вроде работает
CREATE TABLE test ENGINE = Log AS SELECT arrayJoin([1, 2, 3]) as value
SELECT
value1 as value,
sum(value2) as cumsum
FROM
(SELECT
value as value1,
1 as fake
FROM test
)
ALL INNER JOIN
(SELECT
value as value2,
1 as fake
FROM test
)
USING fake
WHERE value1 >= value2
GROUP BY value1 -
Joined. -
а есть какой-нибудь способ ускорить чтение данных? Тестирую опять же на графитной нагрузке
-
делаю запрос типа:
SELECT Path, Time, Value, Timestamp FROM graphite WHERE (Path IN ({74 метрики})) AND ((Date >='2016-12-02' AND Date <= '2016-12-02' AND Time >= 1480650830 AND Time <= 1480672430)) FORMAT RowBinary -
и аналогичный в графит
-
графит отвечает за 70мс
-
кликхаус за 120
-
CREATE TABLE default.graphite ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32) ENGINE = Distributed(graphite, 'default', 'graphite_local', sipHash64(Path))
-
CREATE TABLE default.graphite_local ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup')
-
Лучше всё условие в prewere
-
дает +10мс
-
в смысле становится вместо 120 - 110
-
а это как именно?
-
можно пример?
-
хм, да, так веселее
-
да, теперь одинаково стало )
-
интересно, а можно еще лучше?
-
а почему в Time прописан Timestamp и для чего тогда date?
-
ппц кастыли
-
ну в примере запроса да
-
я за сегодня спрашивал
-
там нет разницы <= AND >=
-
или просто =
-
Timestamp это версия данных
-
Time - свойство данных
-
А date, надо думать, оно вообще не хранит -
@SLASH_CyberPunk потому что в графите нужно их уметь обновлять в прошлое, есть еще версия.
-
ибо это - метаданные
-
а Time это таймстамп который пришел вместе с чиселкой
-
я все равно не понял
-
по условию вижу, что они равнозначны, только типом данных отличаются...
-
то что дата нужна для индекса - это я понял
-
получается, если гоняешь данные со временем, то извращайся такой схемой, хотя более логично было бы что-то подобие trunc делать
-
Не для индекса. Для партиционирования
-
в данном контексте не суть важно
-
Joined. -
Привет. Подскажите как можно импортировать данные таблицу с движком MergeTree если отсутствует столбец с датой? (есть только DateTime) -
Сделать еще столбец с датой
-
Высчитать date из date time?
-
мм.... пробовал сделать поле date DEFAULT toDate(timestamp), а как тогда вставить в таблицу CSV с меньшим количеством столбцов?
-
Сделать свой ETL наверно
-
Либо лепить через временные
-
а какой в данном случае будет синтаксис? сейчас импортирую просто:
cat tes2.csv | clickhouse-client —query="INSERT INTO test FORMAT CSV"; -
понял, сейчас перечитаю внимательней, спасибо =)
-
Так если при импорте запрос, прям в запросе и сделайте колонку
-
INSERT INTO test (col,trunk(col2),col2) FORMAT
-
Или транк в кх не завезли? 😬
-
trunc это функция из oracle, с чего бы ей быть в clickhouse
-
Для этого есть toDate
-
именно то что нужно!
-
Не только оракл...
- 04 December 2016 (14 messages)
-
а имена типов а-ля String, Int (строго с большой буквы) это специально так задумано? или случайно получилось? ;) -
хорошо не Stroka -
Трололо :)
-
В коде кликхауса нет Stroka
-
./ClickHouse/doc/developers/style_ru.md: ~~Stroka~~
:-[ -
есть запрет на Строку )
- 05 December 2016 (285 messages)
-
Привет, ребят , незнаю в тему ли, но хочу спросить. Есть ли смысл оборачивать Clickhouse чем нибудь вроде Hive/Impala/Drill . Цель сделать минимизировать переделки со стороны SQL -
Есть ли какой-то опыт или объяснения почему не стоит так делать?
-
а не проще SQL переписать?
-
ну просто Clickhouse это именно что наружу полноценный SQL диалект предоставляет
-
и всякие особенности с Dcit'ами надо учитывать при разработке
-
Не предоставляет он
-
На текущий момент, у кликхаус очень слабый диалект и сильно отличается от стандарта
-
и??? вы хотите натянуть ужа на ежа и "привести к стандартному диалекту"? зачем?
IMHO затея достойная лучшего применения энергии... -
Я не хочу... 🙈
-
Специфика базы: работать в основном с одной таблицей с неадекватными джойнами. Специфика самого SQL: часть вещей не по стандарту, очень много отсутствует моментов.
-
аналитика - это чаще всего звезда. просто так случилось в мире
-
зато очень много присутсвует других моментов и положительных плюшек =) давайте признаем уже, ClickHouse очень быстрый, но ОЧЕНЬ специфический молоток и надо с помощью него решать именно те задачи под котоорые он заточен и именно теми способами которые он предоставляет из коробки
-
Я в курсе, только чтобы звезду сделать, вам здесь ответят, лейте кх в одну таблицу, а для звезды справочники подключайте на стороне
-
Пока плюс один, халява
-
да, потому что справочники работают эффективнее джойнов у товарищей. мне не сложно.
-
На данных до 1 тб я бы лично рекомендовал вертику бесплатную, шустрости не меньше, но полноценный SQL
-
ну вот смотрите, в Вертике есть projections
в каком стандарте они описаны? -
до 1 Тб можно и на mysql + 1 сервер посидеть.
-
=)) ага, а потом ценник 70k баксов за второй терабайт и блять нормальных реселлеров в россии тупо нет... плавали знаем
-
Можно и Машку за ляшку
-
Причем здесь стандарт и проекции?
-
ну я правильно понял что вы как бы говорите "ай ай вот в вертике все по стандарту, полноценный SQL" а я вот говорю что Вертика хороша, бесспорно, но в ней тоже ДОФИГА специфических вещей которыми тоже как в ClickHouse надо учиться пользоваться ;)
-
понимаете =) ClcikHouse сейчас это как nginx для аналитики, nginx вначале тоже умел с гулькин нос, реверс прокси с keep alive и хорошую раздачу статики
а теперь на нем чуть ли не полноценные приложения начали писать =) и заметье, никто не бузил по поводу "ой у них конфиг не Апачевый, а какой то свой" -
mysql тоже нужно учиться пользоваться
-
:)
-
фейсбук сидит на mysql и у них всё хорошо. это всего лишь один из инструментов.
-
да ладно, в web OLTP нагрузках с кучей мелких транзакций - MySQL себя прекрасно показал для своего времени =) и заставил тот же Pg подтянуться до нормального уровня (хотя и через костыли типа pgbouncer ;)
-
много кто сидит
-
кстати такое вот направление движения для CH рассматривали
-
отдельно - storage
-
поверх него - SQL?
-
да, я думаю ведущие специалисты по СУБД мира конечно могут ошибаться, но не десять лет подряд
-
скажем, как у того же mysql - ISAM и Inno
-
или у монги WT
-
и вообще работу в embedded режиме
-
Тот же графит ощутимо бы выиграл
-
с тех пор - с каких? они с InnoDb на RocksDb мигрировали вот в прошлом году. вместо того, чтобы выкинуть mysql и заюзать что-то более подходящее. Что как бы намекает.
-
Вы путаете стандарт диалекта
-
=)) простите, я не знаю что такое "стандарт диалекта", для меня это ортогональные понятия
-
Тогда и спор ни о чем
-
И какие у них ошибки были?
-
выбор между тормознутым на то время pg и глючным mysql?
-
Да в общем не факт что SQL дает такой значимый overhead
-
дает
-
если много запросов
-
С учетом их бюджетов им проще просто развивать выбранную субд
-
в ту сторону, куда им нужно
-
Вопрос в том насколько станет быстрее
-
вопрос в том, что SQL как API для работы с данными достаточно паршив
-
Вот это новость 😳
-
А что же удобно? 😬
-
Вобщем оргументов не увидел в этой тераде... Пока со своей стороны вижу плюсы в значительно улучшении качества языка запросов, и минусы в потере каких либо фич связанных с группировками. Собственно минусов никто не назвал
-
ну если кому-то нормально, что машина с машиной пытается общаться на пинжин-инглише каком-то, то да
-
SQL - удобный API для бухгалтеров
-
:)
-
ну, например, монговский язык запросов чем плох?
-
:)
-
обычный JSON
-
интересно, в чём костыль-то? почему, если мы ошиблись, мы тратим время на написание нового движка для стораджа, а не меняем БД полностью
-
этим и плох.
-
Тем, что он без структуры
-
это как без структуры?
-
json не читабелен человеком, куча лишних кавычек везде просто
-
а нафиг его читать человеку?
-
SQL тоже хреново читаем, когда в экран не влезает
-
:)
-
потому что разработкой занимаются люди.
-
пока ещё.
-
это еще один вариант
-
У меня на работе тоже пишут очередной Г биллинг на оракле 9, это не значит,, то все в восторге
-
если ты SQL генеришь по частям
-
был бы yml - те же яйца, только без кавычек по поводу и без, можно было бы поговорить
-
то в профайлере будет полный запрос.
-
Читаемость спорный момент, разбивать на куски запрос никто не отменял
-
в зависимости от фильтров -- у тебя тоже нечитаемая мешанина будет
-
sql = "SELECT " + ....
-
это еще прочтешь
-
ну и JSON на куски бей
-
кто мешает?
-
когда я пишу генераторы sql, они генерируют читаемый sql
-
потому что я его потом буду читать
-
Это вообще из серии разработки софта, а не работы с БД
-
отлично
-
тут соглашусь. если от пользователя БД спрятана за ГУИ и он никогда не пишет запросы, можно хоть msgpack сделать языком запросов
-
я про это и говорю
-
в отдельных случаях
-
когда запрос генерится по каким-то внешним фильтрам
-
SQL просто банально неудобен
-
удобен.
-
Ежику и кактус вкусен
-
о чем спорить
-
только разработчики потом будут вынуждены научиться читать мсгпак и всё.
-
разработчики чего?
-
монга, кстати, не заставляет BSON читать
-
Вопрос изначально был отм что нужен SQL . тк работать будут люди. они набирают пальцами SQL который знают. JSON это способ описания объекта а не запроса
-
эээ
-
SQL конвертируется в AST
-
так или иначе
-
того, кто будет прятать от юзера язык запросов. вообще, мне непонятно, почему вы считаете, что надо прятать SQL от аналитиков
-
по нему строится план
-
они обычно его знают
-
JSON точно так же конвертируется в AST
-
и по нему строится план
-
только JSON сам по себе уже дерево
-
ещё раз. был бы yml - было бы дерево
-
а так - скобочки в кавычках
-
yml - надмножество json
-
какая разница?
-
только более читабельное. я в курсе.
-
кавычек и скобок с запятыми нет.
-
я не про json говорю
-
а про то, когда ты точно знаешь, что тебе нужно, удобнее скормить в запросе само дерево
-
чем из дерева генератором делать SQL
-
юзер делает запрос руками в текстбоксе иногда
-
мы начали про графит
-
однофигственно, кмк. ладно, чат не про это - интересно продолжить, го в личку
-
юзер в графане мышкой мышит
-
ага
-
вы еще про оракловых гуру расскажите, которые по SQL план запроса по запаху определяют
-
я там запросы ручками писал. я днище, видимо :)
-
кстати для grafana никто clickhouse адаптера еще не сделал?
-
на самом деле одно другому не мешает
-
я про то, что для доступа к данным в разные моменты может быть удобным разный API
-
Адаптер это штука позволяющая брать кликхаус как датасорс
-
да, если бы был такой - выкинули бы influx нафиг
-
Ну оно четко все преобразуется в select ... Where Path in ... And Time > ...
-
ну или {"path": {"$in": [....]} .....
-
Я не думаю что если бы тут был json то было бы сильно лучше
-
Ну можно через прослойки к обычному граыиту прикрутить
-
Даже работает
-
а нужны ли они?
-
из инфлюкса графана забирает напрямую
-
Легаси нельзя раз и заменить
-
если графит есть, то да
-
я даже вот про что
-
у influx'а достаточно удобно работать с тегами
-
в плане того, что пишется -- тип метрики и соответсвующие ей теги
-
CH колоночный
-
в нем можно было попробовать теги положить в виде колонок
-
скажем загрузку интерфейсов пишем как Interface | Load | In, object=<железка>, interface=<порт>
-
Можно, я думаю маленький конвертер сделать попробовать даже под наши задачи
-
в таблице метрик сделать при этом колонки object и interface
-
тогда ряд ненужных костылей вроде interface.load.in.<object>.* уйдет
-
и семантика запроса нормальная будет
-
Я больше думаю про отдельную таблицу с текущими тэгами, без истории
-
https://github.com/lomik/carbon-clickhouse вот тут можно было бы как то парсить метрики в нормальные колонки =)GitHub - lomik/carbon-clickhouse: Graphite metrics receiver with ClickHouse as storage
Graphite metrics receiver with ClickHouse as storage - GitHub - lomik/carbon-clickhouse: Graphite metrics receiver with ClickHouse as storage
-
у influx эта таблица - самое слабое место
-
к ней постоянно lookup'ы идут
-
она в памяти должна быть
-
и пока не прососется - он просто писать не может
-
по сетевой части тегов относительно немного
-
несколько десятков от силы
-
> @BloodJazMan
https://github.com/lomik/carbon-clickhouse вот тут можно было бы как то парсить метрики в нормальные колонки =)
Есть такое желание. Только пока непонятно как это вписать в протокол графита и поддержать во всей цепочке доставки (carbon-c-relay etc)GitHub - lomik/carbon-clickhouse: Graphite metrics receiver with ClickHouse as storageGraphite metrics receiver with ClickHouse as storage - GitHub - lomik/carbon-clickhouse: Graphite metrics receiver with ClickHouse as storage
-
О! Роман! и вы тут
-
Огромное вам спасибо за go-carbon
-
вы мне прямо сильно жизнь облегчили в свое время
-
=) Ну собственно я могу issue на github открыть
мне видится это дело как набор параметризованных regexp которые просто экстрактят значение атрибута из названия метрики и все -
т..е. эти данные только в конфиге carbon-clickhouse оставиться и все можно будет пробрасывать стандартным образом
-
Оно по скорости вставки вдарит
-
используйте ORM
-
ну тогда не regexp, а wildcards
что нибудь типа такого
[attributes:diamond-cpu]
data-attibuted-table = graphite_attiributed_diamond_cpu
attibute-wildcards= "servers.{host}.cpu.{cpu_name}.{metric_name}" -
Вот все те, кто говорит, что SQL не удобен, вы кроме как с колокльни разработки кастылей и велосипедов в своем софте вообще расматриваете использование БД?
-
нет, не рассматриваем
-
для нас СУБД - элемент решения
-
в идеале - невидимый юзеру
-
ребят, может хватит про SQL?
-
вот да
-
вернемся к моему вопросу
-
в этом чатике давайте про кликхаус и все что с ним связано
-
возможно ли отделить storage отдельно?
-
по примеру WT, Inno и Rocks?
-
yandex/ClickHouse
ClickHouse is a free analytic DBMS for big data.
-
да все равно довольно дорого, т.к. проверку "парсился ли" нужно делать на каждую метрику )
-
и немного вообще странно, т.к. проще делать колонку host, колонку cpu_name и забить на совместимость с графитом
-
да, спасибо
-
да, я по это и говорю. если нет необходимости тянуть совместимость, с колонками работать гораздо удобнее
-
ну, почему??? графит как тащил через полную metric_name так и тащит... а кому захочется параметризации нормальной, надо делать адаптер для графаны и смотреть уже в графане
-
как ее сделать нормальной?
-
если у разных путей в одно и том же месте совсем разные параметры
-
где-то порт, где-то процессор
-
оно очень сложно описывается в общем случаи, да. На малых инсталяциях работать будет, на мало-мальски крупных будет все плохо с неконсистентностью именования метрик
-
ну экстрактить заданные колонки
для каждого вида путей...
через конфиг
http://metrics20.org/spec/
вот может быть сразу такой ресивер реализовать? -
Экстрактить колонки на каждую метрику это очень и очень дорого с точки зрения ресурсов. Хочется колонки - нужен другой протокол. Metircs 2.0 конечно прекрасная инициатива, но она тоже со своими минусами - например очень многословна и сложна в парсинге (точно также).
-
не дает вообще никаких, нужно брать graphite-api/graphite-web/carbonapi и использовать их
-
graphite-clickhouse реализует сабсет API который может использовать graphite-web в виде CLUSTER_SERVERS или carbonapi
-
более того, насколько я помню сейчас ты даже json данных получить не можешь
-
@rlomonosov или ты в итоге json уже реализовал?
-
да
-
ну учти что оно в статусе что-то уровня pre-alpha
-
никто не проверял
-
оно в статусе "вроде кажется работает если вгетом пнуть"
-
@lexa_work я с carbonapi его интегрировал, с ним работает /render но были какие-то проблемы с /metrics/find
-
но графана могла данные даже показать
-
Еще сейчас graphite-clickhouse по времени запроса дает такой же оверхед как чтение данных
-
Можно пооптимизировать код. Наверно
-
Выборка данных из кх - допустим 100мс. Потом оно еще 100 проведет делая доп работу
-
Вероятно это можно ускорить ощутимо
-
все сложные агрегации делаются вообще на стороне graphite-web. в graphite-clickhouse выгребаются данные и доделывается rollup (домердживает то, что КХ еще не успел). ну еще логика поиска метрик (ракрытие звездочек)
-
А агрегатные функции в условиях это вообще валидный фичреквест? Кажется, было бы удобно.
:) select job_id from rt_details where sum(reqps)=0 group by job_id;
DB::Exception: Aggregate function sum(reqps) is found in WHERE or PREWHERE in query. -
having
-
+1 к having
-
О, точняк! спс
-
затупил
-
-
-
А есть те, кто все еще для мониторинга использует православный munin?
Если есть, то возможно плагин будет полезен: https://github.com/roistat/clickhouse-muninroistat/clickhouse-muninMunin plugin for ClickHouse. Contribute to roistat/clickhouse-munin development by creating an account on GitHub.
-
ru.yandex.clickhouse.except.ClickHouseUnknownException: ClickHouse exception, code: 1002, port: 8123; Xc ��y u}n � v �QCode: 27, e.displayText() = DB::Exception: Cannot parse input: expected \t before: NULL\t1\tNULL q10.0\t1 -
Почему ругается на jdbc setNull?
-
6. SQL support.
If you are familiar with standard SQL, we can't really talk about SQL support.
NULLs are not supported. -
Так в jdbc драувере он есть
-
https://clickhouse.yandex/reference_en.html#Distinctive features of ClickHouseClickHouse Documentation | ClickHouse Documentation
ClickHouse is a fast open-source column-oriented database management system that allows generating analytical data reports in real-time using SQL queries
-
jdbc - это стандарт,я так понимаю, там нельзя было не имплементировать метод, обозначенный интерфейсом
-
Т.е. для каждого типа какие-то дефолтные пустые значения вставлять?
-
Там не имлементированные методы исключения брасают
-
А этот нет
-
Получается нужно какие-то данные додумывать при загрузке
-
А если длинное целое? 0 ?
-
возможно, мейнтейнер просто сам об этом не знал, либо ожидается сделать поддержку нуллов в будущем. в любом случае иначе никак :\
-
Null уже в этом году
-
На каждый запрос создавать prepatedstatement только с ненулевыми колонками?
-
Анализируем все значения котрые хотим вставить, отбираем те которые не содержат пустых значений и перечисляем в insert только те колонки котрые отбрали....
-
Спасибо
- 06 December 2016 (138 messages)
-
Хм, а у кликхауса есть ограничение на размер принимаеого POST запроса?
-
вопрос: из-за чего может input csv-файла производиться не целиком? csv файлы делались экспортом из mysql, предыдущие файлы втягивались нормально, а последний из 4 миллионов записей вставляет только 40 тысяч.
-
Joined. -
cat test.csv | clickhouse-client —query="INSERT INTO test(col1, col2, col...) FORMAT CSV";
-
разделителю вроде неоткуда взяться =/
-
stacktrace ничего не выдает
-
работаем через клиент командной строки
-
так вся прелесть в том, что он файл обрабатывает, выбирает из него какоето количество записей, делает их insert
-
и никаких ошибок
-
вот как раз нет, он выдает ~50к записей, а в csv их 1кк
-
есть по max query size
-
и оно влияет в том числе на то как парсится запрос отправленный по пост и выдает немного странную ошибку
-
поднял юзеру - заработало
-
ну в общем да, просто ошибка неинформативная
-
и по ней казалось словно есть лимит на вставку
-
очень большой селект, примерно на 1.6МБ
-
не, нормальный, просто автоматически сгенерированный графаной
-
SELECT Path, Value, Time, Timestamp where PATH IN ( список из 80 тысяч path'ов)
-
потому что так * раскрылась
-
Хм, интересная штука
-
мелкие запросы с PREWHERE выполняюстя в разы быстрее
-
в 2 раза где-то
-
а тяжелые наоборот, раз в 6 медленее
-
в чем причина?
-
у меня на легких запросах prewhere - 80ms, where - 200ms
-
на тяжелых prewhere - 15sec, where - 3sec
-
ну у меня это графит
-
ну у меня пока графит на пол млн метрик и примерно 50 млрд точек
-
структура поэтому простая
-
зависит от селективности условий и распределения данных по блокам. если про какие-то блоки можно быстро понять, что их читать не надо, то запрос ускоряется, если нет, то данные прочитаюся два раза. почему стало медленней в целых 5 раз - это интересно, но без деталей это вряд ли получится определить.
-
help
"ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)
Путь к таблице в ZooKeeper должен быть разным для каждой реплицируемой таблицы. В том числе, для таблиц на разных шардах, должны быть разные пути.
Что здесь значит "разным для каждой реплицируемой таблицы"? -
Joined. -
Убрал этого человека из группы.
-
А есть бот которому скармливаешь чела и если много кто пожаловался то его банят вобще в телеграме ? -
Не знаю.
-
https://github.com/lomik/graphite-clickhouse + carbonapiGitHub - lomik/graphite-clickhouse: Graphite cluster backend with ClickHouse support
Graphite cluster backend with ClickHouse support. Contribute to lomik/graphite-clickhouse development by creating an account on GitHub.
-
Через слой совместимости с графитом
-
Да
-
Нужно плагин писать под графану
-
Ну у меня задачи мониторинговые сейчас.
-
Спасибо
-
А как используется имя реплики? То есть для чего?
-
Для самоидентификации видимо. Чтоб с себя не качать
-
ну тут можно понять дошли или не дошли -
прогромировать надо просто
-
и кост модель делать
-
а какие тут кост модели щас
-
нет, ты же можешь спросить запрос про старые уже данные
-
можно добавить в синтаксис по-тупому фразу аля "at epoch 5 minutes ago"
-
или как там в вертике сделали
-
Это наверно опция distributed и кластера. оно вроде как про отставания ниче не знает. хотя может я и не прав
-
конечно, взять базу которая виндоу умеет
-
я можно вопрос разработчикам? когда ожидается виндоу?
-
как же вы ранки считаете
-
мне больше раннинг штуки нужны
-
но партишонг бай ортогонально важно
-
Joined. - 07 December 2016 (112 messages)
-
коллеги, привет. У наших админов возник вопрос - является ли хорошей практикой запускать кликхаус в докере? -
Мы не можем рекомендовать, потому что сами не используем так. Но и противопоказаний у нас тоже нет.
-
спасибо, будем пробовать.
-
хм. на форвард нельзя ткнуть, чтобы увидеть откуда
-
в общем, это в этом же канале выше. поиском можно найти по моему вопросу про докер :)
-
ага, нашел. Спасибо. А вам лично удалось запустить кликхаус в докере?
-
я тестовый запускал
-
работает
-
Базы вообще не очень хорошо ложатся на концепцию докера
-
пока нет, потому что другие задачи.
-
доставлять бинари на сервер удобнее. в плане docker image использовать.
-
Базы - stateful, а докер как концепция сделан под stateless
-
потому что к данным привязка. пока у вас контейнер без состояния, всё красиво.
-
Иначе это получается бинарные пакеты работы с которыми дает 3% оверхед минимум :)
-
на самом деле, сам запускальщик runc, не завязан ни на что. под стейтлесс сделаны оркестраторы вокруг докера
-
например, можно взять porto вместо runc.
-
Ну да, докер это тоже не только запускальщик, это вся экосистема
-
ну, людям это непонятно может быть. поэтому лучше говорить, что оркестраторы точат обычно в стейтлесс. а сам docker engine - более менее. Docker swarm - треш, никто в проде не используйте.
-
даже не пытайтесь. ни то, что до 1.12 было, ни 1.12 версию.
-
А сам документ о - непонятно зачем когда у любого дистра есть пакеты
-
пакеты обычно outdated. это верно, например, для ubuntu.
-
поставить две версии пакета обычно нельзя.
-
или я пока не знаю как. а иногда надо.
-
Весь самосбор в /opt
-
И давать префиксы
-
Все равно тебе этот софт надо откуда то брать
-
толстая нода. крутится стейдж и прод. в проде БД 2.0, не в проде БД 5.0
-
да, и вот это всё даёт мне docker image.
-
без заморочек
-
Как будто пакеты собрать сложно
-
при этом совершенно необязательно использовать оркестраторы.
-
Я без оркестраторов не вижу преимуществ докера перед пакетами
-
на ассемблере тоже не очень сложно писать. я с универа помню. в общем, это вопрос религии. Если у вас все разработчики умеют собирать нужные пакеты под нужные дистрибутивы и так, чтобы они зависимостями не подрались, то замечательно.
-
для нашей команды это утверждение неверно. учить этому бессмысленно, т.к. есть инструмент, который проще, а делает тоже самое.
-
https://www.youtube.com/watch?v=XHvh2z0B3JE&t=0s - собственно, посмотрите. В Яндексе +- тоже самое делают. Только porto вместо runc и свой оркестратор. СУБД пока не умеют эффективно, но работают над этим.
-
под базы есть volume в докере
-
Проблема в оркестрации. Например, у вас аппа без состояния. Контейнер сдох, сервер сдох - новый контейнер спокойно можно запустить на другом сервере. Надо поскейлить - запустите ещё N инстансов.
С СУБД так нельзя. Поэтому это представляет сложность. -
А зачастую всякие SAN'ы под СУБД не очень хорошо подходят
-
я бы не сказал что проще - во всех случаях ты описываешь что поставить и как собрать.
-
проще. Потому что девелопить можно на любимом макбуке.
-
для субд для надежности нужно shared storage
-
iscsi, nfs
-
а для скорости локальные ссдшки )
-
нет
-
и iscsi/nfs не надежны сами по себе
-
ну сказки не рассказывай
-
надежность тебе даст то что за ними
-
с другого конца, скажем, nutanix посадить
-
и нормально будет с базой
-
сдохнет нода - встанет на другой
-
ну и не надо заморачиваться про две версии одного пакета в системе.
-
3 петабайта, ага.
-
встанет
-
@dvolodin у каждого решения свои предположения и допущения лежат в основе.
-
а если это был мастер с асинхронной репликацией?
-
у тебя же не WAL на 3Pb
-
Если бы все было так просто как ты пишешь, то у всех бы все было одинаковым в плане как минимум физики
-
ну отлично
-
у тебя сдох сервер
-
чем отличается?
-
та же самая ситуевина
-
пытаешься запустить на другом с тем же состоянием
-
если у меня нет нутаникса, то нет, другая.
-
я как пример привел
-
что в виртуалках, что в докере -- состояние базы надо скидывать на shared storage
-
1. если репликация не синхронная, автоматом перезапускать нельзя. Потому что ты кладёшь на оркестратор бизнес-решение - ок или не ок потерять данные
-
тут не в докере дело
-
нет, про докер точно неверное утверждение.
-
для докера volume - внешнее состояние
-
да, дело в оркестраторе.
-
тогда при чем тут докер
-
:)
-
этак и ESXi может сдуру на другой хост все потянуть
-
ну, если читать всю дискуссию, то есть мнение (не моё), что докер без оркестраторов не нужен. И, в принципе, оно не то, чтобы безосновательное
-
пакетный менеджер - тоже не нужен
-
пакет - более мелкий элемент
-
вот не хочется право же с ним работать
-
иначе потом для инсталляции приходится адские playbook'и городить
-
когда своих сервисов с пару десятков, и еще чужих десяток нужен
-
и все это должно работать на основных дистрах линукса и на фре до кучи
-
docker image можно собирать из пакетов, если хочется
-
фрю в 2016 году пора бы уже закопать
-
пользователям это раскажите :) -
пакетные менеджеры пора бы закопать
-
во всем их многообразии
-
подскажите, почему count может вызывать ошибку?
SELECT COUNT(date) FROM test
Received exception from server:
Code: 42. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Passed 1 arguments to nullary aggregate function count. -
а чего? есть в чатеге те кто юзают nutanix активно?
-
ясно, спасибо
-
Joined. - 08 December 2016 (149 messages)
-
Joined. -
А скажите, есть ли в CH возможность делать массивы, например, Array(String) внутри Nested-структур? -
memory не всегда работает так же, как Log/Merge*
-
Кажется, что да. Но в моём лично кейсе вставка завершается успешно, и всё дальше хорошо, пока не пытаешься сделать select этого поля со вложенным массивом. Вот тогда сервер падает
-
Я использую CollapsingMergeTree
-
*сделать select этого поля
-
ЮХУ!
-
Только у меня он просто подвисает, а потом падает, без таких трейсов
-
Короче, инсерт успешный, а селект из этого поля рушит сервер
-
А у вас воспроизводится на не-in-memory таблице?
-
Ниши кликхауса и эластика практически не пересекаются. Это как сравнивать яблоко и чай
-
Скрин из их рекламки
-
Иллюзий про его надежность особых нет (см скрин), но мб кто интересовался продуктом.
-
@roman_kolchin я думаю посмотреть на него если кликхаус под графит будет слишком сложен.
-
но под графит
-
меня смущает в первую очередь что у них нет биндингов для бинарного протокола под какие либо языки
-
только описалово
-
и протокол сложнее чем у кликхауса
-
А насколько надежен сам КХ и стабилен по сравнению с тем же эвент кью эль?
-
ну кликхаус в продакшене в метрике яндексовой с 2013 года что ли
-
то есть тот сабсет что используется в метрике очень стабилен должен быть
-
2 с лишним миллиона метрик в секунду и 130ТБ виспер файликов без учета отказоустойчивости
-
а вы их умышленно в секунды перевели или вы правда их раз в секунду шлете?
-
это усредненно конечно
-
потому что я не представляю как посчитать отдельно по каждому ретеншену
-
возможно у кого-то есть больше, но они не признаются (есть подозрение что такого же масштаба в mail.ru и у гитхаба)
-
разной. Есть посекундные, по 10сек, по 60сек, по 5 минут, по 10, по часу, по дню
-
м... ну мы написали маленькую софтинку на Го которая файлики читает и отает по протобуфу, еще одну софтинку на Го, которая спрашивает сервера и склеивает метрики со всех серверов в один ответ и еще на Го есть переписанный graphite-api
-
когда последний раз считал 56млн уникальных названий
-
секрет в том что это примерно 45 серверов без учета репликаций
-
и под 200 с учетом (4х кратная)
-
соответственно на бэкэнд сумарно выходит 8 с лишним млн уже
-
а фишка в том что в тесте кликхаус 2.4млн в секунду на 1 сервер может переварить и упирается в сеть
-
нет конечно, на одну ноду больше 150 тысяч в секунду не бывает
-
-
через задницу
-
до недавнего времени - берем машин больше чем нужно и переносим данные скриптом на баше )
-
через неделю выключаем старый кластер
-
-
сейчас через bucky tools переносятся только новые метрики на новые сервера
-
склеивание ответов - carbonzipper наш (см презенташку вверху)
-
просто оно по пределу масштабирования наверное в 3-4 раза вырасти еще может
-
потом сдохнет
-
а кликхаус может на 1 сервер все метрики вписать
-
потому что у нас до начала этого месяца не работал cache из карбон кэша
-
то есть мы читали то что успело записаться на диск
-
диски хоть и ссд но ограничены чем-то в районе 50к иопсов на запись
-
даже если потюнить кэши и пр., все равно не очень весело
-
можно, но сложнее
-
тюнить много
-
если сервер упал - больше восстанавливать
-
у нас го-карбон только в этом месяца заменил carbon-cache :)
-
@rossmohax там проблема в том что примерно с 2013 по 2015 год никто графитом не занимался на фултайме, периодически бывали хакатоны и народ что-то подкручивал
-
в 2015 году один человек на фултайме его попиливал
-
и другой периодически советами помогал
-
а с 2016 стала полноценная команда, но изначальный автор половины кода ушел заниматься другим
-
так что оно только сейчас начало развиваться систематически, а не стихийно
-
это как шаг на будущее. Сейчас подчистили текущий технический долг
-
и можно посмотреть чем бы компактнее хранить данные, веселее делать аналитику и т.п.
-
тем более вот тут @rlomonosov запилил клевые прокси из графита в кликхаус и из кликхауса в графит
-
одну софтину которая совместима с нашим стэком и умеет спрашивать кликхаус и другую софтину которая line protocol принимает и пишет и делает это быстро
-
везде свои проблемы, вопрос в том какие и как жить
-
память конечная, сам виспер не очень оптимальный
-
надежность падает пропорционально
-
carbon-cache умрет быстро
-
go-carbon умрет позже, но тоже умрет в какой-то момент
-
на OpenTSDB столкьо писать сложно
-
у нас поверх графита есть поиск по тэгам :)
-
синтаксис только через задницу
-
virt.v1.*.dc:dc1.role:graphiteFrontend.text-match:http_2xx
-
что-нибудь в таком духе пишешь и получаешь все 200-ки от nginx'а с роли и дц
-
@lexa_work если я не ошибаюсь, у go-carbon'а парсер протокола имеет предел масштабирования в где-то 0.5М в секунду
-
то есть его надо брать и оптимизировать под такое
-
ну я его там в бранче раскочегаривал до 1.4m/s
-
собственно автор парсер переписал и он стал уметь сильно больше )
-
тока смысла в этом мало - все равно go-carbon упирается в виспер
-
и вообще натягивать кластеризацию на виспер это боль
-
оно работает на костылях и костылями погоняет
-
> @rossmohax
поидее если писать в память
В какую память? текущие версии штук под КХ не держат в памяти вообще ничего -
там даже без кеша все ок - последовательная запись в файлик
-
чтение близко к рандомному для совсем свежих данных. чем данные становятся старше, тем послевательнее становится их чтение
-
грубо говоря оно оперирует сортированными списками и периодическти мерджит несколько мелких в более крупные
-
А в паблике нет вашего graphite-api на go? -
есть, но оно на остальной наш стек завязано )
-
go-graphite/carbonapi
carbonapi - API server for github.com/go-graphite/carbonzipper
-
в принципе там основа в виде библиотеки, так что можно в теории прикрутить к чему угодно
-
Спасибо, попробуем
-
Joined. -
Joined. - 09 December 2016 (32 messages)
-
Is there any way to view a release notes? · Issue #156 · yandex/ClickHouseClickHouse is a free analytic DBMS for big data.
-
можешь поправить зависимость и рассказать нам что сломалось потом
-
эквивалент width_bucket изображается легко, произвольную сетку через multiIf тоже можно сделать, хоть и длинновато получится. встроенных функций по-моему нет, для обоих случаев.
-
выглядит как sum(f1)
-
Arthur через docker log driver
-
Configure logging drivers
Configure logging driver.
-
Joined.
- 11 December 2016 (24 messages)
-
Очепятка
-
Привет -
👌🏻
-
А уже есть слой совместимости кликхауса с графаной?
-
Насколько я понимаю - агрегация в бэкграунде есть
-
Угу, все ясно, спасибо
-
Без гоулэнга не обошлось :(
-
а ты его внезапно разлюбил? -
Угу
-
Не то чтобы совсем внезапно, но да
-
чего так?
-
Я на нем довольно долго писал за деньги
-
so, what is clickhouse bad at, in which cases it's is definitely a very bad choice?
-
Да там весь код простой довольно
- 12 December 2016 (15 messages)
-
Видео будет с митапа? -
injective означает, что функция сохраняет отличия, т.е. x!=y => f(x)!=f(y). используется для оптимзации запросов, например select f(x)... group by f(x) => select fx) ... group by x
-
Вроде да
- 13 December 2016 (46 messages)
-
как можно полечить ошибку:
"Exception on client:
Code: 209. DB::NetException: Timeout: connect timed out: "?
выдает ее даже по: SHOW TABLES -
я б начал с последних сообщений в логах сервера (с log level'ом trace)
-
ну как минимум происходит вот так:
clickhouse-client —host=my_server
ClickHouse client version 1.1.54046.
Connecting to my_server:9000.
Connected to ClickHouse server version 1.1.54080.
:) -
да у нас только 1 сервер пока)
-
по-моему 100М в данном случае это максимальный разрешенный суммарный размер длин range() по всем строкам.
-
из яндекса кто-то есть в эфире? -
до некоторой степени.
-
Есть, да.
-
Тут есть сам Алексей :) -
У яндекса же есть какая - то поддержка стартапов? https://vc.ru/n/ya-local эти говорят, что есть. Или это ложь и промоакция?
вопрос оффтоповый (и я прошу прощения за это), но ваш pr отдел видимо слишком сильно загружен. хз.«Яндекс» начал тестировать гиперлокальные приложения о районных событиях Москвы«Яндекс» запустил пилотный проект гиперлокальных приложений для жителей конкретных районов Москвы, пишет The Village. Первым экспериментальным сервисом стало приложение для iPhone «В Хамовниках». Аналогичный проект сейчас развивает правительство Москвы.
-
кто "эти"? в твоей статье ни слова об этом
-
Во-первых, действительно совсем не по теме
-
Во-вторых, в статье ничего нет про поддержку стартапов
-
Я ничего не знаю про поддержку стартапов Яндексом и ни разу такого не встречал, кроме Startup Camp
-
который закопали
-
В настройках чата - Photos and Videos
- 14 December 2016 (217 messages)
-
/stat@combot
-
=(
-
Добавьте @combot. Он статистику по сообщениям показывает)
-
Joined.
-
/stat@combot
-
интересно, что у них в качестве базы.
-
Кстати об аналитике. Тут проскакивало про поддержку clickhouse в redash. Кто-нить пробовал? Я попробовал кучу разных ревизий (после той, в которой вмерджили КХ). Везде все разломано (ошибки js, неработающий функционал и тд.). Может только у меня такие проблемы?
-
Добрый день. Вопрос по INSERT (не нашёл ответа в мануле): если идёт вставка батчем и в процессе вставки происходит сбой, что произойдёт со вставляемыми данными? Вставится часть батча или ничего не вставится?
-
ну там всего два дня назад последник комит по кликсахус в redash был =)
там автор пуллреквеста парень из Sports.ru
попробуй у него спросить что и как? -
Спасибо
-
запустил таки redash. взял последнюю стабильную версию (v0.12.0.b2449) и натянул на нее кликхаус. так работает вроде
-
redash это вроде aribnb superset или вроде metabase
-
он научился SQL делать а не только druid
-
Joined. -
Joined. -
друзья, привет!
-
намучались с ELK для логов и ивентов всяких. стоит пробовать кликхаус?
-
ага.
а с чем намучались-то? -
у нас пока немного данных и ивентов, но уже сейчас тяжело это всё мейнтейнить
-
ну, эластик плох как база
-
+ в него не вмещается много данных, приходится удалять старые индексы, либо переносить их на другие ноды, либо просто закрывать
-
хз, может мы его готовим просто плохо, но пока что от него столько боли. И так понятно, что у больших ребят для наших целей (логи + бизнес-ивенты, которые плохо кладутся в rdbms) kafka + че-нить с хадупом или кассандрой какой
-
на хайлоаде был на докладе про кликхаус, вот думаю попробовать
-
(у меня сейчас кластер yellow просто, сил нет больше)
-
а какие объемы в терабайтах и записях?
-
немного совсем, мы далеко не всё собиарем, что можем. у нас нет терабайтов)
-
записей немного, 300-400 документов в секунду
-
но нам бы хотелось больше
-
json документик с информацией: логом, ивентом
-
но мы быстро растем, примерно в 3 раза за год
-
ну как быстро, скорее, прогнозируемо :)
-
так же у нас в пейлоаде могут быть стектрейсы, например
-
кликхаус лучше себя ведет в том случае, когда этот документ имеет фиксированную типизированную структуру, которую перед заливкой распарсили и разложили в отдельные колонки.
-
мы и в ELK так льём пока.
-
он тоже так лучше переваривает всё
-
а кстати к logstash никто плагин для кликхауса не пишет?
-
да, у нас есть часть строк типизированных, согласен
-
но если эксепшен, то там лютый стектрейс может быть
-
а если их много, то ухх
-
я вот думаю, может велосипед не изобретать, а просто все ивенты аккуратно класть в mysql какой-нибудь, мы пока по нагрузке точно влезем в одну машину
-
а потом в эластик забирать и там уже копать логи
-
тут вопрос в том, использовать ли mysql или сразу тяжелой артиллерией - кассандрой какой или кликхаусом
-
это надо всю систему переписать тогда. в принципе, норм идея тоже
-
еще у меня плохо сделано то, что данные льются прямо в эластик, а он крайне плох в этом плане
-
щас обновимся на es 5.1, сделаю две ingest ноды
-
селектов много или в основном инсерты?
-
инсерты; селекты тока от людей, их немного
-
и мониторинга
-
мускуль как промежуточная стораж?
-
да. просто в эластике данные хранить очень больно
-
мы сейчас переходим со связки mysql + elasticsearch на clickhouse
идея была такая-же - первичку пишем в mysql (к elasticsearch нет доверия в качетсве первичного хранилища), там селектов не делаем, только перекладываем в elastic батчами.
а вот elastic используем только для аналитических выборок
но даже для этого с ним возникают регулярные проблемы (сейчас статус кластера - red). причем у нас тоже не очень большие объемы (50gb данных, причем оно живет на машинке с 64 гб оперативки). возможно мы его не умеем нормально готовить, но по ощущениям - очень капризный продукт -
о, обнимемся, друг!!
-
а 64гб как распределены? хип у эластика 31гб?
-
у вас дефолт или вы настраивали? для одной машины можно убрать реплика шарды
-
но вообще зависит от количества шардов на эти 50гб
-
у нас дефолт. но там хип по-моему больше, в районе 40-50, не помню точно
-
на одной машине держать его это антипаттерн, кстати. а на трёх это БОЛЬ
-
но это в общем-то неважно
пока то что clickhouse показывает на наших данных - это просто сказка. в использовании на порядок удобнее эластика (прежде всего из-за того что sql для выборок) -
хип нельзя ставить больше 31, иначе оно переходит на неправильные поинтеры : D
-
:)) ну вот может сейчас статус тоже до yellow снизим )
-
так, отлично, вот хорошо, что я к вам пришел
-
он у вас будет yellow всегда, пока реплика шарды не будут заассайнены на другие ноды
-
на 64гб памяти можно три ноды запустить по 7гб хипа каждая
-
да
-
двух же достаточно, зачем три
-
ну да, на одной тачке сплит брейна не будет
-
тоже верно
-
так-то и одной хватит на 64гб.
-
рекомендуется запускать несколько нод на машинах там с 64гб+ памяти, например, 128 - две ноды по 31гб хипа
-
просто надо перенастроить под кластер без реплик, заодно и шардов больше влезет, кстати
-
вот не хочется об этом думать ) на таких копеечных объемах данных придумывать там что-то с шардами, нодами и т.п.
-
абсолютно согласен
-
короче эластик классный поиск, но как база он ужасающ. ок, попробуем кликхаус тогда
-
причем elastic у нас на селектах нормально себя показывает, в этом смысле претензий к нему не очень много
просто неудобный в использовании и обслуживании -
как будете переливать из мускуля в кликхаус?
-
хранить там вечно? или подчищать перенесенные данные клх?
-
а кликхаус же хорош для хранения?
-
мы с этим переездом в мускуль писать перестаем
первичные данные в виде файлов собираем, их в clickhouse, а потом в s3 -
а как кхе-кхе ETL из кликхауса в s3?
-
есть че-то готовое или тулзу писать?
-
у эластика круто сделаны снапшоты, кстати. вот этого не хватает в старых базах
-
кнопку нажал, индексы улетели на s3
-
не не, не из clickhouse в s3. просто - логи в виде файлов и забекапить так чтобы если что поднять их можно было оттуда
-
запрос написал, из s3 индекс вернул
-
но там фишка в том, что в эластике нельзя данные держать, там объем ограничен
-
блин, в кликхаусе зукипер, вот это подстава
-
😃
-
не, думаю, одной машины хватит
-
если честно, хотелось бы альтернатив в виде consul и etcd
-
если уж припрет кластер делать
-
zk изящен, как седло на корове
-
^
-
вот-вот, мы для сервисов консул собираемся
-
у кого чего есть
-
просто если есть консул впихивать еще zk как-то лишне
-
ну понятно почему зк, я так понял, внутри яндекса везде zk
-
так что это если только мы с вами запилим альтернативы
-
если надо хадуп кому-то, всё равно зукипер ставить, например.
-
но мы ведь ставим кликхаус чтобы не надо было
-
а как мониторить кликхаус? есть для prometheus чо?
-
о, неплохо
-
ну если кому-то нужен zk, то можно zk
-
а если zk нет, то нафиг он
-
?
-
поидее без zk не будет работать дедупликация вставляемых данных. когда послал пачку данных, упал в процессе, послал снова
-
что CH делает с ZK?
-
key-value или что-то сложнее?
-
Joined. -
Вообще, в Яндексе не только zk. Есть и решения по-лучше но они не в оупесорсе пока.
А для своих целей zk в кликхаусе вполне норм. У вас с ним какие-то проблемы? -
так какие цели у zk?
-
консенсус в кластере же.
-
какие ещё могут быть
-
решения получше в смысле распределенные менеджеры конфигураций?
-
за 32 гб JVM начинает декомпрессить указатели, если вы этим специально не занимались, то это может наоборот ухудшить вам производительность. Точных данных, конечно, ни у кого нет, но rule of thumb за 32 не выходить
-
вы маппинги индексам делаете?
-
я там спутал(сейчас проверил). 57гб - это сколько сейчас elastic жрет памяти
cat /proc/11211/status | grep VmSize
VmSize: 56113512 kB
хип там другой: -Xmx12Gb
я повторюсь - скорее всего мы его плохо готовим. на селектах он проблем не вызывает, проблемы иногда возникают в обслуживании (бывало такое что он не поднимался после рестарта, или поднимался минут 20). я уверен что подкрутив параметры или как-то разнеся на ноды это может решиться. просто по впечатлениям которые получили - работать с ним сложно -
маппинги используем
-
короче пора elasticsearch_ru заводить
-
ну и основное что напрягает - инструменты не очень удобные (когда в коде - еще ничего, но в отладке - мучаемся). запрос писать в json - то еще развлечение
-
давай
-
Если вам просто собирать логи - попробуйте graylog, это обертка над elastic, которая сделает бОльшую часть за вас и позволит тупо скидывать логи в AMQP, особо не беспокоясь за время доставки. Я могу какие-то еще советы дать в личной беседе позже, но я на самом деле только теоретический сварщик; т.к. тут еще пара человек отписалась, возможно, имеет смысл действительно создать конфу.
-
ElasticSearch memory problems caused by mapping issues.Heap usage issues with ElasticSearch caused by mapping issues caused a cluster to crash, and how we managed to fix it.
-
@elasticsearch_ru переезжаем
-
Никто с таким не сталкивался?
-
График Cpu utilization
-
-
В CLH 6 таблиц
-
в две из них идет запись примерно 1600 запросов/сек (пиковые значения)
-
все таблицы - движок MergeTree
-
где непонятно? поясню
-
попробуем, спасибо!
-
кто знает я еще успею поговорить ? -
у нас очень много индексов по некоторым причинам
-
возможно, проблема в этом
-
"active_primary_shards" : 6051,
"active_shards" : 12042, -
Joined. -
заставили?
-
Пока добровольно.
-
-
Joined. -
Joined. -
-
Найс, спасибо
-
Joined. -
-
Analytic Database, OLAP, ColumnStore | MariaDBMariaDB ColumnStore enables real-time business intelligence and analytics. Scalable performance and costs reduction with single user interface for OLAP and OLTP.
-
А что случилось с DELETE? Его сломали?
-
его не было
-
так на highload же рассказывал, вот только там много НО было
-
вообще, до сих пор вроде видео нет, а очень бы хотелось посмотреть
-
Пока нет, по не зависящим от Кликхауса причинам. -
Эти "но" для неофитов. Они усложняют работу с КХ для людей, привыкших к полноценным RDBMS. Приходится изобретать. Но непреодолимых "но" как не было, так и нет
- 15 December 2016 (62 messages)
-
Чем вам zk не нравится то всем?
-
Всерьёз спрашиваю
-
ZK в кликхаусе много для чего. Leader election, распределённый транзакционный kv, всякие listeners
-
У нас в Метрике огромные zk и особл проблем с ними нет
-
Немного неудобно, это правда, свои проблемы есть
-
Но надежность как у гаечного ключа хорошего
-
Соглашусь, zk норм, работает. -
Витя, насколько я понял zk сложнее настроить у некоторых с этим проблемы. Просили даже показать как вы в метрике его используете, с какими опциями.
-
У нас тоже никаких проблем с ZK. Тонкости есть, скажем, cross-dc, но сам ZK работает замечательно
-
Flink сам консьюмит с кафки? У него нормально с ребалансингом и коммитами?
-
> @roman_kolchin
Александр, вы, оказывается, уже в этом чатике! А какой tool используют ваши аналитики для собственного ad hoc анализа данных в КХ? Они освоили его SQL?
У нас собственный middleware (на Scala), который генерирует SQL запросы. Его пришлось полностью переписать под КХ, чтобы заменить обычные SQL-джойны на вложенные и словари. -
Нет, больше как раз таблицы. middleware выдает клиенту json или csv (несколько форматов), который дальше используется UIем или напрямую другими системами
-
Графики тоже, конечно, можно построить, но это уже мелочи
-
Ну можно скзать, что птичий язык. Есть API, через который передаются набор измерений, метрик, фильтров и проч
-
Нет, все самописное
-
Вчера на митапе звучало предложение об MDX. Но это после нормальных джойнов
-
Это был вопрос к Яндексу. Странслировать MDX в CH-SQL (назовем это так) не должно быть слишком сложно
-
Это тоже один из вопросов, которые обсуждали :) Все просят Яндекс, сделайте то, сделайте это, но мало кто контрибьютит сам
-
Насколько я его понимаю, ему нужен клиент, под которого это можно изначально сделать, а потом отдать всем. Так как проект не самый простой, а ресурсов работать забесплатно у его компании нет.
-
Нет, нам не нужен, мы не используем MDX
-
Коллеги, привет. У нас внешние словари имеют ключи guid'ы. Можно ли как-то их подключить?
-
Пока там все кривовато и в каждой ревизии что-то может не работать. Я себе оставил коммит после мержа поддержки clickhouse на время фиксов. Полностью туда мы перейдем после появления функционала склейки запросов из разных источников. ) -
Joined. -
Есть незадокументировнный способ :) Но раскрытие незадокументированных возможностей -- это почетная обязанность Алексея
-
мы для uuid-ов воткнули две строчки, которые превращают uuid в FixedString(16) и обратно
-
но вот для primary key — эт нет
-
Спасибо! Но все-таки guid является не строкой, а отдельным типом данных (да и места меньше занимает). Планируется ли их полноценная поддержка?
-
У нас в докере работает
- 16 December 2016 (14 messages)
-
Вот это отличный вопрос кстати
-
Подскажите, а как можно посчитать median() в CollapsingMergeTree без использования модификатора FINAL ?
-
Выглядит так что действительно никак, но можно попробовать придумать
-
Joined. - 17 December 2016 (70 messages)
-
Если это тот, о ком я думаю, то драйвером дело не ограничится )
-
Это тот кто спрашивал на митапе "хочу продавать clickhouse за деньги"? =)
-
А, наоборот, он покупает
-
Да, планируется
-
И то и то
-
Пока не успеваем
-
Как с таким бороться? Только перезагрузка?
Вылетает после селекта неоч красивых данных из базы -
Сори, проблема не в кликхаусе
-
Спасио
-
КХ умеет аггрегировать вычисляемые значения по дате?
типа
GROUP BY toYear(event_date) -
Я так понимаю бинарные данные лучше в стринг не засовывать?
-
Пытаюсь сделать так
select
toYear(event_date) as y,
toMonth(event_date) as m,
count() as total
from tbl
where
user_id=29
group by toMonth(event_date)
получаю
Code: 215, e.displayText() = DB::Exception: Column event_date is not under aggregate function and not in GROUP BY., e.what() = DB::Exception -
точно. спасибо)
-
Есть ли какая то встроенная функция для экранирования бинарных данных?
-
Его и использую в веб морде приложения, но хочется посмотреть из базы данные в консоли
-
JSON/JSONCompact еще
-
Спасибо, буду думать
-
Сейчас попробую
-
Отлично, с ним хотя бы не крешиться
-
простите за невнимательность, но вот свежеобновил кликхаус, а UUIDNumToString вроде как ещё нет. Или не там смотрел?
-
SELECT UUIDNumToString(server_id),count() FROM retroview_production.sessions group by server_id FORMAT Pretty
-
Code: 46, e.displayText() = DB::Exception: Unknown function UUIDNumToString, e.what() = DB::Exception
-
1.1.54112
-
буду обновлять
-
а, но это последняя версия в репозитории. Видимо вы из исходников ставили?
-
ага
-
Наверное лучше на клиенте делать hex() и писать в базу чистую строку
-
сейчас это так:
-
replaceRegexpOne(lower(hex(server_id)),'(.{8})(.{4})(.{4})(.{4})(.{12})','\\\\1-\\\\2-\\\\3-\\\\4-\\\\5') as server_id
-
и toFixedString(unhex(replaceAll(" ++ ServerId ++ ",'-','')),16) AS server_id
-
больше добивает обожаемое мультиэкранирование
-
ага
- 18 December 2016 (7 messages)
- 19 December 2016 (95 messages)
-
Как я делал с постгресным драйвером:
sudo apt-get install -y unixodbc
sudo apt-get install -y odbcinst
sudo apt-get install -y odbc-postgresql
В /etc/odbc.ini:
[DEFAULT]
Driver = myconnection
[myconnection]
Description = PostgreSQL connection to norma
Driver = PostgreSQL Unicode
Database = norma
Servername = 10.... (твой хост)
UserName = uname
Password = pwd
Port = 5432
Protocol = 9.3
ReadOnly = No
RowVersioning = No
ShowSystemTables = No
ConnSettings =
<dictionary>
<name>table_name</name>
<source>
<odbc>
<table>postgresql_table</table>
<connection_string>DSN=myconnection</connection_string> <!— может потребоваться UID=norma;PWD=norma;, но по идее не должно —->
</odbc>
</source>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
<layout>
<flat/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>some_column</name>
<type>Int32</type>
<null_value>-1</null_value>
</attribute>
...
</structure>
</dictionary> -
Так все взлетало без проблем
-
пока нету
-
Joined. -
Joined. -
а чем вы мониторите кликхаус?
-
Всем привет! У нас на одном из серверов в логах ошибка:
-
DistributedSessions.Distributed.DirectoryMonitor: Code: 32, e.displayText() = DB::Exception: Attempt to read after eof, e.what() = DB::Exception, Stack trace:
0. clickhouse-server(StackTrace::StackTrace()+0xe) [0xfd8d0e]
1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1e) [0xf9c69e]
2. clickhouse-server(DB::throwReadAfterEOF()+0x3a) [0xf9c86a]
3. clickhouse-server(DB::StorageDistributed::DirectoryMonitor::processFile(std::string const&)+0x7c9) [0x23f4759]
4. clickhouse-server(DB::StorageDistributed::DirectoryMonitor::run()+0x15d) [0x23f501d]
5. clickhouse-server(execute_native_thread_routine+0x20) [0x32a3300]
6. /lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7ff7579c6184]
7. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ff756fe137d] -
На остальных все норм. Как нам побороть эту ошибку?
-
а для жаглера нет?:)
-
Alexey Как определить обрезанный файл?
-
А не подскажете, насколько много данных за раз можно слать POST-запросом по HTTP API ClickHouse?
-
сколько угодно
-
Раздел руководства "Производительность при вставке данных."
» Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду.
Подскажите, эти рекомендации относятся к таблице или целиком ко всему инстанцу clh? -
Такой вопрос: хочется и чтобы данные реплицировались, и чтобы при вставке одинаковых строк данные не дублировались и оставался один экземпляр. Нет ли какого-нибудь незадокументированного ReplicatedReplacingMergeTree-движка?) И можно ли такого как-нибудь достичь в принципе?
-
-
Рили лол))
Сейчас посмотрю, работает ли :D -
Работает корректно)
-
Вот ребята скромные, делают всякие крутости, но не рассказывают об этом на каждом углу)
Следующий вопрос: насколько это стабильно и как скажется на производительности? -
К сожалению, совсем не прод вариант, хотелось бы вот как ReplicatedReplacingMergeTree)
-
а зачем нужен FINAL? Вроде как и без него работает корректно
-
Да, по-моему так
-
final просит доделать все мерджи
-
Спасибо!
Мержи происходят по крону на постоянной основе, поэтому в случае, если вставка нерегулярная, нельзя просто подождать и затем делать обычные запросы, да? -
Не не, в принципе же так устроено, нет?
-
Да, я про них и говорю
-
Если они происходят только при вставке, а потом никаких склеек нет, то вариант с "подождать" в принципе должен работать нормально
-
А этот ReplacingMergeTree не мержится автоматически? Только по FINAL или OPTIMIZE?
-
А разве нельзя, как и с CollapsingMergeTree _сразу_ после вставки делать запросы, используя sign?
-
Просто не очень понятно, в чём Replacing хуже Collapsing в итоге
-
Или collapsing всегда мержится перед запросом?
-
Просто Replacing было бы очень соблазнительно использовать, если я правильно понимаю как он работает. Поскольку для Collapsing желательно использовать отдельный внешний KV storage, а в Replacing получается, что старые строки просто заменяются на новые
-
Кстати, а при any inner join выбирается последняя версия или произвольная?
-
Блин, жалко, ненадежный вариант, конечно, да... Алексей, я так понимаю, никаких производительных путей обхода кроме варианта, предложенного Игорем, с временной таблицей нет?
-
Хорошо, а если мы закладываемся, что дубли могут быть, но хочется хотя бы уменьшить занимаемое место на диске, т.е. чтобы хотя бы часть (я так понимаю это большая) схлопывалась и у нас есть 1 час на мерж (выгрузка происходит ночью), является ли такой вариант боевым или все таки не стоит?
-
Таблица большая, 60 млрд. и каждую неделю выгружается по 150-160 млн.
-
Алексей, спасибо!
-
Мои 5 коп. Если данные грузятся пакетами, а обычно так и бывает, то назначайте идентификатор пакета и проверяйте, что он уже загружен (не id отдельной записи, а id всего пакета). Накладные расходы невелики. Дополнительно можно ограничить по дате. Это подходит для больших таблиц (условно -- фактов). Для небольших, проверка уникальности id недорога, и можно на всякий случай делать иногда optimize, если загрузка может происходить с разных серверов.
-
Отлично, т.е. при фильтровать я планирую это дело все равно DISTINCT-ом для полного устранения дублей (если из-за этого не будет сильно просидать производительность), а это будет чисто в качестве очистки места.
Алексей, а репликация будет происходит корректно? Я так понимаю, будет все равно некоторое расхождение -
Спасибо, поиграюсь с разными вариантами
-
Посмотрю, как это отразится на времени выгрузки на нормальных объемах
-
Что-то меня переклинило, решил, что на оригинале и реплике слияния будут происходить независимо..
Ок, всем спасибо! -
если пачками, то и 20к и 200к - не очень много.
-
Joined. -
Joined. - 20 December 2016 (35 messages)
-
Масштабирование ClickHouse, управление миграциями и отправка запросов из PHP в кластер
В предыдущей статье мы поделились своим опытом внедрения и использования СУБД ClickHouse в компании СМИ2. В текущей статье мы затронем вопросы масштабирования, к...
-
будет не верно считать? чтобы народ отдыхал в НГ? 😁
-
я пока не готов отвечать, т.к. под мои критерии кликхаус пока не подходит, но я очень надеюсь, что когда-нибудь я смогу им пользоваться в полной мере
-
Игорь, спасибо за статью!
-
Не читал, но одобряю :)
-
Ещё не читал, позже
-
Игорь, статья хорошая и полезная, хотя тема не полностью раскрыта. В частности, по нашему опыту репликация между датацентрами требует более аккуратного подхода, особенно если пинг между датацентрами не очень хороший. Насчет PHP ничего сказать не могу кроме того, что удивляюсь его долгожительству )
-
Вообще, я бы эту статью разбил на две, но это уже поздно, наверное. Первая -- про масштабирование и конфигурация, а вторая -- про PHP утилиты
-
РНР большими буквами вроде как Ремотно Наладочные Работы ?
-
Да я без наезда, полно сайтов на PHP и людей, которые им пользуются, поэтому утилиты, наверняка, полезные.
-
На самом деле, это может быть примером того, что пользоваться СlickHouse -- это совсем не rocket science. Так что оно даже, может, и хорошо, что на php, а не на чем-нибудь более сложном
-
Хотя статья типа "ML-инфраструктура на Хаскеле и ClickHouse" смотрелась бы более внушительно :)
-
Я как-то делал доклад на тему "BigData для чайников". Очень помогает искать простые слова и аналогии :)
-
> The quote "An alleged scientific discovery has no merit unless it can be explained to a barmaid." is popularly attributed to Lord Rutherford of Nelson in as stated in Einstein, the Man and His Achievement By G. J. Whitrow, Dover Press 1973. Einstein is unlikely to have said it since his theory of relativity was very abstract and based on sophisticated mathematics.
-
:) 👍
- 21 December 2016 (24 messages)
-
Joined. -
Ребяты, привет!
Такой очень очень простой кейс: 8 тачек с таблицей в 22 млрд.
Длинный первичный ключ, т.к. ReplacingMergeTree используется для схлопывания дублей.
Запрос формата:
select col1, col2, ..., colN from table where id='214352512532';
где id - первое поле первичного ключа.
Запросы идут в распределенную таблицу, в которую заливались записи с ключом шардирования cityHash64(id).
Гранулярность индекса 8192
Вот лог на тачке без мержа (читай вспомогательной):
########################
...WHERE bar_code = '61226094020347' FORMAT JSON
2016.12.21 09:27:27.902808 [ 28 ] <Debug> merge.matreshka_merge_half_year (SelectExecutor): Key condition: (column 0 in ['61226094020347', '61226094020347'])
2016.12.21 09:27:27.902827 [ 28 ] <Debug> merge.matreshka_merge_half_year (SelectExecutor): Date condition: unknown
2016.12.21 09:27:27.903474 [ 28 ] <Debug> merge.matreshka_merge_half_year (SelectExecutor): Selected 24 parts by date, 24 parts by key, 24 marks to read from 24 ranges
2016.12.21 09:27:27.905881 [ 28 ] <Trace> merge.matreshka_merge_half_year (SelectExecutor): Reading approx. 196608 rows
2016.12.21 09:27:27.905954 [ 28 ] <Trace> InterpreterSelectQuery: FetchColumns -> WithMergeableState
2016.12.21 09:27:27.907098 [ 28 ] <Debug> executeQuery: Query pipeline:
Union
Expression × 20
Filter
MergeTreeThread
2016.12.21 09:27:30.091786 [ 2227 ] <Debug> MergeTreeReadPool: Slow read, event №1: read 52003 bytes in 2.065 sec., 0.025 MB/s.
2016.12.21 09:27:31.284043 [ 2228 ] <Debug> MergeTreeReadPool: Slow read, event №2: read 23942 bytes in 1.013 sec., 0.024 MB/s.
2016.12.21 09:27:31.284077 [ 2228 ] <Debug> MergeTreeReadPool: Will lower number of threads to 19
2016.12.21 09:27:31.852538 [ 28 ] <Trace> UnionBlockInputStream: Waiting for threads to finish
2016.12.21 09:27:31.852754 [ 28 ] <Trace> UnionBlockInputStream: Waited for threads to finish
2016.12.21 09:27:31.852869 [ 28 ] <Information> executeQuery: Read 196608 rows, 41.72 MiB in 3.951 sec., 49756 rows/sec., 10.56 MiB/sec.
2016.12.21 09:27:31.852900 [ 28 ] <Trace> UnionBlockInputStream: Waiting for threads to finish
2016.12.21 09:27:31.852909 [ 28 ] <Trace> UnionBlockInputStream: Waited for threads to finish
2016.12.21 09:27:31.853147 [ 28 ] <Debug> MemoryTracker: Peak memory usage (for query): 197.51 MiB.
2016.12.21 09:27:31.853166 [ 28 ] <Debug> MemoryTracker: Peak memory usage (for user): 197.51 MiB.
2016.12.21 09:27:31.853174 [ 28 ] <Debug> MemoryTracker: Peak memory usage (total): 197.51 MiB.
2016.12.21 09:27:31.853281 [ 28 ] <Information> TCPHandler: Processed in 3.953 sec.
########################
Вот лог на тачке с распредделенной табличкой, где мерж происходит:
########################
WHERE bar_code = '61226094020347' FORMAT JSON
2016.12.21 09:27:27.895044 [ 4876 ] <Debug> merge.matreshka_merge_half_year (SelectExecutor): Key condition: (column 0 in ['61226094020347', '61226094020347'])
2016.12.21 09:27:27.895103 [ 4876 ] <Debug> merge.matreshka_merge_half_year (SelectExecutor): Date condition: unknown
2016.12.21 09:27:27.895825 [ 4876 ] <Debug> merge.matreshka_merge_half_year (SelectExecutor): Selected 19 parts by date, 19 parts by key, 20 marks to read from 19 ranges
2016.12.21 09:27:27.897585 [ 4876 ] <Trace> merge.matreshka_merge_half_year (SelectExecutor): Reading approx. 163840 rows
2016.12.21 09:27:27.897640 [ 4876 ] <Trace> InterpreterSelectQuery: FetchColumns -> WithMergeableState
2016.12.21 09:27:27.898588 [ 4876 ] <Trace> InterpreterSelectQuery: WithMergeableState -> Complete
2016.12.21 09:27:27.899785 [ 4876 ] <Debug> executeQuery: Query pipeline:
Union
Expression
Materializing
Union
Expression × 19
Filter
MergeTreeThread
Expression × 7
Remote -
2016.12.21 09:27:31.422427 [ 28 ] <Trace> ODBCDictionarySource: SELECT code, value FROM operand_type;
2016.12.21 09:27:35.270417 [ 4876 ] <Trace> UnionBlockInputStream: Waiting for threads to finish
2016.12.21 09:27:35.270492 [ 4876 ] <Trace> UnionBlockInputStream: Waited for threads to finish
2016.12.21 09:27:35.270500 [ 4876 ] <Trace> UnionBlockInputStream: Waiting for threads to finish
2016.12.21 09:27:35.270663 [ 4876 ] <Trace> UnionBlockInputStream: Waited for threads to finish
2016.12.21 09:27:35.270721 [ 4876 ] <Information> executeQuery: Read 1624972 rows, 343.17 MiB in 7.377 sec., 220271 rows/sec., 46.52 MiB/sec.
2016.12.21 09:27:35.270742 [ 4876 ] <Trace> UnionBlockInputStream: Waiting for threads to finish
2016.12.21 09:27:35.270748 [ 4876 ] <Trace> UnionBlockInputStream: Waited for threads to finish
2016.12.21 09:27:35.270757 [ 4876 ] <Trace> UnionBlockInputStream: Waiting for threads to finish
2016.12.21 09:27:35.270763 [ 4876 ] <Trace> UnionBlockInputStream: Waited for threads to finish
2016.12.21 09:27:35.270928 [ 4876 ] <Debug> MemoryTracker: Peak memory usage (for query): 118.77 MiB.
2016.12.21 09:27:35.270940 [ 4876 ] <Debug> MemoryTracker: Peak memory usage (for user): 118.77 MiB.
2016.12.21 09:27:35.270944 [ 4876 ] <Debug> MemoryTracker: Peak memory usage (total): 118.77 MiB.
########################
По времени выполнени то в жар, то в холод. Иногда прям очень резво, а иногда 15 сек. переваривает.
Основной вопрос: что за: Slow read, event №1: read 52003 bytes in 2.065 sec., 0.025 MB/s. и как этого избежать? Что можно/нужно подкрутить? -
Добрый день, после не предвиденного отключения питания в логах clickHouse мы видим много ошибок: Considering to remove broken part "путь до партиции" because it's impossible to repair.
Можем ли мы восстановить битые патриции.
Спасибо, жду ответа. -
Joined. -
отцепить и перезалить ? -
не надо на серванте, возьмите лучше платяной шкаф
-
Оно на каких то действиях просто начнет падать с sigill
-
Тут думаю кто нибудь даже скажет на какиих
-
Амдшный ссе4а может иметь нужные инструкции
- 22 December 2016 (25 messages)
-
А зачем удалять? Храните все, удалить всегда успеете
-
Вас не смущает текст ошибки? Там не в размере батча дело.
- 23 December 2016 (31 messages)
-
Привет. Подскажите как лечить такую ошибку при вставке:
DB::Exception: Not found column lastcount in block. There are only columns: Date, TimeStamp, NormalizedUrl, NormalizedParameters, HttpStatus, ReceivedBytes, SentBytes, UpstreamTime, AuthSid, PortalUserId, TraceId, group10, group50, group100, group500, group1000, group2000, groupGt2000, stattime. -
INSERT INTO ??? FORMAT VALUES
-
INSERT INTO db.Table_2016_12_23 (Date, TimeStamp, NormalizedUrl, NormalizedParameters, HttpStatus, ReceivedBytes, SentBytes, UpstreamTime, AuthSid, PortalUserId, TraceId) FORMAT Values ('2016-12-23', '2016-12-23 05:03:08', 'someurl', '=-', 302, 1029, 566, 0.33, '', '', 'someid')
-
Есть Merge-табличка над кучей таблиц. В том числе и над этой.
-
Хотя и вьюха есть с таким столбцом. Видимо тот же баг. Спасибо.
-
Нет еще, но вроде обещали
-
Таблица с одним значением одного столбца
-
Используется в основном как заглушка синтаксиса, при селекте константы
-
-
По возможности использовать внешние словари
-
есть массивы
-
common table expressions в списке нет, печаль.
-
Крутяк - 24 December 2016 (1 messages)
-
Joined. - 26 December 2016 (7 messages)
-
Добрый день,
Скажите как ClickHouse использует директорию /opt/cores. Хотим разместить данные ClickHouse в другой директории, не в /opt.
Можно ли изменить расположение cores из конфига, или это лучше сделать ссылкой? -
в конфиге core_path
-
Joined. -
Joined. -
А используется когда clickhouse упал чтоб отложить core dump
- 27 December 2016 (37 messages)
-
Joined. -
argMax
-
если вопросов нет, то либо все понятно, либо ничего не понятно. если надо, могу более развернуто пояснить.
-
а, ок.
-
Joined. -
В корке?
-
в консоли
- 28 December 2016 (159 messages)
-
а разве бротли быстро жмет на лету? я думал он как зопфли, чтоб заранее пожатые файлики класть
-
brotli жмет быстрее всего, что мы пробовали. Включая zstd
-
(впрочем, zstd мы пробовали год назад, а brotli -- совсем недавно)
-
а снаппи там всякие не?
-
которыми монги по дефолту жмутся
-
снаппи жмет быстро, но плохо
-
В следующий раз мы надеемся сделать встречу более интересной и надеюсь участников (контрибьютеров) будет больше :)
-
Колеги, не все и всегда могут на митап явиться. Будет обидно пропускать обсуждаемую информацию. Может всё же будет общедоступным видео от таких встреч?
-
ага, показываешь паспорт, что не из ДС, и тебе дается уникальная секретная одноразовая ссылка на видео, которое уничтожается автоматом на твоем лептопе после первого просмотра... XD
-
Что за дичь?
Т.е. есть желание организации закрытого комьюнити по CH или всё же открытого?
Для популиризации платформы наверное всё же чем больше публичной информации с рассказами, обсуждениями - тем лучше, ИМХО.
Но это как уж авторы задумали.
Или тут комьюнити только на Мск рассчитано, кто всегда сможет заглянуть на встречу? Тогда хоть вебинары организуйте -
Да ладно вам. Все более менее крупные встречи будут с видео. Небольшие могут быть и без (это проще организовать). Видел с большого митапа тут было, с того что был в декабре - нет, мы как раз смотрим и думаем выкладывать ли.
-
тогда надо действительно как-то делить встречи и доступ разделить.
Через ту же Г+ группу для разработчиков иметь возможность видеть больше материалов с техническими обсуждениями, что будет недоступно просто в паблике.
Это конечно решается в первую очередь через агенду при организации встреч - кто ЦА и кому будут доступны материялы. Для каких-то материялов строго "ватермарк", что это не публичная оферта, а лишь идеи внутри комьюнити разработки и деплоя -
согласен
-
Я не думаю, что ограниченность приглашения надо связывать с ограниченностью доступа к видео. На Олимпиаду мало кого приглашают, но все смотрят. Ограничивать следует только в том случае, если была информация "не для всех". Насколько я помню, ничего секретного на митапе не было. Хотя не уверен насчет выступления товарища из Люксофта, имеет смысл у них спросить.
-
там не для разглашения может быть только название клиента
-
Но мне кажется, что сам факт видео съемки подразумевает, что видео не для служебного пользования.
-
Но решать Яндексу
-
а документация не доксигеном сгенерирована?
-
подсветка и дополнение хорошо сделаны в ipython
-
в принципе, для работы с данными можно использовать jupyter notebook
-
еще бы стоил не как самолет :)
-
у паблика вообще почти нет коннекторов, кроме веба и локальных файлов
-
только если прослойку делать
-
я написал про веб
-
Была. Более того, она со второго года просит по 400 кажется зеленых -
Personal была, и из Personal никуда не приконектишься. бесплатная это Public
-
web data connector разве умеет запросы какие-то проксировать? он же вроде тупо данные отдает
-
ну типа как csv, а все остальнео уже сама tableau делает. мне всегда казалось, что так
-
из этого примера я и сделал вывод, что все данные должны отдаться в tableau и он уже будет делать аггрегацию. я посмотрел elasticsearch-tableau-connector по скриншотам там такая же петрушка. т.е. сам запрос tablue в wdc прокинуть не может
-
Умеет, но это зависит от коннектора, разумеется. -
А с flat file, он полностью агрегирует на своей стороне, потому что у csv никаких движков в принципе нет.
-
Поэтому, зависит от источника данных ~ коннектора.
-
Если честно, то не помню.
Обычно я пользовался Custom SQL и это решало все вопросы с тем на какой стороне происходит агрегация. -
Joined. -
думал тут про tableau еще.. подумалось, что можно же еще написать fdw для постгреса, через какой-нибудь multicorn. правда как я понял multicorn пока не поддерживает aggregation pushdown, но это можно обойти с помощью созданием разных таблиц под разные запросы. зато условия в where будут работать честно и в tableau будут приезжать не все данные, а только нужные
-
mutlicorn это что бы fdw пистаь на питоне. ну по простому же
-
в постгресе ты можешь создать табличку, к который запросы будут идти через экстеншн (ну совсем по простому), multicorn это экстеншн на си, который позволяет писать экстеншены на питоне. ты описываешь какую-то табличку со всеми полями которые должны быть в результате, делаешь select field from tbl, тебе в питон обработчик приходит запрос, мол дай такие-то колонки с таким-то условием (ну после where), на основании этого ты идешь в CH, делаешь там какой угодно запрос и возвращаешь нужные колонки. group by как я понимаю в multicorn нет, но на разные колонки можно создать разные таблицы
-
я не настоящий сварщик, multicorn никогда не использовал. но у меня в голове я вижу это так, тебе в питон придет название таблицы, колонки которые спрашиваешь, и как сортировать. в зависимости от названия таблицы ты поставляешь нужны запрос с нужными колонками и нужным order by.
-
да. но сам запрос который уходит в CH уже геенрится на основании названия таблицы
-
т.е. это как вьюха получается
-
тебе придется описать каждый вариант group by разной таблицей :)
-
ну лучше чем csv :) по-моему или 10, или 9.6 постгрес умеют и join push down и всякое такое. но писать экстеншн уже надо будет на сях
-
mongodb, простите меня, делаала что-то подобное в своем коннектере для bi
-
да, personal версия там какая-то совсем не о чем если честно
-
какая-то крутая ссылка. откуда она? :)
-
Это мы показывали в рамках мастер-класса по использованию нового Logs API и ClickHouse -
Как автор notebook'a, отвечу :) Чаще всего аналитики пишут sql запросы прямо в python'e (обычно в jupyter'e) без подсказок и автокомплитов
-
А ссылка умерла 😕
-
А вот эта работает
-
Можно я тоже влезу, и дополню Машу @miptgirl? Мы в отделе в основном используем CH двумя сценариями:
1) Некоторая "тяжелая выгрузка", занимающая минуты-часы. У нас есть самописные обертки, упощающие итерирование по периодам рассчета (всё вместе в квоту не лезет). Запросы пишем вручную, вроде не слышал, вроде несильно страдаем: это потому что мало джойнов и жести, как у Маши 😊. Далее сразу в питоне в пандасе вертим-крутим как нужно.
2) А вот сценарии вида "посчитать за один день/период простую метрику", "оценить воообще кол-во событий в группе", "грепнуть и посмотреть" мы активно пользуемся CH GUI вашей (СМИ2). Очень радуемся, очень удобно)
Раньше (у меня до сих пор) для этих целей использовали clickhouse-client в tmux'е, но с гуи намного визуально понятнее, опять же вкладки, возможность глянуть в табличку.
В общем ещё раз спасибо за это! - 30 December 2016 (52 messages)
-
Joined. -
Ребят, а подскажите, если в Clickhouse нет NULL
то как их все таки лучше вставлять?
например через TabSeparated???
просто писать пустую строку?
и делать \t\t ?
а оно будет в 0 приводить для численных типов?
или все таки надо заранее знать тип и приводить к нему ? -
а можно вставлять Nested структуры в TapSeparated ?
как массивы в квадратных скобках? -
ну и там вроде как должна быть одинаковая длинна? так?
-
Да
-
В смысле количества элементов
-
я не из сырцов ставлю
и я думаю что старое поведение никто ломать не будет =) -
ну у меня golang ;)
там NULL нет нормального
там только nil ;) -
ну сочетание golang и TabSeparated, не дает мне шанса вставить NULL в том виде как оно обычно в SQL используется
-
\tNULL\t
это ж строка будет для String в таком случае для TabSeparated
в общем я таки попробую пустые строки посмотрю что получится -
ну дак это отдельно экранировать придется =)
-
еще раз
если \t разделитель
и я для типа String
поставлю NULL
Null или еще как то
то это не должно интерпрититорваться как NULL
это должна быть строка
если нет, то это значит сломали все =) -
МНЕ НЕ НАДО ВСТАВИТЬ \t как строку =)
-
ок \N, понял
может быть можно будет попровать ... - 31 December 2016 (32 messages)
-
C наступающим всех =)
пусть в новом году ClickHouse обгонит и перегонит все Collumn Oriented databases и станет номер 1 =) по популярности -
-
=) а кто живой? а если я хочу String вставить в TabSeparated и Nested, мне надо [Строка1, Строка2, Скрока3] делать? или надо еще внутри массива строки кавычками экранировать?
-
у меня массив из строк
к сожалению =) -
https://clickhouse.yandex/reference_ru.html#Nested(Name1 Type1, Name2 Type2, ...)
вот тут я чтото не вижу примервов на вставку и на кавычки =(Документация ClickHouse | Документация ClickHouseClickHouse is a fast open-source column-oriented database management system that allows generating analytical data reports in real-time using SQL queries
-
ну я так и собираюсь сделать
-
но просто хочу уточнить вдруг кто уже прошел этот путь
-
неа =) надо экспериментировать сейчас будет
-
ну вроде разобрался
http://take.ms/pbeOLScreenshot "C__Windows_system32_cmd.exe 2016-12-31 14.51.49.png"Monosnap — the best tool to take & share your screenshots..
-
-
И Q5! -
Квартал!
@clickhouse_ru / Public archive of Telegram messages.
- 01 Dec 2016 (78)
- 02 Dec 2016 (82)
- 04 Dec 2016 (14)
- 05 Dec 2016 (285)
- 06 Dec 2016 (138)
- 07 Dec 2016 (112)
- 08 Dec 2016 (149)
- 09 Dec 2016 (32)
- 11 Dec 2016 (24)
- 12 Dec 2016 (15)
- 13 Dec 2016 (46)
- 14 Dec 2016 (217)
- 15 Dec 2016 (62)
- 16 Dec 2016 (14)
- 17 Dec 2016 (70)
- 18 Dec 2016 (7)
- 19 Dec 2016 (95)
- 20 Dec 2016 (35)
- 21 Dec 2016 (24)
- 22 Dec 2016 (25)
- 23 Dec 2016 (31)
- 24 Dec 2016 (1)
- 26 Dec 2016 (7)
- 27 Dec 2016 (37)
- 28 Dec 2016 (159)
- 30 Dec 2016 (52)
- 31 Dec 2016 (32)