Как запускать в облаке приложения, требовательные к latency? СУБД Arenadata DB на сверхбыстрых облачных дисках

[amarao]

Я ничего не понимаю в ваших цифрах. Если вы гарантируете время ответа за 0.5мс (0.0005с), то это автоматически гарантирует не менее 2000 IOPS, т.к. если я буду запускать запросы по-очереди, каждый из них должен отработать за 500 микросекунд. А у вас в табличке число, не имееющее отношение к жизни.

Далее, я не совсем понимаю что такое "сверхбыстрые". Последний раз, когда я трогал DC-grade NVME, я получал от 200000 до 500000 IOPS fsync-записи. Коллеги подсказывают, что новые вендоры обещают (и доставляют) до 2M IOPS.

Но это были "быстрые" NVME.

Теперь вы приходите с рассказом про "сверхбыстрые NVME", и у них в поле IOPS указано число, подозрительно напоминающее производительность TLC low-end'а у меня в компьютере. Не сильно быстро, но за сто баксов больше и не потребуешь.

[supervisor]

Про табличку. 0.5 мс - это SLA, т.е. гарантированный сервис. Это не значит, что система будет отвечать с максимальной пропускной способностью. Это как раз наоборот означает, что система при самой тяжелой нагрузке на инфраструктуру облака не просядет ниже 2 kIOPS.

Теперь про небыстрые-сверхбыстрые NVME. Не думаю что корректно сравнивать NVME напрямую подключенный в bare-metal сборке с виртуалкой в облаке с NVME подключенными через кучу слоев абстракции, инфраструктура которой находится под непрерывной недетерменированной нагрузкой. Облака ценят ведь за другое :)

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

[amarao]

Эту часть я понимаю. Но у вас написано IOPS '273,4', а рядом гарантированная latency 0.5ms. Либо вы не гарантируете latency, либо вы сами не знаете, что вы пишите.

(Да, я в курсе, что для большого размера блоков не принято их считать в iops'ах, но раз уж вы написали, то, это, оправдывайтесь теперь).

[outlingo]

Во-первых, LLD — это диски с резервированием и расширенными возможностями менеджмента, а вы «трогали» сырые диски. То есть если выходит из строя диск LLD в MCS — данные остаются живы, если выходит из строя ваш сырой диск — данные отправляются в страну вечных бэкапов. Плюс возможности онлайн-миграции данных на другой диск, снапшотирование и прочие крайне нужные в облаке особенности, о которых часто забывают. Но это всё имеет свою цену.

Во-вторых, есть latency и есть IOPS. Latency на этих дисках (в «синтетике») составляет порядка 150мкс или меньше (вплоть до 100мкс). Но это не значит что они ограничены 6...10K IOPS, поскольку есть ещё и количество потоков.

В-третьих, мы делаем существенный запас по заявленным характеристикам для того, чтобы быть уверенными, что даже во время системных / аварийных работ заявленные характеристики будут соблюдены.

[amarao]

Вы реально не прочитали статью.

Смотрите, вот статья в табличке:

Low latency nvme:

Block size 1M

read iops 585,94

write iops 273,44

guarateed latency 500μs

Вот вы мне пообещали 500µs задержки на блоках в 1МБ. Я беру и фигачу их подряд. При 500µs - это 2000 блоков по 1МБ в произвольном порядке.

А у вас в вашей же табличке написано - 273 блока в секунду (IOPS). Получается, врёте с latency. Прям в одной строке два противоречивых утверждения.

И никакие LLD, резервирования и пафос эту проблему не исправят.

[outlingo]

А, это.
IOPS гарантируется не менее 273, полоса 500 это «лимит сверху».
Мы потеряли контекст при подготовке документации, спасибо что заметили.