Как хранить данные аудита в Azure

Question

Мы находимся на этапе проектирования для создания контрольного журнала в существующем веб-приложении. Приложение работает на Windows Azure и использует базу данных SQL Azure.

Журналы аудита должны быть отфильтрованы пользователем или по типу объекта (например, показать все действия пользователя или показать все действия, выполняемые над объектом).

Нам нужно выбрать способ хранения данных, следует ли использовать SQL Azure или использовать табличное хранилище? Мы предпочитаем хранение таблиц (дешевле).

Однако проблема с хранилищем таблиц заключается в том, как определить ключ раздела. У нас несколько тысяч клиентов (пользователей приложений) в нашей базе данных SQL, каждая из которых находится в собственном арендаторе. Использование идентификатора арендатора в качестве ключа раздела недостаточно специфично, поэтому нам нужно добавить что-то к ключу раздела. Таким образом, возникает проблема: учитывая требования к фильтрации, мы можем добавить идентификатор пользователя к ключу раздела, чтобы сделать фильтрацию пользователем простой, или мы можем добавить идентификатор объекта, чтобы упростить фильтрацию по объекту.

Итак, мы видим два возможных решения:
- использовать SQL Azure вместо хранения таблицы
- использование для хранения таблицы и использовать две таблицы с разными ключами разделов, что означает, что мы дублируем всех записей

Любые идеи, что это лучший подход к нашей ситуации? Есть ли другие, лучшие решения?

Answer 1

ДокументDB на Azure, возможно, стоит рассмотреть. https://azure.microsoft.com/en-us/documentation/articles/documentdb-use-cases/ Вы можете иметь аудита хранятся в DocDB в формате JSON документов (пользователь, активность, полей объекта и может индексировать по всем полям)

Answer 2

Azure Table Storage подходит для хранения данных журнала. Поскольку службы Azure App используют хранилище таблиц Azure для хранения журналов диагностики.

Вдумайтесь, вы можете установить PartitionKey в качестве имени владельца вашего пользователя, а RowKey - это идентификатор пользователя. В соответствии с Table Storage Data Model, нам нужно только сохранить:

Вместе PartitionKey и RowKey однозначно идентифицировать каждый объект в таблице

В качестве альтернативы, вы можете уточнить ваше беспокойство по поводу:

Использование идентификатора арендатора в качестве ключа раздела не является достаточно конкретным, поэтому нам нужно что-то добавить к ключу раздела

Кроме того, вы можете обратиться к https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#overview за дополнительной информацией о дизайне Azure Table Storage.

Любое обновление, не стесняйтесь, дайте мне знать.

Answer 3

Если вы беспокоитесь о фильтрации несколькими способами - вы всегда можете записывать одни и те же данные в несколько разделов. Он работает очень хорошо. Например, в нашем приложении у нас есть Персонал и Клиенты. Когда есть взаимодействие, которое мы хотим отслеживать/отслеживать, применяемое к ним обоим (возможно, по телефону Purchase), мы будем записывать ту же информацию (как правило, json) в наши таблицы аудита.

{ 
    PurchaseId: 9485, 
    CustomerId: 138, 
    StaffId: 509, 
    ProductId: 707958, 
    Quantity: 20 
    Price: 31.99, 
    Date: '2017-08-15 15:48:39' 
} 

И мы напишем тот же ряд следующих разделов: Product_707958, Customer_138, Staff_509. Ключ строки один и тот же в трех строках в каждом разделе: Purchase_9485. Теперь, если я хочу пойти и запросить все, что произошло для данного персонала, клиента или элемента, я просто захватил весь раздел. Хранение грязи дешево, поэтому кому это нужно, если вы напишете его в нескольких местах?

Кроме того, у вас есть идея, что у вас есть несколько арендаторов - вы можете сделать имя таблицы Tenant_[SomeId]. Есть некоторые другие проблемы, с которыми вам придется иметь дело, но это в некотором смысле еще один ключ для получения данных без схемы.