Programmēšana

NoSQL aizvainojums: MongoDB pret Couchbase Server

Pareizas datu bāzes izvēle šim darbam var būt biedējošs uzdevums, it īpaši, ja jūs izklaidējat visu SQL un NoSQL opciju vietu. Ja jūs meklējat elastīgu vispārējas izvēles iespēju, kas ļauj izmantot plūstošas ​​shēmas un sarežģītas ligzdotas datu struktūras, dokumentu datu bāze var būt jums piemērota. MongoDB un Couchbase Server ir divas populāras izvēles iespējas. Kā jums vajadzētu izvēlēties?

MongoDB apvieno milzīgas popularitātes priekšrocības, atbalstu vienkāršiem diagrammu meklējumiem un iespēju veikt SQL vaicājumus, izmantojot BI savienotāju. Couchbase ir sava plaša lietotāju kopiena, veiksmīga atslēgas vērtības arhitektūra un SQL līdzīga vaicājumu valoda, kas spēj orientēties ligzdoto dokumentu struktūrās.

Īsāk sakot, gan MongoDB, gan Couchbase ir spēcīgas un elastīgas uz dokumentiem orientētas datu bāzes ar daudzām ekstrām. Tas nozīmē, ka viņiem ir svarīgas atšķirības, kas līdzsvaru vienā vai otrā virzienā, atkarībā no jūsu vajadzībām. Lai palīdzētu jums izlemt, mēs pārcelsim šīs datubāzes, izmantojot galveno apsvērumu aprakstu, aptverot katras veiktspēju attiecībā uz instalēšanu un iestatīšanu, administrēšanu, lietošanas ērtumu, mērogojamību un dokumentāciju.

Šīs diskusijas pamatā ir MongoDB 3.4 un Couchbase Server 4.6. Jūs varētu arī apskatīt manas atsevišķās atsauksmes par MongoDB 3.4 un Couchbase Server 4.0.

Uzstādīšana un iestatīšana

Uzstādīšanu un iestatīšanu var apskatīt no divām perspektīvām: izstrādātājiem, kas strādā pret vietējo instanci, un infrastruktūras inženieriem, kas izveido sākotnējo ražošanas kopu. Daudzām NoSQL datu bāzēm ir spēcīgi stāsti par draudzīgumu izstrādātājiem, palielinot iespēju, ka izstrādātājs izmēģina produktu un ievieš to savās sistēmās. Vienkārša vietējā iestatīšana ir spēcīgs pārdošanas punkts. No otras puses, datubāze galu galā pierādīs savu vērtību ražošanā, tāpēc ražošanas iestatīšana ir tikpat svarīga, lai panāktu pareizību.

Izstrādātāja iestatīšana

Tā vietā, lai izmantotu bināros failus, kas darbojas uz tukša metāla, mēs apskatīsim, kas nepieciešams, lai šīs divas datu bāzes izveidotu Docker vidē. Docker iestatīšana gan MongoDB, gan Couchbase ir diezgan vienkārša. Couchbase prasa, lai tiktu pakļauti daži papildu porti, taču tas ir vienkārši jārisina. Kad attēli ir noņemti un palaiž konteineri, izstrādātāja pieredze ievērojami atšķiras. Izmantojot MongoDB, jūs esat pabeidzis. Varat izveidot savienojumu, izmantojot lietojumprogrammu vai Mongo apvalku, un nekavējoties sākt strādāt. Turpretī Couchbase ļauj jums veikt obligātu iestatīšanas procesu, izmantojot lietotāja interfeisu, kur jūs saskaras ar virkni konfigurācijas iespēju, kas paredzētas infrastruktūras inženieriem. Kā izstrādātājs varat saglabāt atlasītās opcijas un izmantot noklusējuma segmentu, taču tas papildina pieredzi.

MongoDB uzvar šo, bet ne bez brīdinājuma. Tas, ka vietējā izvietošana bija vienkārša, nenozīmē, ka jūs varat darīt to pašu ražošanā. Var šķist acīmredzams, ka ražošanas videi nepieciešama lielāka kopšana un konfigurēšana, taču plaši izpirkuma uzbrukumi nenodrošinātiem, publiski pieejamiem MongoDB gadījumiem šī gada sākumā liecina, ka daudzi veikali izmanto bīstamus īsceļus.

Kārtas uzvarētājs: MongoDB.

Ražošanas iestatīšana

Izplatītas datu bāzes ieviešana ražošanā mēdz ietvert daudzus soļus un pienācīgu koordinācijas pakāpi; MongoDB un Couchbase neatšķiras. Abos gadījumos iestatīšanas grūtības būs atkarīgas no izvietošanas prasībām, ar dažādiem veiktspējas kompromisiem, kas saistīti ar dažādu sarežģītības pakāpi.

MongoDB kopas sastāvēs vai nu no kopiju kopas, vai sadalītas kopas. Replikas kopa ir MongoDB serveru grupa, kas visi satur vienus un tos pašus datus, savukārt sadalītā kopa izplata datus vairākās kopiju kopās. Repliku kopas ir vienkārši konfigurējamas, un tās sastāv no viena veida izvietotajiem serveriem. Ir vairāk iesaistītas sadalītās kopas, kas prasa izvietot trīs dažādu veidu serverus, kur katrs tiek atkārtots. Klasterus var konfigurēt, izmantojot komandrindas karodziņus, konfigurācijas failus un datu bāzes komandas.

Couchbase kopas var sastāvēt no viena servera tipa vai vairākiem serveru tipiem, atkarībā no veiktspējas īpašībām, kas jums nepieciešami no klastera. Couchbase arhitektūra sastāv no dažādiem pakalpojumiem, kurus var iespējot vai atspējot katram mezglam. Vienkāršā scenārijā jūs iespējojat visus pakalpojumus visos mezglos. Tomēr, ja vēlaties pielāgoties katra pakalpojuma vajadzībām vai vēlaties mērogot katru pakalpojumu neatkarīgi, jums būs jāsāk konfigurēt dažādi serveru tipi, piešķirot preču aparatūru datu dienestam, SSD indeksa pakalpojumam, optimizētu procesoram. vaicājumu pakalpojums utt. Klasterus var konfigurēt, izmantojot iebūvēto tīmekļa lietotāja interfeisu, komandrindas saskarni un REST API.

Ciktāl tas attiecas uz datu infrastruktūras ražošanas iestatīšanu, gan MongoDB, gan Couchbase ir diezgan skaidras. Protams, jūs varat izpētīt konfigurācijas un pielāgošanas iespējas un nekad neiznākt, taču vairumā gadījumu tie būs vieglāk infrastruktūras inženieriem.

Kārtas uzvarētājs: Kaklasaite.

Administrācija

Kad datu bāze darbojas un pieņem datplūsmu, administrēšana kļūst par galveno problēmu. Lai novērtētu administrēšanas vieglumu, es apskatīšu dublēšanas procesu, datu bāzes jauninājumus un uzraudzības pieejas.

Dublējumi

Dublējumi ir svarīga ražošanas datubāzu higiēnas sastāvdaļa, un datu bāzu vadīšana ļoti pieejamā, izplatītā veidā to nemaina.

MongoDB piedāvā vairākas iespējas darbojošās kopas datu dublēšanai. Ja pamatā esošā operētājsistēma atbalsta momentuzņēmumus vienā brīdī, varat paļauties uz šo funkciju, lai precīzi ierakstītu dublējumu. Tas kļūst nedaudz grūts, lai dublētu sadalītās kopas, jo vienlaikus būs jāuzņem katras lauskas sekundārs un konfigurācijas serveris.

Sistēmas līmeņa rīkus, piemēram, cp vai rsync, var izmantot, lai kopētu datu bāzes failus uz citu vietu, taču rakstīšana procesa laikā ir jāpārtrauc šo rīku rakstura dēļ. Lai gan MongoDB piegādā komandrindas rīkus, lai dublētu un atjaunotu datu bāzes, šie rīki nav ieteicami lielākām kopām. Alternatīvi, jūs varat maksāt par Cloud Manager vai Ops Manager vai izvietot, izmantojot MongoDB Atlas DBaaS platformu, lai iegūtu uz UI balstītus rīkus, kas rūpēsies par dublējumiem un atjaunošanu jūsu vietā.

Couchbase piegādā komandrindas rīkus, lai dublētu datus no dažādiem pakalpojumiem, un tos var konfigurēt, lai palaistu pilnīgas dublējumkopijas vai divu veidu papildu dublējumus. Papildu dublējumkopijas var būt vai nu pieaugošas no pēdējās pilnās dublējuma (kumulatīvās inkrementālās), vai arī pieaugošās no jebkāda veida pēdējās dublējuma (diferenciālās inkrementālās). Tas ļauj izveidot sarežģītas rezerves struktūras, kurām nepieciešama dažāda līmeņa krātuve un kas saistīta ar dažādu līmeņu atjaunošanas sarežģītību.

Uzņēmumu klienti var izmantot utilītu cbbackupmgr, kas izmanto dažādas pamatā esošās datu struktūras, lai sasniegtu labāku veiktspēju datu dublējumā.

Kārtas uzvarētājs: Couchbase, pateicoties lielākai elastībai un atbalstam papildu dublējumkopijām.

Jaunināšana

Ilgstoši darbojošam klasterim vajadzētu būt skaidram, vienkāršam jaunināšanas ceļam. Jo grūtāk ir jaunināt, jo mazāk ticams, ka tas tiks atjaunināts. Tas nozīmē, ka gan izstrādātāji, gan administratori palaidīs garām jaunas funkcijas.

MongoDB jauninājumus vislabāk var saprast no kopijas iestatītā līmeņa. Ja izmantojat sadalītu kopu, lielākoties veicat katras lauskas kopiju kopu jaunināšanas darbības. Replikas komplektā katrs sekundārais tiek izslēgts, jaunināts vietā un palaista. Kad sekundārie aparāti ir darbojušies un saskan ar primārajiem, tiek sākta kļūme, un iepriekšējo primāro var noņemt un uzlabot. Tas atkal tiks palaists kā sekundārs un sasniegs rakstus, kurus tā palaida bezsaistē. Tādējādi jauninājumi pārsvarā ir tiešsaistes process, taču primārā kļūme, visticamāk, nerakstīs 10 līdz 20 sekundes, tāpēc ir nepieciešams uzturēšanas logs ar pieņemamu dīkstāvi.

Couchbase pieeja jauninājumiem notiek tāpat, kā jūs pievienotu vai noņemtu mezglu no kopas. Visi jaunināšanas mezgla dati ir jālīdzsvaro visā klasterī, pēc tam atkal jābalansē, kad jaunināšana ir pabeigta un mezgls atkal pievienojas kopai. Šim līdzsvarošanas procesam jānotiek katram klastera mezglam viens pēc otra. Tas aizņems daudz vairāk laika nekā MongoDB kopas jaunināšana visu datu dēļ, kas jāpārvieto apkārt. Vēl viena iespēja ir padarīt visu kopu bezsaistē, jaunināt katru mezglu un atkal tos visus savienot tiešsaistē.

Kaut arī Couchbase jaunināšanas ceļam nav nepieciešams dīkstāves laiks, process ir ilgs un darbam nepieciešams daudz datu sajaukšanas.

Kārtas uzvarētājs: Kaklasaite. Tiebreaker: Ja tehniskās apkopes dīkstāves laiks ir pieņemams, tad uzvar MongoDB. Ja nē, tad Couchbase ir vienīgā izvēle.

Uzraudzība

Redzamība darbojas klasterī ir acīmredzami būtiska veiksmīgai datu bāzes administrēšanai. Kad viss notiek nepareizi, nekas nav sliktāks par ierobežota skata uz patiesību kopā.

MongoDB čaulā piedāvā CLI rīkus un komandas, kas nodrošina metriku par instances aktivitāti un veiktspēju. Papildus tam MongoDB jums palīdzēs ar trešo personu rīkiem vai saviem uzņēmuma produktiem (Cloud Manager, Ops Manager, Atlas).

No otras puses, Couchbase piegādā tīmekļa interfeisu, kas ietver statistiku un vizualizācijas gadījumiem, mezgliem, vaicājumu veiktspēju un daudz ko citu. Turklāt Couchbase var konfigurēt, lai nosūtītu brīdinājumus pa e-pastu, kad noteikta statistika ir ārpus diapazona.

Kārtas uzvarētājs: Couchbase, kas paredzēts vizualizēšanai un brīdināšanai ārpus izvēles.

Lietošanas ērtums

Pēc datubāzes izveides un visu mūsu administrācijas vajadzību apmierināšanas galvenā problēma pāriet no darbībām uz lietošanu. Es to sadalīšu līdz datu modelēšanai, indeksa noformēšanai, pamata vaicājumiem un apkopošanai.

Datu modelēšana

Kā dokumentu datu bāzes ne MongoDB, ne Couchbase nevar izvairīties no izaicinājuma, kā rīkoties ar relāciju datiem. Abas piedāvā iespēju glabāt relāciju datus kā ligzdotus, denormalizētus datus, kā arī atsauču veidā uz citiem augstākā līmeņa dokumentiem. Šī pieeja datu glabāšanai galu galā ir abu datu bāzu datu modelēšanas galvenais apsvērums, neskatoties uz to, ka katra no tām atbalsta arvien plašākus lietojuma gadījumus, funkcijas un vaicājumu modeļus.

Kārtas uzvarētājs: Kaklasaite.

Indeksa dizains

Indeksi dokumentu datu bāzēs pilda to pašu funkciju kā relāciju datu bāzēs. Tas ir, tie atspoguļo noteiktus datus efektīvākos veidos, lai uzlabotu vaicājumu veiktspēju. MongoDB un Couchbase izmanto ļoti atšķirīgu pieeju indeksa veidošanai un izveidei.

MongoDB atbalsta indeksa izveidi vienam vai vairākiem dokumenta laukiem, ļaujot norādīt standarta indeksu secību un virzienu (augšupejošu vai dilstošu). Tās pašas sintakses ietvaros ir iespējams iekļaut arī īpašus ģeotelpiskos indeksus un pilna teksta indeksus. Vaicājumu dzinējs pieprasījumu paātrināšanai izmantos šos indeksus, šo indeksu prefiksus vai vairāku indeksu kombināciju.

Couchbase balstās uz diviem dažādiem mehānismiem, lai uzlabotu vaicājumu veiktspēju: MapReduce skati un globālais sekundārais indekss (GSI). MapReduce skati sastāv no lietotāja definēta JavaScript koda, kas apstrādā datus, kad tie iet caur sistēmu, piemēram, pakāpeniska iepriekšēja apkopošana. MapReduce skati var būt tik vienkārši, kā atļaut dokumentu meklēšanu iekšējā laukā, vai arī tie var ietvert sarežģītāku loģiku, kas veic aprēķinus un apkopojumus dokumentos esošajiem datiem.

MapReduce rakstīšana JavaScript, lai atbalstītu vaicājumus, ir diezgan apgrūtinoša, tāpēc parasti vēlaties izmantot GSI, kur iespējams. Indeksi GSI tiek aprakstīti, izmantojot N1QL (izrunā “niķelis”), daļēju SQL ieviešanu virs Couchbase. N1QL sintakse ir diezgan skaidra, un N1QL vaicājumi ir daudz labāki nekā MapReduce, taču indekss ir jāievieto noteiktā mezglā. Ja vēlaties, lai indekss būtu ļoti pieejams, šis indekss ir jāizveido manuāli vairāk nekā vienā mezglā.

Kārtas uzvarētājs: MongoDB par konsolidēto indeksēšanas API un spēju vispār izvairīties no MapReduce.

Pamata jautājumi

Ņemot vērā atbilstošu datu modeli, vairums vaicājumu uz datu bāzi mēdz būt vienkārši. Papildus CRUD operācijām, kurās ir zināms attiecīgā dokumenta ID, ir svarīgi spēt izteikt dažādus dokumentu filtrēšanas veidus un izvēlēties, kuri lauki mūs interesē.

MongoDB apraksta vaicājumus JSON, nodrošinot deklaratīvu sintaksi, lai norādītu apstākļus un filtrus laukos. Vaicājuma dokuments var sastāvēt no jebkura veida vaicājumu atlasītājiem, kas apraksta to, kādai vajadzētu būt rezultātu kopai. Šajā vaicājuma dokumentā var definēt diapazonus, vienlīdzību, teksta meklēšanu un ģeotelpiskos vaicājumus. Dokuments atbalsta Būla operatorus, tāpēc loģiski var savienot vairākus vaicājuma klauzulas ar UN, VAI, un tā tālāk. Vaicājuma dokuments var ātri izaugt par ļoti ligzdotu JSON dokumentu, kas dažkārt var būt milzīgs un pie kura noteikti jāpierod. Arī vaicājumos ir iespējams izmantot projekcijas, kas ļauj atgriezt tikai jums svarīgos laukus un samazināt vadu kopējo rezultātu lielumu.

$config[zx-auto] not found$config[zx-overlay] not found