Hadoop får mye av stordatakreditten, men realiteten er at NoSQL-databaser er langt bredere distribuert - og langt bredere utviklet. Faktisk, mens det å handle for en Hadoop-leverandør er relativt greit, er det å velge en NoSQL-database alt annet enn. Det er tross alt over 100 NoSQL-databaser, som DB-Engines popularitetsrangering viser.
Hvilket bør du velge?
Bortskjemt for valg
Fordi velge du må. Så fint som det kan være å leve i en lykkelig utopi av såkalt polyglot-utholdenhet, "hvor ethvert anstendig selskap vil ha en rekke forskjellige datalagringsteknologier for forskjellige typer data," som Martin Fowler hevder, er virkeligheten du har ikke råd til å investere i å lære mer enn noen få.
Heldigvis blir valget enklere ettersom markedet samles rundt tre dominerende NoSQL-databaser: MongoDB (støttet av min tidligere arbeidsgiver), Cassandra (først og fremst utviklet av DataStax, men klekket ut på Facebook) og HBase (nært tilpasset Hadoop og utviklet av samme samfunn).
Merk at jeg målrettet ekskluderer Redis fra denne listen. Selv om det er en flott datalager, brukes den primært til hurtigbufring av data og er ikke godt egnet for et bredt utvalg av arbeidsbelastninger.
LinkedIn-data fra 451 Research viser hvordan markedet trekker til MongoDB, Cassandra og HBase:
Det er LinkedIn-profildata. En mer fullstendig oversikt er DB-Engines ', som samler jobber, søk og andre data for å forstå databasens popularitet. Mens Oracle, SQL Server og MySQL troner øverst, gir MongoDB (nr. 5), Cassandra (nr. 9) og HBase (nr. 15) dem løp for pengene sine.
Selv om det er for tidlig å kalle hver annen NoSQL-database for en avrundingsfeil, når vi raskt det punktet, akkurat som skjedde i det relasjonelle databasemarkedet.
For å bedre forstå hvorfor disse tre databasene skinner, ba jeg representanter fra hver om å identifisere viktige attributter for deres suksess: Kelly Stirman, direktør for produkter i MongoDB; Patrick McFadin, sjef Cassandra-evangelist i DataStax; og Justin Kestelyn, seniordirektør for utviklerrelasjoner i Cloudera.
Men først må vi forstå hvorfor NoSQL betyr noe.
En verden bygget med ustrukturerte data
Vi lever i økende grad i en verden der data ikke passer fint inn i de ryddige radene og kolonnene i en RDBMS. Mobil, sosial og cloud computing har skapt en massiv flom av data. I følge en rekke estimater ble 90 prosent av verdens data opprettet de siste to årene, med Gartner knyttet 80 prosent av alle bedriftsdata som ustrukturert. I tillegg vokser ustrukturerte data med dobbelt så høy hastighet som strukturerte data.
Når verden endrer seg, stiger kravene til datastyring utover det effektive omfanget av tradisjonelle relasjonsdatabaser. De første organisasjonene som observerte behovet for alternative løsninger var nettpionerer, offentlige etater og selskaper som spesialiserer seg på informasjonstjenester.
I økende grad ønsker selskaper av alle striper å dra nytte av fordelene med alternativer som NoSQL og Hadoop: NoSQL for å bygge operasjonelle applikasjoner som driver deres virksomhet gjennom engasjementsystemer, og Hadoop for å bygge applikasjoner som analyserer dataene i ettertid og hjelper med å levere kraftig innsikt .
MongoDB: Av utviklerne, for utviklerne
Blant NoSQL-alternativene, påpeker MongoDBs Stirman, at MongoDB har siktet mot en balansert tilnærming som passer til et bredt spekter av applikasjoner. Mens funksjonaliteten er nær den for en tradisjonell relasjonsdatabase, tillater MongoDB brukere å utnytte fordelene med skyinfrastruktur med sin horisontale skalerbarhet og enkelt å jobbe med de forskjellige datasettene som er i bruk i dag takket være den fleksible datamodellen.
MongoDB er ofte de første NoSQL-databaseutviklerne vil prøve fordi det er så lett å lære. Will Shulman, administrerende direktør i MongoLab (en MongoDB-som-en-tjenesteleverandør), sier det slik:
Den uforholdsmessige suksessen til MongoDB er i stor grad basert på innovasjonen som en datastrukturbutikk som lar oss lettere og uttrykkelig modellere "tingene" i hjertet av applikasjonene våre ...
Å ha den samme grunnleggende datamodellen i koden vår og i databasen er den overlegne metoden for de fleste brukssaker, da det dramatisk forenkler oppgaven med applikasjonsutvikling, og eliminerer lagene med kompleks kartleggingskode som ellers er nødvendig.
Spesielt er MongoDB, som de andre databasene på denne listen, ikke en en-triks ponni. Bedrifter som lærer MongoDB “kan avskrive sine investeringer i MongoDB på tvers av mange, mange prosjekter, noe som gjør den til en kort liste over standarder de stoler på for all datahåndtering,” som Stirman fortalte meg.
Som enhver teknologi har MongoDB selvfølgelig sine styrker og svakheter. MongoDB er designet for OLTP-arbeidsbelastninger. Det kan gjøre komplekse spørsmål, men det passer ikke nødvendigvis best for rapportering av arbeidsmengder. Eller hvis du trenger komplekse transaksjoner, vil det ikke være et godt valg. Imidlertid gjør MongoDBs enkelhet det til et flott sted å starte.
Cassandra: Kjør trygt i målestokk
Det er minst to typer database enkelhet: utviklings enkelhet og operativ enkelhet. Mens MongoDB med rette får æren for en enkel opplevelse utenom boksen, tjener Cassandra full poeng for å være enkel å administrere i stor skala.
Som DataStax's McFadin fortalte meg, har brukere en tendens til å trekke seg til Cassandra jo mer de støter på hodet mot vanskeligheten med å gjøre relasjonsdatabaser raskere og mer pålitelige, spesielt i stor skala. En tidligere Oracle DBA, McFadin var begeistret for å oppdage at "replikering og lineær skalering er primitive" med Cassandra, og funksjonene var "det primære designmålet fra begynnelsen."
I RDBMS-verdenen er databasefunksjoner som skalering og replikering de harde delene som overlates til brukeren. Dette fungerte bra i gårsdagens virksomhet da skala ikke var et stort problem. I dag blir det raskt de utgave.
Som jeg hørte fra McFadin og andre, skinner Cassandra spesielt i utskalering. Cassandra kommer med innbakt støtte for flere datasentre. Når det gjelder å legge til kapasitet i en klynge, "Du starter ganske enkelt en ny maskin og forteller Cassandra hvor de andre nodene er," sa McFadin, "og den tar seg av resten."
Denne enkle skaleringen, kombinert med eksepsjonell skriveytelse ("Alt du gjør er å føye til slutten av en loggfil") og forutsigbar spørringsytelse, gir opp til en høyytelses arbeidshest i Cassandra.
En artikkel av NoSQL-tro jeg lenge har hatt, er at Cassandra kan være kraftig i skala, men det krever en doktorgrad for å komme i gang. Ikke det, insisterte McFadin:
Replikering og lese- og skriveveier er målrettet enkle. Du kan lære kjernen internt i Cassandra i løpet av få timer. Det kan gi mye selvtillit når du distribuerer ny teknologi fordi det er mindre "black box" -detaljer som introduserer komplekse feilmodus.
Dette betyr at prisen for opptak til effektiv Cassandra-utvikling ligger i å forstå datamodellen og hvordan den vil fungere med søknaden din. Gitt kjennskapen til Cassandras CQL-spørrespråk (ment å være "akkurat som SQL bortsett fra når det ikke er"), sa McFadin, det er ikke en bratt læringskurve.
Enda viktigere, fortalte han meg, “Cassandra belønner deg med den ene tingen du vil ha fra en database: ikke noe drama. Dette er grunnen til at brukere elsker å bruke Cassandra. ”
HBase: Brystkompiser med Hadoop
HBase, som Cassandra, en kolonneorientert nøkkelverdibutikk, får mye bruk i stor grad på grunn av sin vanlige stamtavle med Hadoop. Faktisk, som Clouderas Kestelyn uttrykte det, “HBase gir et rekordbasert lagringslag som muliggjør rask, tilfeldig lesing og skriving til data, og supplerer Hadoop ved å legge vekt på høy gjennomstrømning på bekostning av I / O med lav latens.
Kestelyn fortsetter:
Endringer blir effektivt katalogisert i minnet for å oppnå maksimal tilgang mens dataene vedvares til HDFS. Denne designen gjør det mulig for et Hadoop-basert EDH [enterprise data hub] å levere tilfeldige avlesninger og skrivinger til brukere og applikasjoner i sanntid, men likevel ha HDT-toleransen og holdbarheten.
Tilknytning til Hadoop er ikke den eneste grunnen til at HBase fortsetter å stige i databasens popularitetsrekke, selv om det kan være nok. I likhet med Cassandra, blir HBases røtter som en åpen kildekodeimplementering av Googles Bigtable, oversett til at databasen er meget skalerbar av design.
Fordi den kan bruke lagrings-, minne- og CPU-ressursene til et hvilket som helst antall servere, samt har utskalingsfunksjoner som automatisk skjæring, kan HBase skaleres ubegrenset ettersom krav til belastning og ytelse øker ganske enkelt ved å legge til servernoder. HBase ble designet fra grunnen av for å gi optimal ytelse når konsistens er kritisk.
Men skala er ikke bare verktøy. Som Kestelyn bemerket, “Takket være den tette integrasjonen med resten av Hadoop-økosystemet, er data lett tilgjengelig for brukere og applikasjoner via SQL-spørringer (ved bruk av Cloudera Impala, Apache Phoenix eller Apache Hive) eller til og med fasettert fritekstssøk (ved hjelp av Cloudera Search). ” Dermed gir HBase utviklere en måte å utnytte eksisterende ekspertise med SQL mens de bygger på en mer moderne, distribuert database.
Hver database har sine egne styrker og mangler, men hver av de tre som er profilert her har fylt et stort hull i big data-landskapet. Selv om det er mulig at en ny database vil komme sammen for å hevde en plass i NoSQL topp tre (DynamoDB?), Er virkeligheten at utviklere og bedriftene de betjener allerede standardiserer seg på noen få sterke alternativer: MongoDB, Cassandra og HBase.
Nå VP for mobil hos Adobe, var Matt Asay tidligere visepresident for samfunnet i MongoDB, Inc. Han er emeritusstyremedlem i Open Source Initiative (OSI) og tjente sin juris doktorgrad ved Stanford, hvor han fokuserte på åpen kildekode og annet problemer med lisensiering av immaterielle rettigheter, og mastergrad fra University of Kent i Canterbury og bachelor fra Brigham Young University. Asay var en av de første bloggerne.
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til [email protected].
