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

когда последний раз считал 56млн уникальных названий

солидно

но не на 2М в секунду :)

секрет в том что это примерно 45 серверов без учета репликаций

и под 200 с учетом (4х кратная)

ух...

соответственно на бэкэнд сумарно выходит 8 с лишним млн уже

чтож такое вы там мониторите...

а фишка в том что в тесте кликхаус 2.4млн в секунду на 1 сервер может переварить и упирается в сеть

соответственно на бэкэнд сумарно выходит 8 с лишним млн уже

на одну графит ноду 8 миллионов?

на одну графит ноду 8 миллионов?

нет конечно, на одну ноду больше 150 тысяч в секунду не бывает

http://events.linuxfoundation.org/sites/events/files/slides/booking-graphite-atscale-linuxconeur2k16.pdf

а вот это все как аркиструется при горизонтальном масштабировании?

а вот это все как аркиструется при горизонтальном масштабировании?

через задницу

крутая у вас задница

видать железобетонная

до недавнего времени - берем машин больше чем нужно и переносим данные скриптом на баше )

через неделю выключаем старый кластер

в общем я под впечатлением...

сейчас через bucky tools переносятся только новые метрики на новые сервера

склеивание ответов - carbonzipper наш (см презенташку вверху)

просто оно по пределу масштабирования наверное в 3-4 раза вырасти еще может

потом сдохнет

нет конечно, на одну ноду больше 150 тысяч в секунду не бывает

почему? размер блока в фс сделать 512 байт, взвинтить vm.dirty_expire_centisecs на значения в десятки минут и вуаля - по 1кб памяти на метрику расходуется

а кликхаус может на 1 сервер все метрики вписать

почему? размер блока в фс сделать 512 байт, взвинтить vm.dirty_expire_centisecs на значения в десятки минут и вуаля - по 1кб памяти на метрику расходуется

потому что у нас до начала этого месяца не работал cache из карбон кэша

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

диски хоть и ссд но ограничены чем-то в районе 50к иопсов на запись

даже если потюнить кэши и пр., все равно не очень весело

читать из пейджкэша тоже ж можно

можно, но сложнее

тюнить много

если сервер упал - больше восстанавливать

go-carbon вот прям сейчас на убогий raid5 пишут 2М/минуту на ноду с тюнингом описаным выше и нагрузки ноль, одно ядро занято чуток

go-carbon вот прям сейчас на убогий raid5 пишут 2М/минуту на ноду с тюнингом описаным выше и нагрузки ноль, одно ядро занято чуток

у нас го-карбон только в этом месяца заменил carbon-cache :)

@rossmohax там проблема в том что примерно с 2013 по 2015 год никто графитом не занимался на фултайме, периодически бывали хакатоны и народ что-то подкручивал

в 2015 году один человек на фултайме его попиливал

и другой периодически советами помогал

а с 2016 стала полноценная команда, но изначальный автор половины кода ушел заниматься другим

ну заводить КХ под это дело радикальный вариант :)

так что оно только сейчас начало развиваться систематически, а не стихийно

ну заводить КХ под это дело радикальный вариант :)

это как шаг на будущее. Сейчас подчистили текущий технический долг

но интересный, опишите потом опыт :)

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

тем более вот тут @rlomonosov запилил клевые прокси из графита в кликхаус и из кликхауса в графит

одну софтину которая совместима с нашим стэком и умеет спрашивать кликхаус и другую софтину которая line protocol принимает и пишет и делает это быстро

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

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

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

везде свои проблемы, вопрос в том какие и как жить

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

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

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

carbon-cache умрет быстро

go-carbon умрет позже, но тоже умрет в какой-то момент

если честно, мне подход к организации метрик в стиле graphite после openTSDB и Ko, как-то не очень приживается

нее, я про go-carbon конечно. нет не умрет, у него в памяти ничего висеть не будет

если честно, мне подход к организации метрик в стиле graphite после openTSDB и Ko, как-то не очень приживается

на OpenTSDB столкьо писать сложно

я вот думаю, что более прогрессивно было бы попробовать на CH что-то более нативное сделать

я не про сам openTSDB

расход памятьи- 1кб/метрику независимо от количества обновлений

я не про сам 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 поидее если писать в память В какую память? текущие версии штук под КХ не держат в памяти вообще ничего

> @rossmohax поидее если писать в память В какую память? текущие версии штук под КХ не держат в памяти вообще ничего

в page cache, оно почти бесплатно получается

там даже без кеша все ок - последовательная запись в файлик

я КХ не смотрел, но если запись последовательная, значит чтение рандомное :) хотя учитывая что пишут сильно больше чем читают, то может оно и к лучшему

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

оно как в leveldb их перепаковывает по ключу?

А скажите, есть ли в CH возможность делать массивы, например, Array(String) внутри Nested-структур?

Создавать массивы в nested-структурах нельзя. То, что CH позволяет их создавать - бага. https://github.com/yandex/ClickHouse/issues/193 и https://github.com/yandex/ClickHouse/issues/234 (вероятно, что вторая ваша и есть)

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

м... ну мы написали маленькую софтинку на Го которая файлики читает и отает по протобуфу, еще одну софтинку на Го, которая спрашивает сервера и склеивает метрики со всех серверов в один ответ и еще на Го есть переписанный graphite-api

А в паблике нет вашего graphite-api на go?

А в паблике нет вашего graphite-api на go?

есть, но оно на остальной наш стек завязано )

https://github.com/dgryski/carbonapi

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

Спасибо, попробуем

Решили сделать митап для тех, кто участвует в разработке ClickHouse или открытых проектов, которые с ним работают: https://events.yandex.ru/events/meetings/14-dec-2016/

Небольшой оффтопик не про КХ, но про историю инструментов BI -- научная статья, описывающая подход к анализу данных и прототип софтины, на базе который была разработана Tableau: http://graphics.stanford.edu/papers/polaris/polaris.pdf

Небольшой оффтопик не про КХ, но про историю инструментов BI -- научная статья, описывающая подход к анализу данных и прототип софтины, на базе который была разработана Tableau: http://graphics.stanford.edu/papers/polaris/polaris.pdf

?

А где-то публикуется changelog между версиями?

вроде нет, список коммитов на гитхабе разве что

https://github.com/yandex/ClickHouse/issues/156

а как-нибудь можно поставить Кликхаус на Убунту 16.04 при выполнении sudo apt-get install clickhouse-server-base у меня ошибка clickhouse-server-base : Depends: libc6 (< 2.20) but 2.23-0ubuntu5 is to be installed E: Unable to correct problems, you have held broken packages.