Я использую Azure Table Storage или SQL Azure для нашей системы чтения CQRS?

Мы собираемся внедрить часть Read нашей системы CQRS, цель которой состоит в том, чтобы значительно улучшить производительность чтения. В настоящее время наши чтения проводятся через веб-службу, которая запускает запрос Linq-to-SQL по отношению к нормализованным данным, включая некоторую степень десериализации из базы данных SQL Azure.

Упрощенная структура наших данных:

  • Пользователь
  • Разговор (группировка сообщений для тех же получателей)
  • Сообщение
  • Получатели (набор пользователей)

Я хочу переместить это в денормализованное состояние, так что, когда пользователь запрашивает фид сообщений, он читает от EITHER:

Денормализованное представление, хранящееся в хранилище таблиц Azure

  • UserID как PartitionKey
  • ConversationID как RowKey
  • Любые изменчивые данные, подверженные изменениям, хранятся как сущности
  • Сообщения, сериализованные как JSON в сущности
  • Получатели сообщений, сериализованные как JSON в сущности
  • Основная проблема заключается в том, что ограниченный размер строки в хранилище таблиц (960 КБ)
  • Также любые запросы в столбцах "volatile data" будут медленными, поскольку они не являются частью ключа

Нормализованное представление, хранящееся в хранилище таблиц Azure

  • Разная таблица для деталей беседы, сообщений и получателей.
  • Клавиши разделов для сообщений и получателей, хранящихся в таблице бесед.
  • Бар, который; это следует той же структуре, что и выше.
  • Получает максимальную проблему с размером строки
  • Но нормализованное состояние уменьшит прирост производительности денормализованной таблицы?

ИЛИ

Денормализованное представление, содержащееся в SQL Azure

  • UserID и ConversationID, хранящиеся как составной первичный ключ
  • Любые изменчивые данные, подверженные изменениям, хранятся в отдельных столбцах
  • Сообщения, сериализованные как JSON в столбце
  • Получатели сообщений, сериализованные как JSON в столбце
  • Наибольшая гибкость для индексирования и структура денормализованных данных
  • Значительно медленнее, чем запросы хранилища таблиц.

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

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

Ответы

Ответ 1

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

Вот некоторые причины моего скептицизма в претензии:

  • SQL Azure использует собственный/эффективный протокол TDS для возврата данных; Таблицы Azure используют формат JSON, который является более подробным.
  • Соединения/фильтры в SQL Azure будут очень быстрыми, если вы используете первичные ключи или имеете индексы в SQL Azure; Таблицы Azure не имеют индексов, и соединения должны выполняться на стороне клиента.
  • Ограничения в количестве записей, возвращаемых таблицами Azure (по 1000 записей за раз), означают, что вам нужно реализовать несколько обращений к двум записям

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

И последнее, но не менее важное: использование таблиц Azure обычно имеет смысл, когда вы пытаетесь сократить свои расходы на хранение (это дешевле, чем SQL Azure), и когда вам нужно больше хранилища, чем может предложить SQL Azure (хотя теперь вы можете использовать Federations для ограничения максимального ограничения на максимальную память для одной базы данных). Например, если вам нужно сохранить 1 миллиард записей клиентов, использование Azure Table может иметь смысл. Но использование Azure Tables для увеличения скорости само по себе довольно подозрительно.

Если бы я был на вашем месте, я бы поставил под сомнение эту претензию очень сильно и убедился, что у вас есть навыки разработки SQL-навыков для персонала, которые могут продемонстрировать, что вы достигли узких мест производительности, присущих SQL Server/SQL Azure, прежде чем полностью изменить архитектуру.

Кроме того, я бы определил, каковы ваши цели эффективности. Вы смотрите на 100x быстрее время доступа? Вместо этого вы рассматривали кеширование? Правильно ли вы используете индексирование в своей базе данных?

Мои 2 цента...:)