it-swarm.com.ru

БД Microsoft Cosmos (API DocumentDB) и БД Cosmos (API таблиц)

Microsoft Cosmos DB включает в себя API DocumentDB, API таблиц и другие. У меня есть ~ 10 TB данных и я хотел бы получить быстрый поиск по значению ключа (очень мало обновлений и записей, в основном это чтение). Добавьте ссылку на БД Microsoft Cosmos: https://docs.Microsoft.com/en-us/Azure/cosmos-db/

  1. Так как же выбрать между API DocumentDB и API таблиц? 
  2. Или когда я должен выбрать DocumentDB API? Когда я должен выбрать Table API? 
  3. Полезно ли использовать API DcoumentDB для хранения 10 TB данных?
8
nkhuyu

Так как же выбрать между API DocumentDB и API таблиц?

Выбор между DocumentDB API и Table API будет в основном зависеть от типа данных, которые вы собираетесь хранить. DocumentDB API предоставляет schema-less JSON database engine with SQL querying capabilities, тогда как Table API предоставляет key-value storage database service. Поскольку вы упомянули, что ваши данные основаны на key-value, рекомендуется использовать Table API.

Или когда я должен выбрать DocumentDB API? Когда я должен выбрать Table API?

То же, что и выше.

Полезно ли использовать API DcoumentDB для хранения 10 TB данных?

И Document DB API, и Table API предназначены для хранения огромных объемов данных.

Однако вы можете захотеть посмотреть на Azure Table Storage также. Cosmos DB позволяет вам точно настроить необходимую вам пропускную способность, а также надежную поддержку индексирования/запросов по цене. Azure Tables, с другой стороны, имеет фиксированную пропускную способность и ограниченную поддержку индексирования/запросов и является чрезвычайно дешевым по сравнению с Cosmos DB.

Вы можете найти эту ссылку полезной, чтобы узнать больше о Cosmos DB: https://docs.Microsoft.com/en-us/Azure/cosmos-db/introduction .

6
Gaurav Mantri

API таблицы Azure Cosmos DB Table был представлен, чтобы сделать сообщество Cosmos DB и его расширенные функции индексирования, геораспределения и т.д. Доступными для сообщества хранилищ Azure Table. Идея заключается в том, что тот, кто использует хранилище таблиц Azure, которому нужны более продвинутые функции, предлагаемые только Cosmos DB, может буквально просто изменить строку подключения, и существующий код будет работать с Cosmos DB. 

Но если вы являетесь клиентом с нуля, то я бы порекомендовал использовать SQL API (ранее называемый Document DB API), который является супер-набором Table API. Мы постоянно инвестируем в предоставление более продвинутых функций и возможностей для SQL API, в то время как для Table API мы просто стремимся поддерживать совместимость с API хранилища таблиц Azure, который не менялся в течение многих лет.

То, сколько у вас данных, никак не влияет на то, какой API вы выберете. Они оба имеют одинаковую многомодельную инфраструктуру и могут обрабатывать данные одинакового размера, нагрузки запросов, распределения и т.д. 

9
Yaron Y. Goland

Пожалуйста, не отмечайте это как не по теме.

Это может помочь вам знать заранее: если вы рассматриваете интерфейс документа, то на самом деле существует нечувствительность к регистру, которая может повлиять на то, как классы DataContract (и, я полагаю, все остальные) преобразуются в и из Космоса. 

В связанном обсуждении ниже вы увидите, что в Newtonsoft.Json не учитывается регистр, который может влиять на вашу обработку объектов, которые вы передаете или получаете непосредственно из API. Не то, чтобы у Космоса были ЛЮБЫЕ недостатки, и на самом деле это совершенно превосходно. Но с API документа вы могли бы (как и я) начать просто передавать объекты DataContract в Cosmos (что, очевидно, не так и на самом деле очень ожидаемо от API объекта), но есть некоторые опции обработчика сериализатора и стратегии именования, которые Вы, вероятно, лучше, по крайней мере, знать об этом заранее.

Так что просто добавьте заметку для вас, чтобы быть в курсе этого поведения с интерфейсом объекта. Обсуждение здесь на GitHub:

https://github.com/JamesNK/Newtonsoft.Json/issues/815

1
Steven Coco