Microsoft Azure DocumentDB vs Azure Table Storage

В течение нескольких последних лет Microsoft предлагает хранилище ключей/значений "NoSQL", называемое "Хранилище таблиц" (http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-tables/)

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

Недавно Microsoft анонсировала новую услугу "NoSQL" под названием "DocumentDB" (http://azure.microsoft.com/en-us/documentation/services/documentdb/)

Вместо хранения списка свойств (например, таблицы) DocumentDB хранит объекты JSON. Весь проиндексируемый объект - поэтому эффективные запросы могут быть созданы на основе каждого свойства и любого вложенного свойства хранимых объектов.

Microsoft заявляет, что DocumentDB обеспечивает высокую производительность и масштабируемость.

Если это так - почему кто-нибудь будет использовать Table Storage для DocumentDB? Похоже, что DocumentDB предоставляет те же функции, что и таблицы, но с дополнительными возможностями, такими как возможность индексирования чего-либо.

Я буду рад, если кто-то сравним DocumentDB и Table Storage, выделив минусы и плюсы каждого из них.

Ответ 1

Оба являются технологиями NOSql, но они совершенно разные. Azure Tables - это простое хранилище Key/Value и не поддерживает сложные функции, такие как сложные запросы (большинство из них потребуют полного сканирования разделов/таблиц в любом случае, что убьет вашу производительность и экономию средств), выборочная индексация (индексирование основано на PartitionKey и RowKey, вы в настоящее время не можете индексировать какое-либо другое свойство сущности, и для поиска чего-либо, кроме комбинации PartitionKey/RowKey, потребуется сканирование раздела/таблицы) или хранимых процедур. Вы также не можете выполнять запросы на чтение для нескольких объектов (хотя запросы на пакетную запись поддерживаются, если все сущности подчиняются одному и тому же разделу). Для реального использования таблиц Azure см. ЗДЕСЬ.

Если ваши данные (в частности, вокруг их запроса) просты (как в примере выше), то таблицы Azure предоставляют то, что вам нужно, вы можете использовать это в пользу DocDB из-за ценообразования, производительности и емкости хранилища. Например, Azure Tables целевой показатель производительности составляет 20 000 операций в секунду. Попытка получить тот же уровень производительности на DocDB будет иметь значительно более высокую стоимость обслуживания для вас. Кроме того, таблицы Azure ограничены пропускной способностью вашей учетной записи хранения Azure ( 500TB), тогда как хранилище DocDB ограничено единицами мощности, которые вы покупаете.

Ответ 2

Службы таблиц - это, в основном, тип NOSQL с ключевым значением, а DocumentDB - это (как следует из названия) хранилище NoSQL типа документа. То, что вы просите, по существу, является разницей между этими двумя типами подходов NOSQL. Если вы сформируете свое исследование в соответствии с этим, вы должны быть в состоянии получить лучшее понимание наверняка.

Просто, чтобы все было просто, я предлагаю вам рассмотреть различия между оценками DocumentDB и Table Services. Не только стоимость этих услуг сильно отличается друг от друга, но тот факт, что DocumentDB работает с "первой позицией" и Table Services, предлагается по цене, основанной на чистом потреблении, может дать вам некоторые подсказки относительно вашего сравнения/контраста.

Позвольте мне спросить вас об этом; почему я должен использовать DocumentDB, если функции в Table Services хорошо удовлетворяют мои потребности?;) Я предлагаю вам взглянуть на то, как текущая утилита Azure Diagnostics использует Azure Storage Services, как показатели хранилища используют Azure Storage для себя, чтобы понять, насколько полезны службы таблиц и как может быть избыточным DocumentDB в некоторых ситуациях.

Надеюсь, что это поможет.

Ответ 3

Пример реальной жизни:

Мне нужно хранить некоторые токены, извлекать их, удалять. Только выполненный запрос будет основан на идентификаторе пользователя.

Поэтому я использую Table Storage, так как он отлично выполняет мои требования. Я сохраняю токен от идентификатора пользователя.

Документ DB, казалось, был излишним для этого.

Ответ 4

Я думаю, что сравнение касается торговой цены за производительность. Службы таблиц - это только службы хранения данных, которые, как представляется, закрываются на 20 000 операций в секунду, но постоянно оплачивают такую пропускную способность (потому что Storage дает нам все это время) составляет 1 200 долл. США в месяц. Сумасшедшие деньги.

Службы таблиц имеют простые индексы, поэтому запросы очень ограничены. Хорошо для всего, что написано и читается через идентификаторы. DocumentDB индексирует весь документ, поэтому запрос может быть выполнен для любого свойства.

И, наконец, сервисы таблиц связаны ограничением хранения учетной записи хранилища (что может привести к сумасшедшему высокому согласованию с Microsoft напрямую), где хранилище DocumentDB кажется неограниченным.

Итак, это баланс. У вас много данных (сотни концертов или терабайт), которые вам нужны в одном месте? DocumentDB. Нужно ли вам поддерживать сложные запросы? DocumentDB. У вас есть данные, которые нужно быстро и быстро приходить, но на основе поиска свойств 1 к 2? Столовые сервисы. Не могли бы вы обменять код на простой индекс, чтобы не платить за нос за пропускную способность? Услуги таблицы.

И Редис, кто-то сказал, что... человек, я не знаю. Даже наличие настойчивости в каркасе кэширования (которое предлагает Редис) не превращает его в технологию выбора... Существует огромное различие между постоянным хранилищем, в котором хранятся данные, которые часто используются, но могут отсутствовать или "время от времени", как и кеш, и постоянное хранилище, которое гарантирует, что ваши данные будут там.