СХ
vladimir kolobaev
Консистентность?
😕я вам более того скажу, кх может при желании даже не записать ваши данные, после записи бывает желательно проверить, а записал ли он их(раньше так было, сейчас может и пофиксили)
Size: a a a
2019 October 31
AN
да сейчас репликации нет, надо быть готовым к этому если хотите использовать VM
ЕО
vladimir kolobaev
Тем не менее, репликация данных там есть из коробки, и в случае выхода из строя одной из нод, данные будут читаться с реплики, в полном объеме. После того как нода оживет, все данные автоматически на неё подъедут. На пользователях это никак не отразится
С VM у вас просто promxy вычитает данные из n "реплик" и вы не заметите, что на части их данных нет
AV
vladimir kolobaev
А что делать в таком случае с масштабированием нагрузки на чтение данных?
добавлять больше шардов
СХ
😅может тогда сразу в пг хранить
AV
vladimir kolobaev
@valyala Я могу к примеру: 10 экземпляров ВМ подключить к этому, одному GCP persistent disk, и направить в них 100 000 RPM? С объемом от 1 до 500 000 000(у нас сейчас такие лимиты на чтение из Графита) datapoints?
GCP persistent disk нельзя использовать с нескольких компов одновременно. Он подключается только к одному компу. Его производительность (bandwidth & iops) растет линейно с размерами этого диска. И этот диск можно динамически расширять до 257 терабайт без остановки операционной системы.
VS
GCP persistent disk нельзя использовать с нескольких компов одновременно. Он подключается только к одному компу. Его производительность (bandwidth & iops) растет линейно с размерами этого диска. И этот диск можно динамически расширять до 257 терабайт без остановки операционной системы.
Там есть особенности масштабирования по производительности (она в какой то момент выходит на плато)
VS
В смысле есть предел для persistent hdd, есть предел для persistent ssd, есть лимиты per CPU в том числе
AV
vladimir kolobaev
@valyala Я могу к примеру: 10 экземпляров ВМ подключить к этому, одному GCP persistent disk, и направить в них 100 000 RPM? С объемом от 1 до 500 000 000(у нас сейчас такие лимиты на чтение из Графита) datapoints?
100K rpm - это 1.7K rps. Такую нагрузку может выдержать и single-node victoriametrics, если приходят "легкие" запросы по небольшому количеству уникальных временных рядов за небольшой интервал времени. См. https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae .
Если же это тяжелые запросы по десяткам тысяч временных рядов с сотнями миллионов точек, то такой rps даже здоровенный кластер кликхаус не потянет :)
Если же это тяжелые запросы по десяткам тысяч временных рядов с сотнями миллионов точек, то такой rps даже здоровенный кластер кликхаус не потянет :)
AV
vladimir kolobaev
@valyala Я могу к примеру: 10 экземпляров ВМ подключить к этому, одному GCP persistent disk, и направить в них 100 000 RPM? С объемом от 1 до 500 000 000(у нас сейчас такие лимиты на чтение из Графита) datapoints?
ВМ может просканировать 500М точек за 10 секунд на одном ядре. Скорость сканирования масштабируется линейно на имеющиеся ядра, как и у кликхауса. Поэтому на 20 ядрах запрос займет полсекунды.
vk
GCP persistent disk нельзя использовать с нескольких компов одновременно. Он подключается только к одному компу. Его производительность (bandwidth & iops) растет линейно с размерами этого диска. И этот диск можно динамически расширять до 257 терабайт без остановки операционной системы.
При параллельной записи одинакового потока метрик на несколько инстансов ВМ, не вижу смысла использовать отказоустойчивый сторедж.
AN
500M -> 50M
AN
а ошибся там 10 ядер - 50m это на одно ядро
AV
vladimir kolobaev
Частичные? Только 50% триггеров начнут орать 50% пользователей?
подразумевается, что алерты должны быть настроены на прометеусах, пишущих данные в ремоут сторедж. Иначе без разницы, что за ремоут сторедж - при временном обрыве соединения между прометеем (или любым другим источником данных) и централизованным хранилищем алерты на централизованном хранилище сойдут с ума
vk
100K rpm - это 1.7K rps. Такую нагрузку может выдержать и single-node victoriametrics, если приходят "легкие" запросы по небольшому количеству уникальных временных рядов за небольшой интервал времени. См. https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae .
Если же это тяжелые запросы по десяткам тысяч временных рядов с сотнями миллионов точек, то такой rps даже здоровенный кластер кликхаус не потянет :)
Если же это тяжелые запросы по десяткам тысяч временных рядов с сотнями миллионов точек, то такой rps даже здоровенный кластер кликхаус не потянет :)
В этой стать нет КХ.
Я могу завтра снять статистику за минуту с кластера, чтобы было поняно, сколько каких запросов мы обрабатываем. Так как 20К запросов в кластер это наше нынешнее состояние
Я могу завтра снять статистику за минуту с кластера, чтобы было поняно, сколько каких запросов мы обрабатываем. Так как 20К запросов в кластер это наше нынешнее состояние
AV
vladimir kolobaev
Ребята из биллинга будут очень не довольны частичным данным
хранить данные из биллинга в решении, предназначенном для мониторинга - так себе идея :)
vk
хранить данные из биллинга в решении, предназначенном для мониторинга - так себе идея :)
Это отличная идея, для того чтобы создавать корреляции при деградациях
vk
И для того чтобы разработчикам того же биллинга было понятно как на них влияет та или иная реализованная ими функциональность
ЕО
хранить данные из биллинга в решении, предназначенном для мониторинга - так себе идея :)
+