Некоторые рекомендации по проектированию базы данных Azure CosmosDB с использованием SQL API - PullRequest
0 голосов
/ 11 мая 2019

Я создаю приложение Node, которое в настоящее время использует MongoDB с Mongoose.Большая часть данных, которые использует мое приложение, периодически синхронизируется с веб-сервисом SOAP.Этот веб-сервис SOAP предоставляет множество различных объектов данных (например, Organization, Contact, SupportTicket и т. Д.), Которые связаны между собой, но все объекты извлекаются в отдельных запросах.

Эти объекты в настоящее время хранятся в собственной коллекции MongoDB.,Поскольку данные являются реляционными, я могу выполнять соединения через виртуальные среды Mongoose.Поэтому я определил отношение в схемах Mongoose для Contact, которое связывает сущность Contant с сущностью организации.Работает довольно хорошо таким образом;один запрос Mongoose возвращает организацию со всеми связанными контактами.Конечно, то же самое относится и к другим сущностям.

Я подумываю о переходе на Azure CosmosDB.MongoDB API звучит как правильный подход, но у меня возникают проблемы с обработкой HTTP 429 («запрос на ограничение достигнут, попробуйте еще раз», см. uservoice ), которые иногда возникают при синхронизации больших наборов данных, полученных черезSOAP API.Механизм повторного спуска встроен в NodeJS SDK для API SQL.

Другим вариантом будет переключение на SQL API, но тогда у меня могут возникнуть проблемы с моделированием данных, которые я синхронизирую и храню.Поскольку мое приложение не несет ответственности (или не может) вносить изменения в несколько сущностей, которые я извлекаю через API-интерфейс SOAP, вложение данных в документы с поддокументами не похоже на правильный подход.Если один контакт должен измениться, мне нужно создать довольно сложный механизм для обнаружения этого и следующего обновления всех вложенных контактов в каждом документе, который содержит определенный контакт (в этом примере Organization и SupportTicket, но есть и другие).

Кроме того, SQL API не поддерживает перекрестную коллекцию JOIN.Я мог бы хранить все документы в одной коллекции и использовать какое-либо свойство дискриминатора (например, «вид» или «тип»), чтобы указать, о каком объекте идет речь в документе, но, похоже, я должен сам с этим справиться.Я бы предпочел использовать для этого какой-то ORM, который я не смог найти для NodeJS.Mongoose поддерживает это (как описано здесь: дискриминаторы Мангуста ), но чем-то я застрял с проблемой HTTP 429 повторного запроса.

Реляционная база данных могла бы быть хорошим подходом, но я бы предпочел придерживаться NoSQL, так как партнер, предоставляющий веб-сервис SOAP, уже обрабатывает меньше накладных расходов и согласованности данных, так что это не аргумент.

Так что мне интересно, какой будет хороший подход к моему решению;

  • переключитесь на Azure Cosmos DB с SQL API и забудьте о перекрестных коллекциях JOIN (намного больше кода и больше запросов, объединяющихся в коде) и ручной обработке свойств дискриминатора в моих «моделях»;
  • переключитесь на Azure Cosmos DB с API MongoDB и увеличьте мой RU до уровня, по которому я никогда не получаю HTTP 429 (т.е. платите намного больше!)
  • переключитесь на модель реляционной базы данных (подробнеенакладные расходы)
  • и вообще забудьте о Azure Cosmos DB.

Любой совет приветствуется!

...