Hadoop får meget af big data-kredit, men virkeligheden er, at NoSQL-databaser er langt bredere implementeret - og langt mere bredt udviklet. Faktisk, mens shopping for en Hadoop-leverandør er relativt ligetil, er det alt andet end at vælge en NoSQL-database. Der er trods alt over 100 NoSQL-databaser, som DB-Engines popularitetsrangering viser.
Hvilket skal du vælge?
Forkælet for valg
Fordi vælg du skal. Så pænt som det kan være at leve i en lykkelig utopi af såkaldt polyglot-vedholdenhed, "hvor enhver anstændig størrelse virksomhed vil have en række forskellige datalagringsteknologier til forskellige slags data", som Martin Fowler hævder, er virkeligheden du har ikke råd til at investere i at lære mere end nogle få.
Heldigvis bliver valget lettere, da markedet samler sig omkring tre dominerende NoSQL-databaser: MongoDB (bakket op af min tidligere arbejdsgiver), Cassandra (primært udviklet af DataStax, skønt skrabet på Facebook) og HBase (tæt tilpasset Hadoop og udviklet af samme samfund).
Bemærk, at jeg målrettet ekskluderer Redis fra denne liste. Selvom det er en god datalager, bruges den primært til cachedata og er ikke velegnet til en bred vifte af arbejdsbelastninger.
LinkedIn-data fra 451 Research viser, hvordan markedet trækker til MongoDB, Cassandra og HBase:
Det er LinkedIn-profildata. En mere komplet visning er DB-Engines ', som samler job, søgning og andre data for at forstå databasens popularitet. Mens Oracle, SQL Server og MySQL troner øverst, giver MongoDB (nr. 5), Cassandra (nr. 9) og HBase (nr. 15) dem et løb for deres penge.
Mens det er for tidligt at kalde enhver anden NoSQL-database for en afrundingsfejl, når vi hurtigt det punkt, nøjagtigt som det skete i det relationsdatabasemarked.
For bedre at forstå, hvorfor disse tre databaser skinner, bad jeg repræsentanter fra hver om at identificere nøgleegenskaber for deres succes: Kelly Stirman, direktør for produkter hos MongoDB; Patrick McFadin, chef Cassandra-evangelist hos DataStax; og Justin Kestelyn, seniordirektør for udviklerrelationer hos Cloudera.
Men først skal vi forstå, hvorfor NoSQL betyder noget.
En verden bygget med ustrukturerede data
Vi lever i stigende grad i en verden, hvor data ikke passer godt ind i de ryddelige rækker og kolonner i en RDBMS. Mobil, social og cloud computing har skabt en massiv oversvømmelse af data. Ifølge en række skøn blev 90 procent af verdens data oprettet i de sidste to år, hvor Gartner fastgjorde 80 procent af alle virksomhedsdata som ustrukturerede. Hvad mere er, ustrukturerede data vokser med det dobbelte af strukturerede data.
Efterhånden som verden ændrer sig, går kravene til datastyring ud over det effektive anvendelsesområde for traditionelle relationsdatabaser. De første organisationer, der observerede behovet for alternative løsninger, var webpionerer, regeringsorganer og virksomheder, der specialiserer sig i informationstjenester.
I stigende grad nu søger virksomheder af alle striber at udnytte fordelene ved alternativer som NoSQL og Hadoop: NoSQL til at oprette operationelle applikationer, der driver deres forretning gennem systemer til engagement, og Hadoop til at opbygge applikationer, der analyserer deres data med tilbagevirkende kraft og hjælper med at levere kraftig indsigt .
MongoDB: Af udviklerne til udviklerne
Blandt NoSQL-indstillingerne påpeger MongoDB's Stirman, at MongoDB har tilstræbt en afbalanceret tilgang, der passer til en lang række applikationer. Mens funktionaliteten er tæt på en traditionel relationsdatabase, giver MongoDB brugerne mulighed for at udnytte fordelene ved skyinfrastruktur med sin vandrette skalerbarhed og let arbejde med de forskellige datasæt, der er i brug i dag takket være dens fleksible datamodel.
MongoDB er ofte de første NoSQL-databaseudviklere, der prøver, fordi det er så let at lære. Will Shulman, administrerende direktør for MongoLab (en MongoDB-som-en-tjenesteudbyder), siger det på denne måde:
MongoDB's uforholdsmæssige succes er i vid udstrækning baseret på dens innovation som en datastrukturbutik, der lader os lettere og udtrykkeligt modellere "tingene" i hjertet af vores applikationer ...
At have den samme grundlæggende datamodel i vores kode og i databasen er den overlegne metode til de fleste brugssager, da det dramatisk forenkler opgaven med applikationsudvikling og eliminerer de lag af kompleks kortlægningskode, der ellers er påkrævet.
Især MongoDB er, ligesom de andre databaser på denne liste, ikke en en-trick-pony. Virksomheder, der lærer MongoDB “kan afskrive deres investeringer i MongoDB på tværs af mange, mange projekter, hvilket gør det til en kort liste over standarder, de stoler på for al datahåndtering,” som Stirman fortalte mig.
Som enhver teknologi har MongoDB selvfølgelig sine styrker og svagheder. MongoDB er designet til OLTP-arbejdsbelastninger. Det kan udføre komplekse forespørgsler, men det passer ikke nødvendigvis bedst til rapportering-stil arbejdsbelastninger. Eller hvis du har brug for komplekse transaktioner, vil det ikke være et godt valg. MongoDBs enkelhed gør det dog et godt sted at starte.
Cassandra: Kør sikkert i målestok
Der er mindst to slags database enkelhed: enkelhed i udvikling og operationel enkelhed. Mens MongoDB med rette får kredit for en let out-of-the-box oplevelse, optjener Cassandra fulde point for at være let at administrere i stor skala.
Som DataStax's McFadin fortalte mig, har brugere en tendens til at tiltrække sig til Cassandra, jo mere de støder på hovedet mod vanskeligheden ved at gøre relationsdatabaser hurtigere og mere pålidelige, især i stor skala. En tidligere Oracle DBA, McFadin var begejstret for at opdage, at "replikering og lineær skalering er primitive" med Cassandra, og funktionerne var "det primære designmål fra starten."
I RDBMS-verdenen er databasefunktioner som skalering og replikering de hårde dele, der overlades til brugeren. Dette fungerede fint i gårsdagens virksomhed, da skala ikke var et stort problem. I dag er det hurtigt ved at blive det problem.
Som jeg hørte fra McFadin og andre, skinner Cassandra især i udskalede implementeringer. Cassandra leveres med indbygget support til flere datacentre. Hvad angår tilføjelse af kapacitet til en klynge, “Du starter simpelthen en ny maskine og fortæller Cassandra, hvor de andre knudepunkter er,” sagde McFadin, “og det tager sig af resten.”
Denne lette skalering kombineret med enestående skriveydelse ("Alt hvad du laver er at tilføje til slutningen af en logfil") og forudsigelig forespørgselsydeevne, tilføjer op til en højtydende arbejdshest i Cassandra.
En artikel i NoSQL-tro, som jeg længe har haft, er, at Cassandra kan være stærk i skala, men det kræver en doktorgrad for at komme i gang. Ikke så insisterede McFadin på:
Replikations- og læse- og skrivestierne er målrettet enkle. Du kan lære kerneinterne i Cassandra om et par timer. Det kan give stor tillid, når du implementerer ny teknologi, fordi der er mindre "black box" -detaljer, der introducerer komplekse fejltilstande.
Dette betyder, at prisen for adgang til effektiv Cassandra-udvikling ligger i forståelsen af datamodellen, og hvordan den fungerer sammen med din applikation. I betragtning af kendskabet til Cassandras CQL-forespørgselssprog (beregnet til at være "nøjagtigt som SQL undtagen når det ikke er"), sagde McFadin, det er ikke en stejl indlæringskurve.
Mere vigtigt sagde han til mig, ”Cassandra belønner dig med den ene ting, du vil have fra en database: intet drama. Dette er grunden til, at brugerne elsker at bruge Cassandra. ”
HBase: Brystkammerater med Hadoop
HBase får, ligesom Cassandra, en kolonneorienteret nøgleværdibutik, stort set meget brug på grund af sin fælles stamtavle med Hadoop. Faktisk, som Clouderas Kestelyn udtrykte det, “HBase giver et rekordbaseret lagerlag, der muliggør hurtig, tilfældig læsning og skrivning til data, hvilket supplerer Hadoop ved at understrege høj kapacitet på bekostning af I / O med lav latenstid.”
Kestelyn fortsætter:
Ændringer katalogiseres effektivt i hukommelsen for at opnå maksimal adgang, mens dataene vedvares til HDFS. Dette design gør det muligt for et Hadoop-baseret EDH [enterprise data hub] at levere tilfældige læser og skriver til brugere og applikationer i realtid, men alligevel nyder HDFS's fejltolerance og holdbarhed.
Affinitet med Hadoop er ikke den eneste grund til, at HBase fortsætter med at stige i databasens popularitetsranger, selvom det måske er nok. I lighed med Cassandra oversætter HBases rødder som en open source-implementering af Googles Bigtable til databasen, der er meget skalerbar af design.
Fordi det kan udnytte lagrings-, hukommelses- og CPU-ressourcerne på et hvilket som helst antal servere samt har udskalningsfunktioner som automatisk sharding, kan HBase skaleres ubegrænset, da krav til belastning og ydelse stiger ved blot at tilføje serverknudepunkter. HBase blev designet fra bunden til at give optimal ydeevne, når konsistens er kritisk.
Men skala er ikke kun det nytteværdi. Som Kestelyn bemærkede, “Takket være den tætte integration med resten af Hadoop-økosystemet er data let tilgængelige for brugere og applikationer via SQL-forespørgsler (ved hjælp af Cloudera Impala, Apache Phoenix eller Apache Hive) eller endda facetteret fritekstsøgning (ved hjælp af Cloudera-søgning). ” Således giver HBase udviklere en måde at udnytte eksisterende ekspertise med SQL, mens de bygger på en mere moderne, distribueret database.
Hver database har sine egne styrker og mangler, men hver af de tre, der er profileret her, har fyldt et stort hul i big data-landskabet. Selvom det er muligt, at en ny database kommer sammen for at gøre krav på en plads i NoSQL top tre (DynamoDB?), Er virkeligheden, at udviklere og de virksomheder, de betjener, allerede standardiserer på nogle få stærke muligheder: MongoDB, Cassandra og HBase.
Nu vicepræsident for mobil hos Adobe, Matt Asay var tidligere vicepræsident for samfund hos MongoDB, Inc. Han er emeritus-bestyrelsesmedlem i Open Source Initiative (OSI) og tjente sin juris-doktorgrad i Stanford, hvor han fokuserede på open source og andet spørgsmål om licens til intellektuel ejendom og hans kandidater fra University of Kent i Canterbury og hans bachelor fra Brigham Young University. Asay var en af de første bloggere.
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
