Не фанат оракла ниразу, но btrfs - кал, извините

Не фанат оракла ниразу, но btrfs - кал, извините

Ничего не меняется с течением времени ?

с сообщениями в духе '[btrfs-transaction] stuck for 300s'

?

А, значит шард можно запечатать полностью. Ну ОК. Но все одно это какой то дремучий пиздец из прошлого века и антипаттерн. А ручное добавление северов и шардов, в 20матьего17 году?

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

Тем что это ручной пиздец

КХ это суровая система для сурового железа с выделенным админом

На другие юзкейсы она натягивается плохо

А ты его вообще уже ставил? :)

Describe ставил

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

я сейчас переливаю метрики в clickhouse на двух серверах с помощью https://github.com/bzed/whisper-to-graphite , смотрю что место в /var/lib/clickhouse/ растет вообще незаметно - как он там жмет непонятно, но очень хорошо судя по расходу )

я сейчас переливаю метрики в clickhouse на двух серверах с помощью https://github.com/bzed/whisper-to-graphite , смотрю что место в /var/lib/clickhouse/ растет вообще незаметно - как он там жмет непонятно, но очень хорошо судя по расходу )

там lz4 и zlib банальный )

если б там для value и ts можно было б задать double-delta компрессию, было б еще лучше

А подскажите, зачем используют graphite + clickhouse а не grafana + clickhouse ? Я же верно понимаю, что графит это аналог графаны?

в go-carbon использвали sparce файлы 600Гб на файловай системе по df

@SomeoneBehindYou графана - морда

графит это набор конвенций по API в том числе

формат входных и выходных данных + референсная имплементация этого (и пачка альтернативных)

@SomeoneBehindYou графана - морда

Так а зачем прослойка в виде графита?

Так а зачем прослойка в виде графита?

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

и готовый мониторинг по нему

в графите функции - грубо говоря

во вторых если не графит, то создание протокола и тулзов на тебе

в графите в морде куча математики есть уже (не всегда хорошей впрочем)

я сейчас переливаю метрики в clickhouse на двух серверах с помощью https://github.com/bzed/whisper-to-graphite , смотрю что место в /var/lib/clickhouse/ растет вообще незаметно - как он там жмет непонятно, но очень хорошо судя по расходу )

у меня свежие данные занимают 6 байт на точку, старые данные 3.5 байта на точку при этом отличие от виспера пустые точки не хранятся

@SomeoneBehindYou тут где-то упоминали что в графане например нельзя алерты делать по не core плагинам (graphite, es, prometheus, influxdb вроде бы)

именно средствами графаны

Ок, спасибо :)

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

так, шардирование (На чтение) вроде бы победил, осталось с репликацией разобраться

как думаете, какой вариант лучше: 1. carbon-c-relay -> в 3 ноды 2. carbon-c-relay -> в 3 ноды + zookeeper ( не совсем понятно как он там будет работать) 3. carbon-c-relay -> в 1 ноду -> zookeeper -> 2 ноды

как думаете, какой вариант лучше: 1. carbon-c-relay -> в 3 ноды 2. carbon-c-relay -> в 3 ноды + zookeeper ( не совсем понятно как он там будет работать) 3. carbon-c-relay -> в 1 ноду -> zookeeper -> 2 ноды

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

да я не собираюсь пока шардинг на запись делать: 1. медленнее чем в локальный 2. отсутствует избыточность (отказоустойчивость)

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

Я не склонен распространять опыт эксплуатации локалхоста на большой кластер. С КХ у меня пока опыт эксплуатации локалхоста, и в виде локалхоста он ОК. И исходя из документации я уже вижу могучий пиздец ожидающий его эксплуататоров в определенном юзкейсе, типа моего. При этом я вполне согласен что в юзкейсе Метрики он может смотрится неплохо - и именно в этом суть того что в Кассандре и Риаке кластеринг нормальный есть, а в КХ нет - ну не нужен им он был. У них команда админов есть, нового железа намотали, шардов добавили, старых запечатали - лепота. Графит там так и добавили - для своего случая, раз такая база под рукой есть. И я ни разу в случаях БД не встречался со случаем - "по документации эксплуатация пиздец, а в реале - конфетка прст". Наоборот - 1000 раз. Кассандра - в доках все ОК, в реале - ад и страдание. Риак - "супер простая система в оперировании" - в результате езда по кочкам и переезд на Кассандру. Ну его нахрен, товарищи. После этого в рассказы о супер простых базах данных не верю вообще, сорри.

@deniszh иногда задокументированный пипец лучше чем неявный :)

да я не собираюсь пока шардинг на запись делать: 1. медленнее чем в локальный 2. отсутствует избыточность (отказоустойчивость)

Почему отсуствует? можно ж шардинг с репликацией комбинировать? черезжопно конечно, но можно ж.

В самом шардинге отсутствует, мы не можем сожранять N раз одну и туже информацию на N нод, чтобы в случае падения одной из нод - информация была доступна в полном объеме.

как думаете, какой вариант лучше: 1. carbon-c-relay -> в 3 ноды 2. carbon-c-relay -> в 3 ноды + zookeeper ( не совсем понятно как он там будет работать) 3. carbon-c-relay -> в 1 ноду -> zookeeper -> 2 ноды

у меня просто carbon-c-relay в 2 ноды пишет сразу , так планировал и оставить типа зеркало

@ihard а что будет когда одна из нод отъедит?

@ihard а что будет когда одна из нод отъедит?

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

@ihard а что будет когда одна из нод отъедит?

поток метрик идет через балансер в carbon-c-relay в нем есть очередь у меня часов на 20 хватает

это для догона отваливщейся реплики

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

как думаете, какой вариант лучше: 1. carbon-c-relay -> в 3 ноды 2. carbon-c-relay -> в 3 ноды + zookeeper ( не совсем понятно как он там будет работать) 3. carbon-c-relay -> в 1 ноду -> zookeeper -> 2 ноды

Я использую вариант 2.

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

КХ умеет не читать из отстающей реплики, например

если репликация его средствами

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

они видят данные которые приходят сейчас, а все хвосты уже не видят

у меня же зеркало

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

и как потом синкать друг с другом эти зеркала - вопрос

Я использую вариант 2.

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

или даже не так - сначала прилетает значение в 1 сервер -синкаемся с 2-мя - потом прилетает значение во 2 сервер - синкаемся с 2-мя - потом в 3-ий ...

м.б. есть смысл писать в какой нить haproxy и через roundrobin Заливать на 3 сервера, если один из них отъедит то хапрокси автоматом будет писть только в 2

vladimir не надо писать дважды, юзай репликацию кликхауса. Тогда синк можно делать средствами КХ

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

пили просто в any_of сервер

ну или первый и второй как бэкап

на твой выбор

vladimir не надо писать дважды, юзай репликацию кликхауса. Тогда синк можно делать средствами КХ

средствами КХ - это zookeeper?

средствами КХ - это zookeeper?

ну оно потребует зукипер

ок, попробую так

vladimir zookeeper внешная штука, которую КХ использует для синхронизации действий

vladimir просто в КХ есть механизмы восстановления сдохшей железки

ERROR: S client not available

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

у меня сеть нагружена на 5% на графитах. это место меня совсем не беспокоит

наших сетевиков беспокоит =D

vladimir оно данные жмет, так что вы проверье )

в отличии кстати от carbon-c-relay :0

последний гоняет несжатие данные

то есть где-то трафика будет в 6-10 раз больше чем между двумя КХ серверами по его протоколу

круть

В самом шардинге отсутствует, мы не можем сожранять N раз одну и туже информацию на N нод, чтобы в случае падения одной из нод - информация была доступна в полном объеме.

В смысле? Ну можно сохранять N кусков информации на 2*N нод.

а можно ссылочку на доку - где это сказано

vladimir в случаи с репликациями все довольно просто и очевидно

у тебя есть следующие варианты: Replication Factor = m - каждую точку хэшируем m раз и пишем на m разных нод

писать m раз

реплицировать на m машин

У всех трех подходов свои особенности есть

в первом случаи - ты переживаешь гарантированно падение m-1 нод без потери данных

а потом начинаешь терять ~ 1/(m-1) данных на каждую упавшую ноду, если считать что распределение у тебя идеальное

писать m раз очень похож на "реплицировать на m машин" по характеристикам

там появляется вероятность потерять данные от падения более чем m-1 машин

что то я вот тут: https://clickhouse.yandex/docs/ru/table_engines/distributed.html про Replication Factor ничего найти не могу

что то я вот тут: https://clickhouse.yandex/docs/ru/table_engines/distributed.html про Replication Factor ничего найти не могу

оно его не умеет потому что

так

а кто умеет?

а кто умеет?

ты можешь на уровне relay'а это делать

но подумай точно ли тебе нужно

vladimir КХ умеет только схему "реплицируем на m машин"

ну вот я про это и говорил

что шардирование в КХ не поддерживает Replication Factor, об остальных вариантах я вкурсе

vladimir но как бы у тебя Replication Factor vs Репликация это trade-off количества потерянных данных в случаи отказа на уменьшение вероятности события

поэтому я вот не уверен что Replication Factor под такие данные вообще нужен

потому что железо оно не экономит

под репликации надо таблици пересоздавать - =(