Стратегия хранения журналов приложений в хранилище таблиц Azure

Question

Я должен определить хорошую стратегию хранения информации о регистрации в Azure Table Storage. У меня есть следующие:

PartitionKey: Наименование журнала.

RowKey: инвертированием DateTime клещей,

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

Но при этом тип выполняемых запросов всегда будет включать PartitionKey (без сканирования) И фильтр RowKey (незначительное сканирование).

Например (на естественном языке):

where `PartitionKey` = "MyApiLogs" and 
where `RowKey` is between "01-01-15 12:00" and "01-01-15 13:00" 

При условии, что запрос делается на обоих PartitionKey и RowKey, я понимаю, что размер раздела не имеет значения.

Answer 1

Взгляните на наш новый Table Design Patterns Guide - в частности, анти-образец журнала данных, поскольку он говорит об этом сценарии и альтернативах. Часто, когда люди пишут файлы журналов, они используют дату для ПК, что приводит к тому, что раздел становится горячим, так как все записи переходят в один раздел. Довольно часто Blobs становятся лучшим местом для данных журнала - поскольку люди, как правило, в конечном итоге обрабатывают журналы в партиях - руководство говорит об этом как о опции.