Oikean tietokannan valinta työhön voi olla pelottava tehtävä, varsinkin jos viihdyt koko SQL- ja NoSQL-vaihtoehtojen kanssa. Jos etsit joustavaa, yleiskäyttöistä vaihtoehtoa, joka sallii sujuvat kaaviot ja monimutkaiset sisäkkäiset tietorakenteet, asiakirjatietokanta saattaa olla oikea sinulle. MongoDB ja Couchbase Server ovat kaksi suosittua vaihtoehtoa. Kuinka sinun pitäisi valita?
MongoDB yhdistää valtavan suosion edut, tuen yksinkertaisille graafihauille ja kyvyn suorittaa SQL-kyselyjä BI-liittimen kautta. Couchbasella on oma suuri käyttäjäyhteisö, suorituskykyinen avainarvoarkkitehtuuri ja SQL-tyyppinen kyselykieli, joka pystyy navigoimaan sisäkkäisissä asiakirjarakenteissa.
Lyhyesti sanottuna sekä MongoDB että Couchbase ovat tehokkaita ja joustavia asiakirjoihin suuntautuneita tietokantoja, joissa on paljon lisäominaisuuksia. Heillä on kuitenkin tärkeitä eroja, jotka kallistavat tasapainoa tavalla tai toisella, tarpeidesi mukaan. Autamme sinua päättämään, marssimme nämä tietokannat läpi tärkeimmät näkökohdat, joissa kerrotaan, miten kukin toimii asennuksen ja asennuksen, hallinnon, helppokäyttöisyyden, skaalautuvuuden ja dokumentoinnin suhteen.
Tämä keskustelu perustuu MongoDB 3.4: een ja Couchbase Server 4.6: een. Saatat myös tarkistaa itsenäiset arvostelut MongoDB 3.4: sta ja Couchbase Server 4.0: sta.
Asennus ja asennus
Asennusta ja asennusta voidaan tarkastella kahdesta näkökulmasta: kehittäjät, jotka työskentelevät paikallista esiintymää vastaan, ja infrastruktuuri-insinöörit, jotka perustavat alkuperäisen tuotantoklusterin. Monilla NoSQL-tietokannoilla on vahvoja tarinoita kehittäjäystävällisyydestä, mikä lisää mahdollisuuksia kehittäjälle kokeilla tuotetta ja ottaa se käyttöön järjestelmissään. Yksinkertainen paikallinen asennus on vahva myyntivaltti. Toisaalta tietokanta todistaa viime kädessä arvonsa tuotannossa, joten tuotantoasetukset ovat yhtä tärkeitä oikeaksi pääsemiseksi.
Kehittäjän asetukset
Sen sijaan että käytämme paljaalla metallilla suoritettavia binaareja, tarkastelemme, mitä näiden kahden tietokannan asettaminen Docker-ympäristöön edellyttää. Sekä MongoDB: n että Couchbasen Docker-asennus on melko yksinkertainen. Couchbase vaatii muutaman ylimääräisen portin paljastamisen, mutta se on yksinkertainen asia käsitellä. Kun kuvat on vedetty alas ja säilöt käynnistyvät, kehittäjäkokemuksessa on huomattava ero. MongoDB: n kanssa olet valmis. Voit muodostaa yhteyden sovelluksen tai Mongo-kuoren kautta ja päästä töihin heti. Sitä vastoin Couchbase vie sinut läpi pakollisen asennusprosessin käyttöliittymän kautta, jossa kohtaat joukon määritysvaihtoehtoja, jotka on suunnattu infrastruktuuri-insinööreille. Kehittäjänä voit säilyttää valitut vaihtoehdot ja käyttää oletussäiliötä, mutta se lisää kitkaa kokemukseen.
MongoDB voittaa tämän, mutta ei ilman varoitusta. Se, että paikallinen käyttöönotto oli helppoa, ei tarkoita, että voit tehdä saman tuotannossa. Voi tuntua itsestään selvältä, että tuotantoympäristöt vaativat enemmän hoitoa ja konfigurointia, mutta aiemmin tänä vuonna levinneet laajamittaiset lunnaushyökkäykset suojaamattomiin, julkisesti saatavilla oleviin MongoDB-instansseihin viittaavat siihen, että monet kaupat käyttävät vaarallisia pikavalintoja.
Kierroksen voittaja: MongoDB.
Tuotannon asetukset
Hajautetun tietokannan käyttöönotto tuotantoon liittyy yleensä moniin vaiheisiin ja kohtuulliseen koordinointiin; MongoDB ja Couchbase eivät ole erilaiset. Molemmissa tapauksissa asennuksen vaikeus riippuu käyttöönoton vaatimuksista, ja erilaiset suorituskykyä koskevat kompromissit sisältävät monimutkaisuuden.
MongoDB-klusterit koostuvat joko kopiosarjasta tai sirpaleesta. Replikasarja on joukko MongoDB-palvelimia, jotka kaikki sisältävät saman tiedon, kun taas sirpaleinen klusteri jakaa tietoja useille kopiosarjoille. Kopiosarjat on helppo konfiguroida, ja ne koostuvat yhdestä asennettavasta palvelintyypistä. Hajautetut klusterit ovat enemmän mukana, mikä edellyttää kolmen erityyppisen palvelimen käyttöönottoa, joissa kukin on replikoitu. Klusterit voidaan määrittää komentorivilippujen, määritystiedostojen ja tietokantakomentojen avulla.
Couchbase-klusterit voivat koostua yhdestä palvelintyypistä tai useista palvelintyypeistä riippuen klusterista tarvitsemista suorituskykyominaisuuksista. Couchbase-arkkitehtuuri koostuu erilaisista palveluista, jotka voidaan ottaa käyttöön tai poistaa käytöstä solmukohtaisesti. Yksinkertaisessa tilanteessa otat kaikki palvelut käyttöön kaikissa solmuissa. Jos kuitenkin halutaan virittää jokaisen palvelun tarpeet tai haluat skaalata kutakin palvelua erikseen, joudut aloittamaan erilaisten palvelintyyppien konfiguroinnin, jakamalla hyödykelaitteistot datapalvelulle, SSD: t hakemistopalvelulle, CPU-optimoidut palvelulle. kyselypalvelu ja niin edelleen. Ryhmät voidaan määrittää sisäänrakennetun web-käyttöliittymän, komentoriviliittymän ja REST-sovellusliittymän kautta.
Tietoinfrastruktuurin tuotantoasetusten osalta sekä MongoDB että Couchbase ovat melko selkeitä. Toki, voit sukeltaa kokoonpano- ja viritysvaihtoehtoihin etkä koskaan tule ulos, mutta useimmissa tapauksissa nämä ovat infrastruktuurin insinöörien helpommassa päässä.
Kierroksen voittaja: Tie.
Hallinto
Kun tietokanta on käynnissä tuotannossa ja hyväksyy liikenteen, hallinnosta tulee keskeinen huolenaihe. Hallinnan helppouden arvioimiseksi tarkastelen varmuuskopiointia, tietokannan päivityksiä ja valvontamenetelmiä.
Varmuuskopiot
Varmuuskopiot ovat tärkeä osa tuotantotietokantahygieniaa, eikä tietokantojen ylläpito erittäin saatavana, hajautetulla tavalla muuta sitä yhtään.
MongoDB tarjoaa useita vaihtoehtoja käynnissä olevan klusterin tietojen varmuuskopioimiseksi. Jos taustalla oleva käyttöjärjestelmä tukee ajankohtaisia tilannekuvia, voit luottaa siihen ominaisuuteen kaapataksesi varmuuskopion tarkan ajankohdan. Tämä on hieman hankalaa varmuuskopioida sirpaloituneita klustereita, koska joudut ottamaan hetkellisen kuvan jokaisesta sirpaleesta ja määrityspalvelimesta samanaikaisesti.
Järjestelmätason työkaluja, kuten cp tai rsync, voidaan käyttää kopioimaan tietokantatiedostot toiseen sijaintiin, mutta kirjoittaminen on keskeytettävä prosessin aikana näiden työkalujen luonteen vuoksi. Vaikka MongoDB toimittaa komentorivityökalut tietokantojen varmuuskopioimiseksi ja palauttamiseksi, näitä työkaluja ei suositella suuremmille klustereille. Vaihtoehtoisesti voit maksaa Cloud Managerista tai Ops Managerista tai ottaa käyttöön MongoDB Atlas DBaaS -alustan kautta saadaksesi käyttöliittymäpohjaisia työkaluja, jotka hoitavat varmuuskopiot ja palautukset puolestasi.
Couchbase toimittaa komentorivityökalut eri palvelujen tietojen varmuuskopioimiseksi, ja ne voidaan määrittää suorittamaan täydet varmuuskopiot tai kahden tyyppiset lisävarmuuskopiot. Inkrementaaliset varmuuskopiot voivat olla joko inkrementaalisia viimeisestä täydellisestä varmuuskopiosta (kumulatiivinen inkrementaalinen) tai inkrementaaliset mistä tahansa viimeisestä varmuuskopiosta (differentiaaliset inkrementaaliset). Tämä mahdollistaa monimutkaiset varmuuskopiorakenteet, jotka vaativat vaihtelevaa tallennustilaa ja edellyttävät vaihtelevaa palautuskompleksisuuden tasoa.
Yritysasiakkaat voivat hyödyntää cbbackupmgr-apuohjelmaa, joka käyttää erilaisia taustalla olevia tietorakenteita parempaan suorituskykyyn tietojen varmuuskopioinnissa.
Pyöreä voittaja: Couchbase, sen suuremman joustavuuden ja tuen ansiosta varmuuskopioille.
Päivittäminen
Pitkällä käynnissä olevalla klusterilla tulisi olla selkeä, helppo päivityspolku. Mitä vaikeampi on päivittää, sitä vähemmän todennäköistä se pidetään ajan tasalla. Tämä tarkoittaa, että kehittäjät ja järjestelmänvalvojat kaipaavat uusia ominaisuuksia.
MongoDB-päivitykset ymmärretään parhaiten kopion asetetulta tasolta. Jos sinulla on sirpaleinen klusteri, seuraat enimmäkseen kappaleen kopiosarjojen päivittämisen vaiheita. Kopiosarjassa kukin toissijainen suljetaan, päivitetään paikalleen ja käynnistetään. Kun toissijaiset yksiköt ovat toiminnassa ja sopusoinnussa ensisijaisen kanssa, käynnistetään vikasietoisuus ja entinen ensisijainen voidaan poistaa ja päivittää. Se käynnistyy uudelleen toissijaisena ja saa kiinni kirjoituksista, jotka se jäi offline-tilassa. Siksi päivitykset ovat enimmäkseen online-prosessi, mutta ensisijainen vianmääritys johtaa todennäköisesti 10-20 sekuntiin ilman kirjoitusta, joten tarvitaan huoltoikkuna, jolla on hyväksyttävä seisokki.
Couchbase lähestyy päivityksiä samalla tavalla kuin lisäät tai poistat solmun klusterista. Kaikki päivitettävän solmun tiedot on tasapainotettava koko klusterin välillä ja tasapainotettava sitten uudelleen, kun päivitys on valmis ja solmu liittyy uudelleen klusteriin. Tasapainotuksen on tapahduttava klusterin jokaiselle solmulle yksi toisensa jälkeen. Tämä vie paljon kauemmin kuin MongoDB-klusterin päivittäminen, koska kaikki tiedot on siirrettävä. Toinen vaihtoehto on ottaa koko klusteri offline-tilaan, päivittää kukin solmu ja tuoda ne kaikki takaisin verkkoon.
Vaikka Couchbase-päivityspolku ei vaadi seisokkeja, prosessi on pitkä ja vaatii runsaasti datan sekoittamista toimiakseen.
Kierroksen voittaja: Tie. Tiebreaker: Jos huoltoseisokit ovat hyväksyttäviä, MongoDB voittaa. Jos ei, niin Couchbase on ainoa valinta.
Seuranta
Näkyvyys käynnissä olevaan klusteriin on tietysti välttämätöntä tietokannan onnistuneelle hallinnolle. Kun asiat menevät pieleen, mikään ei ole pahempaa kuin rajoitettu näkemys ryhmässä olevasta totuudesta.
MongoDB tarjoaa shellissä CLI-työkaluja ja -komentoja, jotka tarjoavat mittareita ilmentymien aktiivisuudesta ja suorituskyvystä. Tämän lisäksi MongoDB ohjaa sinut avuksi kolmannen osapuolen työkaluihin tai omiin yritystuotteisiin (Cloud Manager, Ops Manager, Atlas).
Toisaalta Couchbase toimittaa web-käyttöliittymän, joka sisältää tilastoja ja visualisointeja esiintymille, solmuille, kyselyn suorituskyvylle ja muulle. Lisäksi Couchbase voidaan määrittää lähettämään sähköposti-ilmoituksia, kun tietyt tilastot jäävät kantaman ulkopuolelle.
Kierroksen voittaja: Couchbase, laatikon ulkopuolisille visualisoinnille ja hälytyksille.
Helppokäyttöisyys
Kun tietokanta on perustettu ja kaikki hallintotarpeemme on täytetty, suurin huolenaihe siirtyy toiminnasta käyttöön. Haluan jakaa tiedot mallintamiseen, hakemistosuunnitteluun, peruskyselyihin ja yhdistelmiin.
Tietomallinnus
Asiakirjatietokantoina MongoDB ja Couchbase eivät voi välttää haastetta relaatiotietojen käsittelyssä. Molemmat tarjoavat mahdollisuuden tallentaa relaatiotietoja sisäkkäisiksi, denormalisoiduiksi tiedoiksi sekä viitteinä muihin ylätason asiakirjoihin. Tämä lähestymistapa tietovarastoon on pääosin molempien tietokantojen tietomallinnuksen huolenaihe huolimatta siitä, että kukin tukee kasvavia käyttötapauksia, ominaisuuksia ja kyselymalleja.
Kierroksen voittaja: Tie.
Hakemistosuunnittelu
Hakemistot suorittavat saman toiminnon dokumenttitietokannoissa kuin relaatiotietokannoissa. Toisin sanoen ne edustavat tiettyjä tietoja tehokkaammilla tavoilla kyselyn suorituskyvyn parantamiseksi. MongoDB ja Couchbase käyttävät hyvin erilaisia lähestymistapoja hakemistosuunnitteluun ja luomiseen.
MongoDB tukee hakemistojen luomista yhdelle tai useammalle asiakirjan kentälle, jolloin voit määrittää vakiohakemistojen järjestyksen ja suunnan (nouseva tai laskeva). On myös mahdollista sisällyttää erityisiä paikkatietohakemistoja ja kokotekstihakemistoja osana samaa syntaksia. Kyselymoottori käyttää näitä hakemistoja, näiden hakemistojen etuliitteitä tai useiden hakemistojen yhdistelmää pyyntöjen nopeuttamiseksi.
Couchbase käyttää kahta erilaista mekanismia kyselyn suorituskyvyn parantamiseksi: MapReduce-näkymät ja globaali toissijainen indeksi (GSI). MapReduce-näkymät koostuvat käyttäjän määrittelemästä JavaScript-koodista, joka käsittelee tietoja järjestelmän läpi kulkiessaan, kuten inkrementaalinen esikooste. MapReduce-näkymät voivat olla yhtä yksinkertaisia kuin sallia asiakirjanhaut sisäkentässä, tai ne voivat sisältää monimutkaisemman logiikan, joka suorittaa laskutoimituksia ja aggregaatteja asiakirjojen tiedoissa.
MapReduce-ohjelman kirjoittaminen JavaScriptiin kyselyjen tukemiseksi on melko hankalaa, joten kannattaa yleensä käyttää GSI: tä mahdollisuuksien mukaan. GSI: n indeksit kuvataan käyttämällä N1QL: ää (lausutaan nimellä "nikkeli"), osittaista SQL-toteutusta Couchbasen päällä. N1QL-syntakse on melko selkeä, ja N1QL-kyselyt ovat paljon parempia kuin MapReduce, mutta sinun on sijoitettava hakemisto tiettyyn solmuun. Jos haluat indeksin olevan erittäin saatavilla, sinun on luotava kyseinen hakemisto manuaalisesti useammalle kuin yhdelle solmulle.
Kierroksen voittaja: MongoDB yhdistetystä indeksointisovellusliittymästä ja kyvystä välttää MapReducea kokonaan.
Peruskyselyt
Kun otetaan huomioon asianmukainen tietomalli, useimmat kyselyt tietokantaan ovat yleensä yksinkertaisia. Niiden CRUD-toimintojen lisäksi, joissa kyseessä olevan asiakirjan tunnus on tiedossa, on tärkeää pystyä ilmaisemaan erilaisia tapoja suodattaa asiakirjoja ja valita kiinnostavat kentät.
MongoDB kuvaa kyselyjä JSON: ssa ja tarjoaa deklaratiivisen syntaksin ehtojen ja suodattimien määrittämiseksi kentille. Kyselyasiakirja voi koostua mistä tahansa joukosta kyselyn valitsimia, jotka kuvaavat miltä tulosjoukon pitäisi näyttää. Alueet, tasa-arvo, tekstihaku ja paikkatietokyselyt voidaan kaikki määritellä tässä kyselyasiakirjassa. Asiakirja tukee loogisia operaattoreita, joten useita kyselylausekkeita voidaan yhdistää loogisesti yhteen JA, TAI, ja niin edelleen. Kyselyasiakirjasta voi nopeasti kasvaa voimakkaasti sisäkkäinen JSON-asiakirja, joka voi toisinaan olla ylivoimainen ja vie ehdottomasti tottua. On myös mahdollista käyttää ennusteita kyselyissä, jolloin voit palauttaa vain sinulle tärkeät kentät ja pienentää tuloksen kokoa langan yli.
