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

Мы стараемся следовать указаниям, приведенным в документеРазработка масштабируемой стратегии разбиения для хранилища таблиц Azure, Поскольку мы делаем большое количество вставок в эту таблицу (и, надеюсь, увеличиваем их по мере масштабирования), мы должны убедиться, что мы не превысим наши пределы, что приведет к потере журналов. Мы структурировали наш дизайн следующим образом:

У нас есть учетная запись хранения Azure для каждой среды (DEV, TEST, PROD).

У нас есть таблица для каждого продукта.

Мы используем TicksReversed + GUID для ключа строки, чтобы мы могли запрашивать блоки результатов между определенными периодами с высокой производительностью.

Первоначально мы решили разделить таблицу с помощью Logger, которые для нас были широкими областями продукта, такими как API, приложения, производительность и кэширование. Однако из-за малого количества разделов мы были обеспокоены тем, что это привело к так называемым «горячим» разделам, когда много операций вставки выполнялись на одном разделе в течение определенного периода времени. Поэтому мы изменили раздел на Context (для нас это имя класса или ресурс API).

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

Некоторые идеи у нас были

использовать блоки времени (скажем, 1 час) для ключей разделов, чтобы упорядочить их по времени (в результате горячие разделы на 1 час)

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

Поскольку это такое распространенное применение хранилища таблиц Azure, должна быть какая-то стандартная процедура.Как лучше распределять таблицы Azure, используемые для хранения журналов?

Ограничения решения

Используйте дешевое хранилище Azure (Table Storage кажется очевидным выбором)

Быстрая масштабируемая запись

Низкая вероятность потери журналов (т. Е. Превышение скорости записи разделов в 2000 объектов в секунду в хранилище таблиц Azure).

Чтение упорядочено по дате, самое последнее сначала.

Если возможно, разделить на что-то, что было бы полезно для запроса (например, область продукта).