Использую ли я Azure Table Storage или SQL Azure для нашей системы чтения CQRS?
Мы собираемся внедрить часть чтения нашей системы CQRS в доме -с целью значительно улучшить нашу производительность чтения. В настоящее время наши чтения выполняются через веб-службу, которая выполняет SQL-запрос Linq -— -к нормализованным данным, включая некоторую степень десериализации из базы данных SQL Azure.
Упрощенная структура наших данных такова:
- Пользователь
- Беседа (Группировка сообщений для одних и тех же получателей)
- Сообщение
- Получатели (Набор пользователей)
Я хочу перевести это в денормализованное состояние,так что, когда пользователь запрашивает просмотр ленты сообщений, он читает ЛИБО:
Денормализованное представление, хранящееся в хранилище таблиц Azure
- . UserID как PartitionKey
- ConversationID как RowKey
- Любые изменчивые данные, которые могут быть изменены, хранятся в виде сущностей
- Сообщения, сериализованные как JSON в объекте
- Получатели указанных сообщений сериализованы как JSON в объекте
- . Основная проблема с этим ограниченный размер строки в Table Storage (960 КБ)
- Кроме того, любые запросы к столбцам «изменчивых данных» будут выполняться медленно, поскольку они не являются частью ключа
. Нормализованное представление, хранящееся в хранилище таблиц Azure
- . Другая таблица для сведений о беседе, сообщениях и получателях
- Ключи разделов для сообщений и получателей хранятся в таблице бесед.
- Бар это; это следует той же структуре, что и выше
- Обходит проблему с максимальным размером строки
- . Но снизит ли нормализованное состояние прирост производительности денормализованной таблицы?
ИЛИ
Денормализованное представление, хранящееся в SQL Azure
- . UserID и ConversationID хранятся как составной первичный ключ
- Любые изменчивые данные, склонные к изменению, хранятся в отдельных столбцах
- Сообщения, сериализованные как JSON в столбце
- Получатели указанных сообщений сериализованы как JSON в столбце
- . Наибольшая гибкость для индексации и структуры денормализованных данных
- Производительность значительно ниже, чем у запросов к хранилищу таблиц
. Я спрашиваю, есть ли у кого-нибудь опыт реализации денормализованной структуры в Table Storage или SQL Azure, что бы вы выбрали? Или есть лучший подход, который я пропустил?
Моя интуиция подсказывает, что нормализованные (хотя бы в некоторой степени )данные в Table Storage были бы правильным выбором; однако я беспокоюсь, что это снизит прирост производительности для выполнения 3 запросов, чтобы получить все данные для пользователя.