Programmēšana

MongoDB, Cassandra un HBase - trīs skatāmās NoSQL datu bāzes

Hadoops saņem lielu daļu no lielo datu kredīta, taču realitāte ir tāda, ka NoSQL datubāzes tiek izvietotas daudz plašāk - un daudz plašāk. Patiesībā, lai gan iepirkšanās pie Hadoop pārdevēja ir samērā vienkārša, NoSQL datu bāzes izvēle ir nekas cits. Galu galā ir vairāk nekā 100 NoSQL datu bāzes, kā liecina DB-Engines datu bāzes popularitātes rangs.

Kuru jums vajadzētu izvēlēties?

Bojāta pēc izvēles

Jo izvēlēties jums ir. Lai cik patīkami būtu dzīvot laimīgā tā dēvētās poliglotu noturības utopijā, “kur jebkuram pienācīga lieluma uzņēmumam būs dažādas datu glabāšanas tehnoloģijas dažādu veidu datiem”, kā apgalvo Martin Fowler, realitāte ir jūs nevarat atļauties ieguldīt vairāk nekā dažu mācībās.

Par laimi, izvēle kļūst vieglāka, jo tirgus saplūst ap trim dominējošām NoSQL datu bāzēm: MongoDB (kuru atbalsta mans bijušais darba devējs), Cassandra (galvenokārt izstrādājusi DataStax, kaut arī izšķīlušies Facebook) un HBase (cieši saskaņota ar Hadoop un izstrādājusi tā pati kopiena).

Ņemiet vērā, ka es mērķtiecīgi izslēdzu Redisu no šī saraksta. Lai gan tas ir lielisks datu krājums, tas galvenokārt tiek izmantots kešatmiņā un nav piemērots plaša spektra darba slodzēm.

LinkedIn dati no 451 pētījuma parāda, kā tirgus gravitējas uz MongoDB, Cassandra un HBase:

Tie ir LinkedIn profila dati. Pilnīgāks skats ir DB-Engines, kas apkopo darbavietas, meklēšanu un citus datus, lai izprastu datu bāzes popularitāti. Kamēr Oracle, SQL Server un MySQL valda visaugstāk, MongoDB (nr. 5), Cassandra (Nr. 9) un HBase (Nr. 15) liek viņiem palaist naudu.

Lai gan ir pāragri katru otro NoSQL datu bāzi saukt par noapaļošanas kļūdu, mēs ātri sasniedzam šo punktu, tieši tā, kā tas notika relāciju datu bāzu tirgū.

Lai labāk saprastu, kāpēc šīs trīs datubāzes spīd, es aicināju katras puses pārstāvjus identificēt galvenos viņu panākumu atribūtus: Kellija Stirmane, MongoDB produktu direktore; Patriks Makfadins, galvenais Kasandras evaņģēlists no DataStax; un Džastins Kestelins, Cloudera izstrādātāju attiecību vecākais direktors.

Bet vispirms mums jāsaprot, kāpēc NoSQL ir svarīga.

Pasaule, kas veidota ar nestrukturētiem datiem

Mēs arvien vairāk dzīvojam pasaulē, kur dati labi neiederas kārtīgās RDBMS rindās un kolonnās. Mobilā, sociālā un mākoņdatošana ir radījusi milzīgu datu plūdu. Saskaņā ar dažādām aplēsēm 90 procenti pasaules datu ir izveidoti pēdējos divos gados, Gartner piesaistot 80 procentus no visiem uzņēmuma datiem kā nestrukturētus. Turklāt nestrukturētie dati pieaug divkāršojot strukturēto datu ātrumu.

Mainoties pasaulei, datu pārvaldības prasības pārsniedz tradicionālo relāciju datu bāzu efektīvo darbības jomu. Pirmās organizācijas, kas novēroja vajadzību pēc alternatīviem risinājumiem, bija tīmekļa pionieri, valsts aģentūras un uzņēmumi, kas specializējušies informācijas pakalpojumos.

Tagad arvien vairāk dažādu kategoriju uzņēmumi vēlas izmantot tādu alternatīvu priekšrocības kā NoSQL un Hadoop: NoSQL, lai izveidotu operatīvas lietojumprogrammas, kas veicina viņu biznesu, izmantojot iesaistes sistēmas, un Hadoop, lai izveidotu lietojumprogrammas, kas retrospektīvi analizē savus datus un palīdz sniegt spēcīgu ieskatu .

MongoDB: no izstrādātājiem, izstrādātājiem

Starp NoSQL iespējām MongoDB Stirman norāda, ka MongoDB mērķis ir līdzsvarota pieeja, kas piemērota visdažādākajām lietojumprogrammām. Kaut arī funkcionalitāte ir tuvu tradicionālās relāciju datu bāzes funkcionalitātei, MongoDB ļauj lietotājiem gūt labumu no mākoņu infrastruktūras priekšrocībām ar tās horizontālo mērogojamību un viegli strādāt ar daudzveidīgajām datu kopām, kas šodien tiek izmantotas, pateicoties tā elastīgajam datu modelim.

MongoDB bieži ir pirmais, ko izmēģinās NoSQL datu bāzes izstrādātāji, jo to ir tik viegli iemācīties. Vils Šulmans, MongoLab (MongoDB kā pakalpojumu sniedzēja) izpilddirektors, saka to šādā veidā:

MongoDB nesamērīgie panākumi lielā mērā ir balstīti uz tā jauninājumiem kā datu struktūras krātuvi, kas ļauj mums vieglāk un izteiksmīgāk modelēt lietojumprogrammu centrā esošās lietas….

Tā kā mūsu kodā un datu bāzē ir viens un tas pats pamatdatu modelis, lielākajā daļā izmantošanas gadījumu ir pārāka metode, jo tas ievērojami vienkāršo lietojumprogrammu izstrādes uzdevumu un novērš sarežģītā kartēšanas koda slāņus, kas citādi ir nepieciešami.

Īpaši jāatzīmē, ka MongoDB, tāpat kā citas šajā sarakstā esošās datu bāzes, nav viena trika ponijs. Uzņēmumi, kas apgūst MongoDB, “var amortizēt savus ieguldījumus MongoDB daudzos, daudzos projektos, padarot to par vienu no īsajiem standartu sarakstiem, uz kuriem viņi paļaujas visā datu pārvaldībā”, kā man teica Stirmans.

Protams, tāpat kā jebkurai tehnoloģijai, arī MongoDB ir savas stiprās un vājās puses. MongoDB ir paredzēts OLTP slodzēm. Tas var veikt sarežģītus vaicājumus, taču tas ne vienmēr ir vispiemērotākais pārskatu stila darba slodzēm. Vai arī, ja jums ir nepieciešami sarežģīti darījumi, tā nebūs laba izvēle. Tomēr MongoDB vienkāršība padara to par lielisku sākumu.

Kasandra: Droši brauciet mērogā

Ir vismaz divu veidu datu bāzes vienkāršība: izstrādes vienkāršība un darbības vienkāršība. Kamēr MongoDB pamatoti saņem atzinību par vieglu pieredzi, kas nav pieejama, Cassandra nopelna pilnas atzīmes par to, ka to ir viegli pārvaldīt mērogā.

Kā man teica DataStax McFadin, lietotāji mēdz pievērsties Kasandrai, jo vairāk viņi sit galvu pret grūtībām padarīt ātrāku un uzticamāku relāciju datu bāzes, īpaši mērogā. Bijušais Oracle DBA, McFadin bija pacilāts, lai atklātu, ka Cassandra "replikācija un lineārā mērogošana ir primitīvas", un iezīmes bija "galvenais dizaina mērķis no paša sākuma".

RDBMS pasaulē datu bāzes funkcijas, piemēram, mērogošana un replikācija, ir lietotājam atstātās cietās daļas. Tas labi darbojās vakardienas uzņēmumā, kad mērogs nebija liela problēma. Šodien tas ātri kļūst izdevums.

Kā dzirdēju no Makfadina un citiem, Kasandra īpaši spīd izvērstās izvietošanas vietās. Cassandra nāk ar izceptu atbalstu vairākiem datu centriem. Kas attiecas uz jaudas palielināšanu klasterim: "Jūs vienkārši palaižat jaunu mašīnu un pasakāt Kasandrai, kur atrodas citi mezgli," sacīja Makfadins, "un tā rūpējas par pārējo."

Šī mērogošanas vienkāršība kopā ar izcilu rakstīšanas veiktspēju (“Viss, ko jūs darāt, ir pievienots žurnāla faila beigām”) un paredzama vaicājumu veiktspēja, kopā ar augstas veiktspējas darba zirgu Kasandrā.

Viens NoSQL ticības raksts, kuru es jau sen turēju, ir tāds, ka Kasandra var būt apjomīga, taču, lai sāktu darbu, ir nepieciešams doktora grāds. Ne tā, Makfadins uzstāja:

Replikācijas, kā arī lasīšanas un rakstīšanas ceļi ir mērķtiecīgi vienkārši. Dažu stundu laikā varat uzzināt Kasandras galvenos iekšējos elementus. Tas var radīt daudz pārliecības, ieviešot jauno tehnoloģiju, jo ir mazāk “melnās kastes” detaļu, kas ievieš sarežģītus atteices režīmus.

Tas nozīmē, ka cena par efektīvu Cassandra izstrādi ir izpratne par datu modeli un kā tas darbosies ar jūsu lietojumprogrammu. Ņemot vērā Kasandras CQL vaicājumu valodas pārzināšanu (domāta kā "tieši tāda pati kā SQL, izņemot gadījumus, kad tā nav"), Makfadins sacīja, ka tā nav strauja mācīšanās līkne.

Vēl svarīgāk, viņš man teica: “Kasandra apbalvo jūs ar vienu lietu, ko vēlaties no datu bāzes: bez drāmas. Tāpēc lietotājiem patīk izmantot Kasandru. ”

HBase: Bosoma draugi ar Hadoopu

HBase, tāpat kā Cassandra, kolonnu orientēts atslēgu vērtību veikals, lielā mērā tiek izmantots daudz, jo tā ir kopēja ciltsgrāmata ar Hadoop. Patiešām, kā izteicās Cloudera Kestelyn, "HBase nodrošina uz ierakstiem balstītu glabāšanas slāni, kas ļauj ātri, nejauši izlasīt un ierakstīt datus, papildinot Hadoop, uzsverot lielu caurlaides spēju uz zemas latentuma I / O rēķina."

Kestelyn turpina:

Izmaiņas tiek efektīvi katalogētas atmiņā, lai sasniegtu maksimālu piekļuvi, kamēr dati tiek saglabāti HDFS. Šis dizains ļauj Hadoop bāzētam EDH [uzņēmuma datu centram] reālā laikā apkalpot izlases lasījumus un rakstīšanu lietotājiem un lietojumprogrammām, tomēr baudot HDFS kļūdu toleranci un izturību.

Interese ar Hadoop nav vienīgais iemesls, kāpēc HBase turpina pieaugt datubāzu popularitātes rindās, lai gan tas varētu būt pietiekami. Līdzīgi kā Cassandra, HBase saknes kā Google Bigtable atvērtā pirmkoda ieviešana nozīmē, ka datu bāze ir ļoti pielāgojama pēc konstrukcijas.

Tā kā HBase var izmantot jebkura servera skaita, atmiņas un centrālā procesora resursus, kā arī tam ir paplašināšanas funkcijas, piemēram, automātiska sadalīšana, HBase var neierobežoti mērogot, jo slodzes un veiktspējas prasības palielinās, vienkārši pievienojot servera mezglus. HBase tika izstrādāta no paša sākuma, lai nodrošinātu optimālu veiktspēju, ja konsekvence ir kritiska.

Bet mērogs nav tikai lietderība. Kā atzīmēja Kestelīna, “Pateicoties ciešajai integrācijai ar pārējo Hadoop ekosistēmu, dati lietotājiem un lietojumprogrammām ir viegli pieejami, izmantojot SQL vaicājumus (izmantojot Cloudera Impala, Apache Phoenix vai Apache Hive) vai pat vienkāršu brīvā teksta meklēšanu (izmantojot Cloudera meklēšana). ” Tādējādi HBase dod izstrādātājiem iespēju izmantot esošo pieredzi SQL, vienlaikus balstoties uz modernāku, izplatītāku datu bāzi.

Katrai datu bāzei ir savas stiprās puses un trūkumi, taču katrs no trim šeit aprakstītajiem ir aizpildījis lielu robu lielo datu ainavā. Lai gan ir iespējams, ka nāk jauna datu bāze, kas pretendēs uz vietu NoSQL pirmajā trijniekā (DynamoDB?), Realitāte ir tāda, ka izstrādātāji un uzņēmumi, kurus viņi apkalpo, jau standartizējas uz dažām spēcīgām iespējām: MongoDB, Cassandra un HBase.

Tagad Adobe mobilo sakaru viceprezidents Mets Asajs iepriekš bija MongoDB, Inc. kopienas viceprezidents. Viņš ir atvērtā pirmkoda iniciatīvas (OSI) valdes emeritus loceklis un ieguvis jurisprudences doktora grādu Stenfordā, kur koncentrējās uz atvērto pirmkoda un citiem jautājumiem. intelektuālā īpašuma licencēšanas jautājumi, kā arī viņa maģistra grāds Kentas Universitātē Kenterberijā un bakalaura grāds Brigamas Janga universitātē. Asay bija viens no pirmajiem emuāru autoriem.

Jauno tehnoloģiju forums nodrošina vietu, kur bezprecedenta dziļumā un plašumā izpētīt un pārrunāt topošās uzņēmuma tehnoloģijas. Izvēle ir subjektīva, balstoties uz mūsu izvēlētajām tehnoloģijām, kuras, mūsuprāt, ir svarīgas un interesē lasītājus. nepieņem mārketinga nodrošinājumu publicēšanai un patur tiesības rediģēt visu ieguldīto saturu. Nosūtiet visus jautājumus uz [email protected].

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