Azure DocumentDB vs MongoDB

Sünteetiline võrdlus

DocumentDB on NoSQL-i andmebaas teenusena, see on osa Microsoft Azure platvormist. Dokumentide hoidjana kuulub see samasse kategooriasse nagu MongoDB, CouchDB või RethinkDB ja just nagu need, töötleb ta dokumente JSON-vormingus.

Kaaludes NoSQL-i dokumendipoe integreerimist nende süsteemidesse, valivad paljud ettevõtted MongoDB-i, kuna see on seal populaarseimate NoSQL-i mootorite hulgas ja see on viimastel aastatel muutunud väga usaldusväärseks. Ma leian, et DocumentDB ei arvesta selle otsuse vastuvõtmisel tavaliselt, ehkki selle omadused muudavad selle MongoDB-iga tõsiseks pretendendiks, pakkudes mõnes olukorras isegi tugevamaid eeliseid.

Kuna ma leian, et DocumentDB ei saa armastust, mida ta väärib, otsustasin kirjutada selle sünteetilise ja erapooletu võrdluse DocumentDB ja MongoDB vahel, mida viitavad nende dokumendid. Loodan, et see võib teile olla juhiseks iga platvormi plusside ja miinuste kaalumisel.

Selle postituse värskendused

[November 2016] eemaldati kõik mainid dokumendiDBDB kohaliku emulaatori puudumise kohta, kuna Microsoft teatas sellise kohaliku arendusversiooni üldisest kättesaadavusest. Pange tähele, et kohalik emulaator on praegu saadaval ainult Windowsi jaoks (tänan David Masonit soovitatud muudatuse eest!).

[November 2016] eemaldati mainimine, et dokumentide automaatne aegumine on ainus funktsioon DocumentDB jaoks, kuna Bo Bendtsen tõi lahkelt välja, et MongoDB-l on sarnased võimalused.

[Jaanuar 2017] lisas jaotise DocumentDB sisseehitatud turvalisuse kohta, nagu soovitas Mary Branscombe.

Sarnasused

Mõisteliselt on kahe andmebaasi vahel mõned põhilised sarnasused:

  • Dokumente säilitatakse ja serveeritakse JSON-vormingus
  • Dokumente saab hankida rikkaliku päringkeele abil, mis sobib hästi JSON-i süntaksiga

Funktsioonid, mis on ainulaadsed MongoDB-le

Alustame loetledes peamised MongoDB-funktsioonid, millel pole (mõistlikult sobivat) DocumentDB-i vasteid.

Rikkalikud päringuvõimalused liitmise torujuhtmega

MongoDB liitmise juhetorustik on väga võimas funktsioon, mis võimaldab teil luua andmetöötlusetappidest koosneva torujuhtme, millest igaüks filtreerib ja muudab kogust pärinevaid dokumente. Selle torujuhtme pakutavad võimalused on peaaegu piiramatud ja selle paindlikkus vastab praktiliselt igasugustele päringutele.

Võrdluseks - DocumentDB SQL-i sarnane päringute süntaks võimaldab dokumentidest lihtsat filtreerimist, isegi kui puuduvad sellised “põhilised” konstruktsioonid nagu loendus või summa (ehkki nad töötavad selle kallal ja võite vahepeal serveripoolse Javascriptiga ümber käia). Käepärase päringu petmise lehe leiate siit.

Kaardi vähendamine

MongoDB kaardistamise funktsioon, mis sarnaneb liitmise torustikuga, laseb MongoDB kaardi vähendamise funktsioonil kogu dokumentidel voolata läbi 2 eraldi etapi, mis korduvad (või projektid) iteratiivselt (seejärel projektid) ja seejärel rühmitavad dokumendid. Mõlemad etapid on määratletud Javascriptis.

DocumentDB-s sellist kontseptsiooni pole, kuigi salvestatud protseduuride abil saab sarnaseid tulemusi saavutada (vt allpool).

Täisteksti indeksid

MongoDB-s saadaolevate erinevat tüüpi indeksite hulgas pakub tekstiindeks täistekstiotsingu võimalusi.

DocumentDB ei paku täisteksti indekseerimist. Soovitatav viis täistekstiotsingu lisamiseks DocumentDB andmebaasi on siduda see Azure'i otsinguteenusega; nende kahe vahel on hea integratsioonilugu.

Rohkem platvorme, mida kliendipoolsed draiverid toetavad

Ma arvan, et on oluline mainida, et MongoDB draiverid toetavad väga suurt platvormide spektrit, samas kui DocumentDB-l on ainult .NET, Java, Python ja Node.js jaoks SDK-d - kuid tänu oma toele saate oma õnne proovida mis tahes MongoDB draiveriga, millel on DocumentDB. MongoDB protokolli jaoks.

Ainulaadsed funktsioonid DocumentDB jaoks

Teeme nüüd ümberpööratud harjutuse ja loetleme DocumentDB funktsioonid, mida MongoDB-st ei leia.

Serveripoolne Javascript

See on DocumentDB põhifunktsioon. Sellel on rikkalik serveripoolne Javascripti API, mis võimaldab teil luua andmetöötlusfunktsioone. Need serveripoolsed funktsioonid võivad esineda kolmel erineval kujul:

  • salvestatud protseduurid, millega saab teha peaaegu kõike (dokumentide sisestamine, päringud, värskendamine) ja helistada SDK-de või REST API kaudu
  • päästikud (või konksud), mis käivitatakse enne või pärast konkreetseid toiminguid (näiteks dokumendi sisestamisel)
  • UDF-id (kasutaja määratletud funktsioonid), millele saab helistada ja SQL-päringu keelt täiendada, vähendades kuidagi lõhet MongoDB-i rikkalike päringuvõimalustega

Nüüd saab MongoDB käivitada ka serveripoolset Javascripti, kuid minu arusaam on järgmine:

  • Kaardista vähendamine ja $, kus päringu operaatorit saab kasutada ainult päringute, mitte värskenduste jaoks
  • Javascripti funktsioonid, mida saate spetsiaalsesse süsteemikogusse salvestada, sobivad ainult halduse või hoolduse jaoks.

MongoDB-i dokumentatsioonis on selgelt öeldud, et serveripoolse Javascripti täitmisel on jõudluse piirangud; Võrdluseks: DocumentDB on tõesti selleks otstarbeks loodud, kuna see eelkompileerib teie Javascripti koodi, seejärel talletab ja käivitab saadud baitkoodi.

Tehingud

Tänu Javascripti salvestatud protseduuridele, mida me just mainisime, on võimalik dokumentide kogumikus ACID-tehinguid käivitada. See toimib väga lihtsalt: kui teie Javascripti funktsioon on lõpule viidud, kohustuvad kõik teostatud kirjutamisoperatsioonid; kui funktsioon loob mõne erandi, saavad kõik toimingud tagasi.

Peale ühe dokumendi aatomilisuse ei ole MongoDB-s tegelikult ühtegi tehingukontseptsiooni, mis tähendab, et dokumendi sisestamine või värskendamine on kindlasti aatomiline, kuid mitut dokumenti hõlmav kirjutamisoperatsioon pole aatom tervikuna.

Vaikimisi täielik indekseerimine

DocumentDB on indekseerimisel üsna drastiline lähenemisviis: vaikimisi indekseerib see kõik teie salvestatud dokumentide väljad! Paljud teist võivad seda käsitleda töötlemise aja ja salvestusruumi raiskamisena - mis selles ausalt öeldes ka on -, kuid see annab huvitava eelise, pakkudes suurepärast päringu jõudlust karbist väljas. Neile, kes eelistavad indekseerimise üle paremat kontrolli saada, on alati võimalik määratleda kohandatud indekseerimiseeskirjad.

(Lihtne) globaalne levitamine

Veel üks üsna hiljutine lisand DocumentDB võimalustele on globaalne levitamine. Põhimõtteliselt võimaldab see funktsioon skannida DocumentDB eksemplari kogu maailma eri piirkondade vahel ja määratleda, millist järjepidevust regioonide vahel ootate, tugevast kuni lõpliku. Erinevates piirkondades on isegi võimalik konfigureerida automaatne ja läbipaistev tõrge.

Muidugi on MongoDB sõlmede ülemaailmse klastri juurutamine kindlasti võimalik, kuid ma tahan siinkohal rõhutada, kui lihtne on sellise klastri seadistamine. See ületab ilmselgelt DocumentDB põhifunktsioone ja on seotud selle PaaS-i olemusega, kuid ma ei usu, et keegi teenuseosutaja pakub MongoDB-le sellist geograafiliselt jaotatud seadistust (selle hinnaga ja kasutusmugavus).

Turvalisus

Väärib märkimist, et teenusena pakub DocumentDB sisseehitatud turvalisust ja juurdepääsu juhtimist, mis on vaikimisi olemas ... Paroolita administraatori juurdepääs puudub! Lisaks annab see ka võimaluse juhtida juurdepääsu kollektsioonidele ja dokumentidele detailselt, luues kasutajaid ja sidudes neid parooliga kaitstud lubade kaudu nende ressurssidega.

Hinnakujundus

Viimane, kuid kindlasti mitte vähem oluline võrdluskriteerium on hind. Kuid me peaksime olema ettevaatlikud, et mitte võrrelda õunu ja apelsine siin: DocumentDB kuulub PaaS-i perekonda, samas kui MongoDB on andmebaas, mitte teenus. Võtame võrdluspunktina MongoDB PaaS-i pakkumise mLab.

Kõigepealt peaksin selgitama, kuidas DocumentDB-i arveldatakse. Iga kollektsiooni arve esitatakse kahes mõõtmes:

  • kasutatav salvestusruum - 0,25 USD kuus GB kohta
  • reserveeritud päringu ühikud sekundis, ~ 6 USD 100 RU kohta kuus

Teie reserveeritud RE-de arv dikteerib teile garanteeritud ribalaiuse (soovite lisateavet taotlusühikute kohta? Vaadake minu postitust!). Põhimõtteliselt esindab RE “töötlemist, mis on vajalik ühe atribuudiga 1KB dokumendi lugemiseks”. Sellegipoolest ei ole keeruline hinnata keerukate toimingute, näiteks suurte päringute või keeruka salvestatud protseduuri tegelikke kulusid, ehkki see juhend aitab palju. Kuid võime teha vastupidise harjutuse, vaadates, kui palju RU-sid me võiksime saada mlab-plaani hinnaga.

Mida ma siiani ei maininud, on see, et DocumentDB töötab kohalikul SSD-l, nii et õiglase võrdluse saamiseks võtame sellelt lehelt plaani “High Performance M3”, mis selle kirjutamise ajal (september 2016) on 80 GB mäluruumi eest kuus 1390 USD.

  • Nende 80 GB arveldatakse DocumentDB-s 20 USD
  • See jätab 1370 USD ehk enam kui 22 800 RU

Mainisin enne, et RE väärtust on keeruline hinnata, kuid minu kogemuse põhjal on 22 800 palju, midagi vahemikku 200 keerulist päringut sekundis. Ja isegi kui selle sama suure jõudlusega M3-plaani võimalusi on samamoodi keeruline hinnata, ütleksin, et mängime sarnases mahus või vähemalt mitte suurusjärgus.

Lisaks on RU elastsuse juures kena see, et see on loodud mõõtühikuks, mis tähendab, et võite alustada tagasihoidliku kogusega RU-ga ja (sujuvalt) selle laiali mõõta, kui teie kogude kasutamine suureneb, samal ajal kasutades ära kohalikku SSD jõudlust algusest peale.

Aga müüja lukustamise hind?

Paljude väljendatud mure on müüjate sisselogimine: kui ma kasutan DocumentDB-d, pole mind lukustatud mitte ainult Microsofti, vaid ka Azure'i kui platvormi jaoks. Võib isegi väita, et sellise lukustuse puudumine oleks tulnud loetleda MongoDB eelistest DocumentDB ees. Ma nõustun. Millised on selle sisselogimise tegelikud kulud?

DocumentDB salvestab dokumendid JSON-vormingus. See on standardvorming, mida enamus NoSQL-i andmebaase kasutab (hei, isegi SQL Server räägib JSON-ist!), Nii et dokumentide teisaldamine DocumentDB-st välja ja nende sisestamine mõnda teise andmebaasi ei tohiks olla probleem.

Peamine tehniline lukustus, millega peate tegelema, on päringuliides: igal andmebaasil on oma viis dokumentide pärimiseks. Enamasti teostate neid päringuid mõne SDK või draiveri kaudu, seega pärineb teie rakenduskoodi vaatenurgast konkreetse andmebaasi lukustamine või sellest kinnipidamine peamiselt selle SDK liideselt. Kuid kui teie arendajad teevad seda õigesti, peaks see liides olema kapseldatud mingisuguse andmeside liidese taha, mis peidab rakenduse ülejäänud rakenduse üksikasjad.

Ja kui teie mureks on, et võiksite hiljem MongoDB-le üle minna, pidage meeles, et DocumentDB ühildub MongoDB-ga protokollidega, mis tähendab, et DocumentDB juurde pääsemiseks ja suurema osa CRUD-toimingute tegemiseks võite kasutada mis tahes MongoDB-draiverit.

Kuidas ma soovitan teie otsust juhendada

Kokkuvõtlikult öeldes on siin esimesed küsimused, mida võiksite endalt küsida, kui peaksite tegema valiku nende andmebaaside vahel (mitte mingis kindlas järjekorras):

  • Päringute keerukus: kas teie päringud nõuavad MongoDB koondamise torujuhtme täielikku võimsust või saate neid rakendada DocumentDB SQL-i ja mõne serveripoolse Javascripti abil?
  • Tehingud: kas teie äriloogika nõuab kogu kogu hõlmavaid, mitme dokumendiga tehinguid või on MongoDB-i ühe dokumendi aatomilisus teie vajaduste jaoks piisav?

Oma vastuste ja nende antud üldise suuna põhjal saate oma analüüsi täpsustada ja kaaluda ülejäänud funktsioone, mida ma mainisin (täistekstiotsing, globaalne levitamine jne).

Palun kommenteerige!

Püüdsin seda võrdlust teostada kõige ausamal ja erapooletumal viisil, kuid võisin mõnes aspektis eksida. Nii et pöörduge julgelt poole, kui tunnete, et mõni funktsioon puudub või oli üle- või alahinnatud! Ma kavatsen seda postitust aja jooksul edasi arendada ja täiendada, et saada heaks võrdlusdokumendiks DocumentDB ja MongoDB võrdlemisel.

Täname, et lugesite!