Programiranje

MongoDB, Cassandra in HBase - tri zbirke podatkov NoSQL za ogled

Hadoop dobi velik del kredita za velike podatke, v resnici pa je, da so zbirke podatkov NoSQL veliko bolj razširjene - in veliko širše razvite. Dejansko je sicer nakupovanje prodajalca Hadoop razmeroma preprosto, izbira baze podatkov NoSQL pa vse prej kot. Kot navsezadnje obstaja več kot 100 baz podatkov NoSQL, kot kaže razvrstitev baze podatkov DB-Engines.

Katero naj izberete?

Razvajen za izbiro

Ker izbrati moraš. Kolikor lepo bi bilo živeti v srečni utopiji tako imenovane poliglotske vztrajnosti, "kjer bo vsako dostojno veliko podjetje imelo različne tehnologije za shranjevanje podatkov za različne vrste podatkov," kot trdi Martin Fowler, je resničnost ne morete si privoščiti vlaganja v učenje več kot le nekaj.

Na srečo je izbira vse lažja, saj se trg združi okoli treh prevladujočih baz podatkov NoSQL: MongoDB (podprl ga je moj nekdanji delodajalec), Cassandra (razvila jo je predvsem DataStax, čeprav se je izlegla na Facebooku) in HBase (tesno usklajena s Hadoop-om in razvita s strani ista skupnost).

Upoštevajte, da Redisa s tega seznama namenoma izključujem. Čeprav je odlična shramba podatkov, se v glavnem uporablja za predpomnjenje podatkov in ni primerna za široko paleto delovnih obremenitev.

Podatki LinkedIn iz raziskave 451 kažejo, kako trg gravitira MongoDB, Cassandri in HBase:

To so podatki o profilu LinkedIn. Popolnejši pogled je DB-Engines ', ki združuje delovna mesta, iskanje in druge podatke za razumevanje priljubljenosti baze podatkov. Medtem ko kraljujejo Oracle, SQL Server in MySQL, jim MongoDB (št. 5), Cassandra (št. 9) in HBase (št. 15) ponujajo denar.

Čeprav je prezgodaj, da bi vsako drugo bazo podatkov NoSQL označili za napako pri zaokroževanju, hitro dosežemo to točko, natanko tako kot se je zgodilo na trgu relacijskih baz podatkov.

Da bi bolje razumel, zakaj svetijo te tri zbirke podatkov, sem predstavnike obeh prosil, naj opredelijo ključne lastnosti za njihov uspeh: Kelly Stirman, direktorica izdelkov pri MongoDB; Patrick McFadin, glavni evangelist Cassandre pri DataStaxu; in Justin Kestelyn, višji direktor odnosov z razvijalci pri Cloudera.

Najprej pa moramo razumeti, zakaj je NoSQL pomemben.

Svet, zgrajen z nestrukturiranimi podatki

Vse bolj živimo v svetu, kjer se podatki ne ujemajo lepo v urejene vrstice in stolpce RDBMS. Mobilno, družabno in računalništvo v oblaku je ustvarilo množično poplavo podatkov. Po različnih ocenah je bilo v zadnjih dveh letih ustvarjenih 90 odstotkov svetovnih podatkov, pri čemer je Gartner kot nestrukturirane vezal 80 odstotkov vseh podatkov podjetja. Še več, nestrukturirani podatki rastejo dvakrat hitreje kot strukturirani podatki.

Ker se svet spreminja, zahteve glede upravljanja podatkov presegajo dejanski obseg tradicionalnih relacijskih baz podatkov. Prve organizacije, ki so opazile potrebo po alternativnih rešitvah, so bili spletni pionirji, vladne agencije in podjetja, specializirana za informacijske storitve.

Podjetja z vsemi črtami si zdaj vse bolj želijo izkoristiti prednosti alternativ, kot sta NoSQL in Hadoop: NoSQL za izdelavo operativnih aplikacij, ki njihovo poslovanje vodijo skozi sisteme sodelovanja, in Hadoop za izdelavo aplikacij, ki analizirajo njihove podatke za nazaj in pomagajo pridobiti močne vpoglede .

MongoDB: Od razvijalcev, za razvijalce

Med možnostmi NoSQL, poudarja Stirman iz MongoDB, si je MongoDB prizadeval za uravnotežen pristop, primeren za najrazličnejše aplikacije. Čeprav je funkcionalnost blizu tradicionalni relacijski bazi podatkov, MongoDB omogoča uporabnikom, da s svojo vodoravno prilagodljivostjo izkoristijo prednosti infrastrukture v oblaku in enostavno delujejo z različnimi nabori podatkov, ki se danes uporabljajo, zahvaljujoč prilagodljivemu podatkovnemu modelu.

MongoDB je pogosto prvi, ki ga bodo poskusili razvijalci baz podatkov NoSQL, ker je tako enostaven za učenje. Will Shulman, izvršni direktor MongoLab (ponudnik storitev MongoDB-as-a-a-a-service), pravi takole:

Nesorazmeren uspeh MongoDB v veliki meri temelji na njegovi inovaciji kot shrambi podatkovne strukture, ki nam omogoča lažje in ekspresivnejše modeliranje "stvari" v središču naših aplikacij ....

Imeti enak osnovni podatkovni model v naši kodi in v bazi podatkov je vrhunska metoda za večino primerov uporabe, saj močno poenostavi nalogo razvoja aplikacij in odstrani plasti zapletene preslikavne kode, ki so sicer potrebne.

MongoDB, tako kot druge zbirke podatkov na tem seznamu, ni ponik z enim trikom. Podjetja, ki se učijo MongoDB, "lahko amortizirajo svoje naložbe v MongoDB v mnogih, mnogih projektih, zaradi česar je eden od ožjih seznamov standardov, na katere se zanašajo pri vsem upravljanju podatkov," kot mi je povedal Stirman.

Kot vsaka tehnologija ima tudi MongoDB svoje prednosti in slabosti. MongoDB je zasnovan za delovne obremenitve OLTP. Lahko izvaja zapletene poizvedbe, vendar ni nujno, da je najbolj primerna za obremenitve v slogu poročanja. Če pa potrebujete zapletene transakcije, to ne bo dobra izbira. Vendar preprostost MongoDB omogoča odličen začetek.

Cassandra: varno teči v merilu

Obstajata vsaj dve vrsti enostavnosti zbirke podatkov: enostavnost razvoja in enostavnost delovanja. Medtem ko MongoDB upravičeno dobi zaslugo za enostavno izkušnjo, Cassandra zasluži polne ocene za enostavno upravljanje v obsegu.

Kot mi je povedal McFadin iz DataStaxa, uporabniki ponavadi gravitirajo k Kasandri, bolj ko se zaletavajo v težave, da bi bile relacijske baze podatkov hitrejše in zanesljivejše, zlasti v obsegu. McFadin, nekdanji Oracle DBA, je z navdušenjem ugotovil, da sta "replikacija in linearno skaliranje primitivno" pri Cassandri, funkcije pa so bile "glavni cilj oblikovanja od začetka."

V svetu RDBMS so funkcije baze podatkov, kot sta skaliranje in kopiranje, trdi deli, ki jih lahko prepustite uporabniku. V včerajšnjem podjetju je to dobro delovalo, ko obseg ni bil velika težava. Danes to hitro postaja težava.

Kot sem slišal od McFadina in drugih, Cassandra še posebej blesti pri uvajanju obsega. Cassandra ima vgrajeno podporo za več podatkovnih centrov. Kar zadeva dodajanje zmogljivosti grozdu, "preprosto zaženete nov stroj in povejte Cassandri, kje so druga vozlišča," je dejal McFadin, "in poskrbi za ostalo."

Ta enostavnost skaliranja, skupaj z izjemno zmogljivostjo pisanja (»Vse, kar počnete, je dodajanje na konec dnevniške datoteke«) in predvidljivo zmogljivost poizvedb, predstavljata visoko zmogljiv delovni konj v Cassandri.

Eden od člankov v veri NoSQL, ki ga že dolgo držim, je, da je Cassandra sicer lahko močna, vendar za začetek zahteva doktorat. Ni tako, McFadin je vztrajal:

Poti kopiranja ter branja in pisanja so namensko enostavne. Osrednje notranjosti Cassandre se lahko naučite v nekaj urah. To lahko prinese veliko zaupanja, ko uvajate novo tehnologijo, saj je manj podrobnosti o "črni škatli", ki uvajajo zapletene načine odpovedi.

To pomeni, da je cena za sprejem v učinkovit razvoj Cassandre v razumevanju podatkovnega modela in kako bo deloval z vašo aplikacijo. Glede na poznavanje Cassandrinega jezika poizvedb CQL (ki naj bi bil "popolnoma takšen kot SQL, razen kadar ni"), je McFadin dejal, da to ni strma krivulja učenja.

Še pomembneje, rekel mi je: “Cassandra te nagradi z eno stvarjo, ki jo želiš od baze podatkov: brez drame. Zato uporabniki radi uporabljajo Cassandro. "

HBase: Prijatelji s Hadoopom

HBase, tako kot Cassandra, v stolpec usmerjeno shrambo ključ-vrednost, se veliko uporablja zaradi skupnega rodovnika s Hadoopom. Kot je dejal Clouderov Kestelyn, "HBase zagotavlja sloj za shranjevanje na osnovi zapisov, ki omogoča hitro, naključno branje in zapisovanje podatkov, dopolnjuje Hadoop s poudarkom na visoki pretočnosti na račun V / I z majhno zakasnitvijo."

Kestelyn nadaljuje:

Spremembe se učinkovito katalogizirajo v pomnilniku, da se doseže največji dostop, medtem ko se podatki ohranijo v HDFS. Ta zasnova omogoča EDH, ki temelji na Hadoop-u, [podatkovno vozlišče podjetja], da v realnem času prikazuje naključna branja in zapisovanja uporabnikom in aplikacijam, vendar še vedno uživa odpornost na napake in trajnost HDFS.

Sorodnost s Hadoop-om ni edini razlog, da se HBase stalno povečuje na lestvici priljubljenosti zbirke podatkov, čeprav je to morda dovolj. Podobno kot Cassandra, so HBase-ove korenine kot odprtokodna izvedba Googlovega Bigtablea prevedene v bazo podatkov zelo prilagodljive po zasnovi.

Ker lahko izkoristi pomnilnik, pomnilnik in vire CPU poljubnega števila strežnikov, poleg tega pa ima tudi funkcije za zmanjševanje, kot je samodejno ostrenje, lahko HBase neomejeno meri, saj se zahteve po obremenitvi in ​​zmogljivosti povečajo zgolj z dodajanjem strežniških vozlišč. HBase je bil zasnovan od začetka do optimalne učinkovitosti, kadar je doslednost ključnega pomena.

Toda obseg ni le koristnost. Kot je opozoril Kestelyn, »zahvaljujoč tesni integraciji s preostalim ekosistemom Hadoop so podatki na voljo uporabnikom in aplikacijam prek poizvedb SQL (z uporabo Cloudera Impala, Apache Phoenix ali Apache Hive) ali celo s fasetiranim iskanjem prostega besedila (z uporabo Cloudera Search). " Tako HBase razvijalcem omogoča, da izkoristijo obstoječe znanje s področja SQL, hkrati pa gradijo na sodobnejši, porazdeljeni bazi podatkov.

Vsaka zbirka podatkov ima svoje prednosti in pomanjkljivosti, vendar je vsaka od treh tukaj profiliranih zapolnila veliko luknjo na področju velikih podatkov. Čeprav je mogoče, da bo prišla nova baza podatkov, ki bo zahtevala mesto med prvimi tremi NoSQL (DynamoDB?), Je resničnost, da razvijalci in podjetja, ki jim služijo, že standardizirajo nekaj močnih možnosti: MongoDB, Cassandra in HBase.

Matt Asay, ki je zdaj podpredsednik družbe Mobile za Adobe, je bil prej podpredsednik skupnosti pri MongoDB, Inc. Je zaslužni član upravnega odbora Open Source Initiative (OSI) in doktoriral na Stanfordu, kjer se je osredotočil na odprtokodne in druge vprašanja licenciranja intelektualne lastnine, magisterij z univerze v Kentu v Canterburyju in dodiplomski študij z univerze Brigham Young. Asay je bil eden prvih blogerjev.

Forum New Tech ponuja prizorišče za raziskovanje in razpravo o nastajajoči podjetniški tehnologiji v globini in širini brez primere. Izbor je subjektiven in temelji na našem izboru tehnologij, za katere menimo, da so pomembne in najbolj zanimajo bralce. ne sprejema tržnih zavarovanj za objavo in si pridržuje pravico do urejanja celotne prispevane vsebine. Vsa vprašanja pošljite na [email protected].

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