Azure DocumentDB срещу MongoDB

Синтетично сравнение

DocumentDB е база данни на NoSQL като услуга, която е част от платформата Microsoft Azure. Като магазин за документи той попада в същата категория като MongoDB, CouchDB или RethinkDB и точно като тези, той обработва документи във формат JSON.

Когато обмислят интеграцията на магазин за документи на NoSQL в техните системи, много компании избират MongoDB, тъй като той е сред най-популярните двигатели на NoSQL там и стана много надежден през последните години. Считам, че DocumentDB обикновено не се взема предвид при вземането на това решение, въпреки че неговите характеристики го правят сериозен съперник на MongoDB, дори предлага по-големи предимства в някои ситуации.

Тъй като чувствам, че DocumentDB не получава любовта, която заслужава, реших да напиша това синтетично и безпристрастно сравнение между DocumentDB и MongoDB, подкрепено от указатели към съответните им документации. Надявам се това да ви послужи като ориентир, когато се опитвате да претегляте плюсовете и минусите на всяка платформа.

Актуализации на тази публикация

[Ноември 2016 г.] премахна всички споменавания за липсата на локален емулатор за DocumentDB, тъй като Microsoft обяви общата наличност на такава версия за местна разработка. Обърнете внимание, че локалният емулатор е достъпен само за Windows в момента (благодаря на Дейвид Мейсън за предложената редакция!).

[Ноември 2016 г.] премахна споменаването на автоматично изтичащи документи като функция, която е изключителна за DocumentDB, тъй като Бо Бендсен любезно посочи, че MongoDB има подобни възможности.

[Януари 2017 г.] Добавен раздел за изчерпаната сигурност на DocumentDB, вградена в сигурността, както е предложено от Мери Бранскомб.

Приликите

Концептуално има някои основни прилики между двете бази данни:

  • Документите се съхраняват и сервират във формат JSON
  • Документите могат да бъдат извлечени с помощта на богат език на заявките, който добре играе със синтаксиса JSON

Характеристики, уникални за MongoDB

Нека започнем с изброяване на основните функции на MongoDB, които нямат никакъв (разумно съвпадащ) DocumentDB колега.

Богати възможности за заявки с тръбопровода за агрегиране

Монголичният тръбопровод на MongoDB е много мощна функция, която ви позволява да изградите тръбопровод, съставен от етапи за обработка на данни, всеки филтриращ и трансформиращ документите, идващи от колекция. Възможностите, предлагани от този тръбопровод, са почти неограничени и неговата гъвкавост може да обслужва практически всякакъв вид заявки.

За сравнение, SQL-подобният синтаксис на заявки на DocumentDB позволява просто филтриране над документите, дори липсват „основни“ конструкции като брой или сума (въпреки че те работят върху него и междувременно можете да работите с Javascript от сървъра). Тук можете да намерите удобен лист за измама.

Карта-намали

По някакъв начин подобно на тръбопровода за агрегиране, функцията на MongoDB за намаляване на карти позволява на документите на колекцията да преминават през два отделни етапа, които итеративно преобразуват (или проекти), след което групират документите. И двата етапа са дефинирани в Javascript.

В DocumentDB няма подобна концепция, въпреки че подобни резултати могат да бъдат постигнати чрез съхранявани процедури (вижте по-долу).

Пълнотекстови индекси

Сред различните видове индекси, налични на MongoDB, текстовият индекс предлага пълнотекстови възможности за търсене.

DocumentDB не предоставя пълно индексиране в пълен текст. Препоръчителният начин за добавяне на пълнотекстово търсене към база данни на DocumentDB е да го сдвоите с услуга за търсене на Azure; има добра история за интеграция между двете.

Повече платформи, поддържани от клиентски драйвери

Мисля, че е важно да споменем, че драйверите на MongoDB поддържат много голям спектър от платформи, докато DocumentDB има само SDK файлове за .NET, Java, Python и Node.js - но можете да опитате късмета си, като използвате всеки драйвер на MongoDB с DocumentDB благодарение на неговата поддръжка за протокола на MongoDB.

Функции, уникални за DocumentDB

Сега нека направим обратното упражнение и да изброим функциите на DocumentDB, които не могат да бъдат намерени в MongoDB.

От сървъра Javascript

Това е ключова характеристика на DocumentDB. Той има богат на сървъра Javascript API от страна на сървъра, който ви позволява да създавате функции за обработка на данни. Тези сървърни функции могат да приемат 3 различни форми:

  • съхранени процедури, които могат да правят почти всичко (вмъкване, запитване, актуализиране на документи) и да се обаждат чрез SDK или REST API
  • задействащи механизми (или куки), които се изпълняват преди или след конкретни операции (например при вмъкване на документ например)
  • UDFs (дефинирани от потребителя функции), от които може да се извиква и увеличава SQL езика за заявки, като по този начин стеснява разликата с богатите възможности на MongoDB за заявки

Сега MongoDB може да изпълнява и Javascript от сървър, но разбирането ми е, че:

  • Намалете картата и $ където операторът на заявки може да се използва само за заявки, а не за актуализации
  • Функциите Javascript, които можете да съхранявате в специалната системна колекция, са подходящи само за целите на администриране или поддръжка.

В документацията на MongoDB ясно се посочва, че има ограничения на производителността при изпълнение на Javascript от страна на сървъра; за сравнение DocumentDB е наистина проектиран за тази цел, тъй като предварително компилира вашия Javascript код, след което съхранява и изпълнява получения байт код.

Сделки

Благодарение на съхранените от Javascript процедури, които току-що споменахме, е възможно да стартирате ACID транзакции върху колекция DocumentDB. Начинът на работа е наистина прост: ако вашата JavaScript функция завърши, всички операции по записване, които е извършил, се ангажират; ако функцията хвърля някакво изключение, всички операции се връщат назад.

В MongoDB наистина няма концепция за транзакция, освен едноатомна атомност, което означава, че вмъкването или актуализирането на документ е гарантирано като атомно, но операцията по записване, включваща множество документи, не е атомна като цяло.

Пълно индексиране по подразбиране

DocumentDB предприема доста драстичен подход към индексирането: по подразбиране индексира всички полета на документите, които съхранявате! Много от вас могат да видят това като загуба на време за обработка и пространство за съхранение - което честно казано е до известна степен - но това дава интересното предимство на предлагането на отлично изпълнение на заявките извън кутията. За тези, които предпочитат да имат по-добър контрол върху това, което се индексира, винаги е възможно да се определят персонализирани политики за индексиране.

(Лесно) глобално разпространение

Друго доста скорошно допълнение към възможностите на DocumentDB е глобалното разпространение. По принцип тази функция ви позволява да мащабирате вашия екземпляр DocumentDB в различни региони по света и да определите какъв тип съгласуваност очаквате между регионите - от силна до евентуална. Възможно е дори да се конфигурира автоматичен и прозрачен отказ при различни региони.

Разбира се, разполагането на световен клъстер от MongoDB възли със сигурност е възможно, но това, което искам да подчертая тук, е колко лесно е да настроите такъв клъстер. Това очевидно е извън основните функции на DocumentDB и е свързано с неговата природа на PaaS, но не вярвам, че има доставчик на услуги, предлагащ такава георазпределена настройка за MongoDB (с тази цена и лекота на използване).

Сигурност

Заслужава да се спомене, че като услуга DocumentDB осигурява вграден контрол на сигурността и достъпа, които са там по подразбиране ... Без администраторски достъп без парола! И освен това, тя също така дава възможността да контролира достъпа до колекции и документи с фин начин, като създава потребители и ги свързва с тези ресурси чрез защитени с парола разрешения.

Ценообразуване

Последният, но със сигурност не на последно място критерий за сравнение е разходът. Но трябва да внимаваме да не сравняваме ябълки и портокали тук: DocumentDB принадлежи към семейството на PaaS, докато MongoDB е база данни, а не услуга. Затова нека вземем mLab, предложение на MongoDB PaaS, за сравнение.

Първо трябва да изясня как се зарежда DocumentDB. Всяка колекция се таксува в 2 измерения:

  • използвано съхранение, при 0,25 USD на GB / месец
  • резервирани заявки за секунди, при ~ 6 USD за 100 RU / месец

Броят на RU, който резервирате, диктува гарантираната ширина на честотната лента, която ще получите (искате да научите повече за заявките за единици? Проверете моята публикация!). По принцип ЖП представлява „обработката, необходима за четене на един 1KB документ с 10 свойства“. Като се има предвид, не е лесно да се оцени реалната цена на сложни операции като големи заявки или сложна съхранена процедура, въпреки че това ръководство помага много. Но можем да направим обратното упражнение, като погледнем колко RU можем да получим за цената на план на mlab.

Това, което не споменах досега, е, че DocumentDB работи на локален SSD, така че за да направим справедливо сравнение, нека вземем плана „High Performance M3“ от тази страница, който към момента на писането (септември 2016 г.) е на цена 1390 USD месечно за 80 GB място за съхранение.

  • Тези 80GB ще бъдат таксувани 20 USD на DocumentDB
  • Това оставя 1370 USD или повече от 22 800 RU

Споменах преди, че е трудно да се оцени „стойността“ на ЖП, но от моя опит 22 800 са много, нещо в обхвата на 200 сложни заявки в секунда. И въпреки че е подобно трудно да се оцени възможностите на този план за високопроизводителни M3, бих казал, че играем в подобен мащаб или поне не се различаваме по големина.

Освен това, което е хубаво с еластичността на RU е, че той е проектиран да бъде единица мащаб, което означава, че можете да започнете със скромно количество RU и (безпроблемно) да го мащабите, когато използването на вашите колекции се увеличава, докато все още възползвайки се от локалните SSD характеристики от самото начало.

Какво ще кажете за цената на заключването на доставчика?

Притеснение, изразено от мнозина, е блокирането на доставчика: ако използвам DocumentDB, аз не съм заключен само с Microsoft, но и с Azure като платформа. Можете дори да спорите, че липсата на такова заключване е трябвало да бъде посочена в предимствата на MongoDB пред DocumentDB. Съгласен съм. Но каква е реалната цена на това заключване?

DocumentDB съхранява документи във формат JSON. Това е стандартен формат, използван от повечето бази данни NoSQL (ей, дори SQL Server говори JSON!), Така че преместването на вашите документи от DocumentDB и инжектирането им в друга база данни не трябва да е проблем.

Основното техническо заключване, с което трябва да се справите, е интерфейсът на заявките: всяка база данни има свой собствен начин за търсене на документи. През повечето време вие ​​извършвате тези заявки чрез някакъв SDK или драйвер, така че от гледна точка на кода на приложението ви, заключването или придържането към определена база данни идва главно от интерфейса на този SDK. След това, ако вашите разработчици се справят правилно, този интерфейс трябва да бъде капсулиран зад някакъв интерфейс за достъп до данни, който крие подробности за внедряването в останалата част от приложението.

И ако притеснението ви е, че на по-късен етап може да искате да мигрирате към MongoDB, не забравяйте, че DocumentDB има съвместимост с протокола с MongoDB, което означава, че можете да използвате всеки драйвер на MongoDB за достъп до DocumentDB и да извършите повечето от CRUD операции.

Как препоръчвам да насочвате вашето решение

Когато я приключите, ето първите въпроси, които мисля, че бихте могли да си зададете, когато трябва да направите избор между тези бази данни (без конкретен ред):

  • Сложност на заявките: вашите заявки изискват ли пълната мощност на агрегационния тръбопровод на MongoDB или можете да ги внедрите с SQL на DocumentDB и някои Javascript от страна на сървъра?
  • Транзакции: Вашата бизнес логика изисква транзакции с много документи за цялата колекция, или атомността на един документ на MongoDB е достатъчна за вашите изисквания?

Въз основа на вашите отговори и общата посока, която дават, можете да прецизирате анализа си и да разгледате останалите функции, които споменах (пълнотекстово търсене, глобално разпространение и т.н.)

Моля коментирайте!

Опитах се да извърша това сравнение по най-честен и безпристрастен начин, но можех да сбъркам в някои аспекти. Така че не се колебайте да се свържете, ако смятате, че някои функции липсват или са надценявани или подценявани! Възнамерявам този пост да се развива с течение на времето и да се допълва, за да стане добра справка за сравнението между DocumentDB и MongoDB.

Благодаря за четенето!