AV
В смысле есть предел для persistent hdd, есть предел для persistent ssd, есть лимиты per CPU в том числе
Aга :) Но там лимиты получше, чем у обычных HDD - 3K read rps / 15K write rps, 240MB/s read/write bandwidth.
Size: a a a
2019 October 31
VS
Aга :) Но там лимиты получше, чем у обычных HDD - 3K read rps / 15K write rps, 240MB/s read/write bandwidth.
Ну это да
VS
Прото надо всегда читать что и как масштабируется
vk
Т.е. я искренне рад, что вы помещаетесь в КХ, но вы его явно переоцениваете
Яндекс метрика помещается в КХ и живёт в 15 ДЦ. Думаю нам даже такого запаса на долго хватит
RL
В кх только асинхронная репликация без всяких кворумов на запись. Поэтому он в общем eventually consistent. Это не плохо, но это надо учитывать при разработке вокруг него
ЕО
vladimir kolobaev
Яндекс метрика помещается в КХ и живёт в 15 ДЦ. Думаю нам даже такого запаса на долго хватит
Яндекс-метрика не ДВХ
VS
О, новое что то. Тогда да, лучше стало
AS
Яндекс-метрика не ДВХ
Графитовский сторадж двх?
ЕО
Графитовский сторадж двх?
Я тут просто пытаюсь убедить человека в том, что рано или поздно ему потребуется map-reduce
AS
Я тут просто пытаюсь убедить человека в том, что рано или поздно ему потребуется map-reduce
В метриках?
ЕО
В метриках?
В бизнес-аналитике
ЕО
Он юзает КХ потому что это решение, которое относительно неплохо работает с бизнес-аналитикой и метриками одновременно
VS
В бизнес-аналитике
Не факт, вопрос в запросах
AV
vladimir kolobaev
При параллельной записи одинакового потока метрик на несколько инстансов ВМ, не вижу смысла использовать отказоустойчивый сторедж.
смысл в том, что каждый инстанс ВМ может находиться в своей availability zone (aka datacenter). При недоступности одного из ДЦ данные продолжат записываться и считываться с живого ДЦ.
vk
смысл в том, что каждый инстанс ВМ может находиться в своей availability zone (aka datacenter). При недоступности одного из ДЦ данные продолжат записываться и считываться с живого ДЦ.
Так, КХ точно так же у нас и работает
AV
vladimir kolobaev
В этой стать нет КХ.
Я могу завтра снять статистику за минуту с кластера, чтобы было поняно, сколько каких запросов мы обрабатываем. Так как 20К запросов в кластер это наше нынешнее состояние
Я могу завтра снять статистику за минуту с кластера, чтобы было поняно, сколько каких запросов мы обрабатываем. Так как 20К запросов в кластер это наше нынешнее состояние
Было бы здорово посмотреть такую статистику. А у вас тэги сейчас не используются?
vk
И при этом ещё и репликация работает между ДЦ.
vk
Было бы здорово посмотреть такую статистику. А у вас тэги сейчас не используются?
Да, конечно используются, данные из прома пишутся в формате тегов графита
AV
vladimir kolobaev
При недоступности КХ, приложение которое в него пишет, начинает писать данные на винт, и после восстановления пишет их в КХ.
Бекапы спасают от ошибки пользователя.
Бекапы спасают от ошибки пользователя.
а если винта не хватит? Например, неправильно обновили КХ -> все данные потерялись -> восстанавливаемся из бэкапа в течение суток (если в КХ были сотни ТБ данных) -> в течение суток КХ недоступен -> место на локальных дисках приложений, пищущих в КХ закончилось. Что дальше?
vk
а если винта не хватит? Например, неправильно обновили КХ -> все данные потерялись -> восстанавливаемся из бэкапа в течение суток (если в КХ были сотни ТБ данных) -> в течение суток КХ недоступен -> место на локальных дисках приложений, пищущих в КХ закончилось. Что дальше?
Сперва мы будем 10 минут думать. Потом напишем в общий чат что у нас всё сломалось и мы чиним. Мойру трогать не будем так как она работает независимо от Графита. Потом мы запросим пару тройку серверов из резерва и через паппит раскатим новый кластер, минут за 10. Завернем всю запись данных в новый кластер. Восстановим старый. Включим параллельную запись сразу в оба. Начнем переливать данные из нового в старый. Переключим читающую нагрузку на старый. Отпишимся в чат. Вернем сервера. Пойдём курить.