Вопрос по балансировке нагрузки Azure Table Storage

Возник вопрос «на подумать» (не связано с работой напрямую, просто разбираюсь с сервисом) по поводу ускорения Azure Table Storage через load balancing. Можно очень дёшево записывать (если очень много информации, то медленно), хранить и вычитывать (очень быстро) оттуда полностью денормализованные данные для специфичных юз-кейсов, но в случае определённой нагрузки, которая не кажется прям сильно большой, можно упереться в лимит. А лимит там 20 тычяч операций над сущностью в секунду для всего Storage Account, или 1 тысяча операций над сущностью для одного PartitionKey (scan/delete/update/insert). Есть вопросы с записью (максимум — 100 сущностей за 1 батч), но батчи можно параллелить до 10 в секунду в пределах одного PartitionKey (учитывая лимит в 1000 сущностей) или до 200 в секунду в пределах Storage Account (учитывая лимит в 20000 сущностей).

Например, если использовать этот сервис как хранилище пользовательских транзакций, то можно задать UserId как PartitionKey, а дату транзакции — как RowKey, и тогда нужные юз-кейсы (взять пачку транзакций для такого-то юзера за определённое время) будут покрыты индексами. Соответственно, PartitionKey всегда должен быть в одном Storage Account (т.е., в нашем случае все транзакции юзера должны быть в одном Storage Account). Но при большой нагрузке мы упрёмся в лимит, и облако нас затроттлит. MS предлагает создавать дополнительные Storage Account’ы, чтобы митигировать проблему, и вопрос у меня возникает по поводу, а как заранее предусмотреть эффективное распределение данных. Делать фиксированное количество юзеров на один Storage Account, и предварительно создавать новые Storage Account’ы по мере роста пользовательской базы (при желании это можно настроить динамически)?

Или есть какой-то более абстрактный способ — может, кто-то работал с Azure Table Storage под нагрузкой и понимает специфику?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

В мене в принципі виникає припущення — чи використання Azure Table для високонавантаженого читання це взагалі правильне рішення? Може має сенс мігрувати на CosmosDb?

Пытаюсь для себя решить, есть ли смысл в специфических случаях. Пока склоняюсь к тому, что есть, когда присутствует много гомогенных нереляционных данных (особенно иммутабельных), которые нужно выгребать по одному-двум критериям.

Може має сенс мігрувати на CosmosDb?

Цена вырастет в десятки, если не сотни раз — таблицы стоят копейки. По этой причине от CosmosDb стоит по возможности отказываться (если позволяет ситуация, конечно).

Та я зрозумів, що то такий cost optimization...
Якби ще критерій був один, можна було б Redis пробувати, або ж інший key-value. Та багато варіантів є...

Даже если использовать

UserId как PartitionKey,

и timestamp транзакции, с округлением до дня/недели/месяца как Id ? Чтение по Id — самое дешевое в контексте RU, плюс если поиск только по id, можно отключить все индексы, чтобы сэкономить RU на вставке.

Цена вырастет в десятки, если не сотни раз

Хм ... выглядит как-то слишком устрашающе

Берём в среднем запись — 1000 операций в секунду (1 запись — 1 сущность), чтение — 10000 операций по 30 сущностей в секунду (300000 сущностей). Хранилище — пусть будет 100 гигабайт. Для простоты будем считать, что каждая сущность — 1 килобайт, чтобы нормально пользоваться калькуляторами.

Космос: 2 региона, 17836 долларов в месяц (25 * 2 — хранилище, 17811 — RU).
Таблицы: 2 региона RA-GZRS Storage Account, 1039 долларов в месяц (13 — хранилище, 1026 — операции).

И чем больше сущностей будет задействовано в одной операции, тем выше будет взлетать цена CosmosDb (пример ещё достаточно мягкий для него — могли быть и батч записи, и больше сущностей в операции чтения).

можно отключить все индексы, чтобы сэкономить RU на вставке.

Калькуляторы Майкрософта именно так и считают по дефолту.

В одной из статей встречал определение таблиц для хай лоада как «Poor man’s Cassandra», и где-то в таком ключе я и мыслю в данном случае)).

Подписаться на комментарии