NoSQL-gegevensopslag tegenover Hadoop - dummies

NoSQL-gegevensarchieven waren oorspronkelijk geabonneerd op het begrip "Zeg gewoon nee tegen SQL" (om te parafraseren van een anti-drugs reclamecampagne in de jaren tachtig), en ze waren een reactie op de waargenomen beperkingen van (SQL-gebaseerde) relationele databases. Het is niet zo dat deze mensen een hekel hadden aan SQL, maar ze waren het zat om vierkante pinnen in ronde gaten te forceren door problemen op te lossen waarvoor relationele databases niet waren ontworpen.

Een relationele database is een krachtig hulpmiddel, maar voor sommige soorten gegevens (zoals sleutel / waarde-paren of grafieken) en sommige gebruikspatronen (zoals extreem grootschalige opslag) is een relationele database niet echt t praktisch. En als het gaat om opslag met een hoog volume, kan een relationele database duur zijn, zowel wat betreft de licentiekosten van de database als de hardwarekosten. (Relationele databases zijn ontworpen om te werken met enterprise-grade hardware.)

Dus met de NoSQL-beweging ontwikkelden creatieve programmeurs tientallen oplossingen voor verschillende soorten netelige gegevensopslag- en verwerkingsproblemen. Deze NoSQL-databases bieden doorgaans een enorme schaalbaarheid door middel van clustering en zijn vaak ontworpen om hoge doorvoer en lage latentie mogelijk te maken.

De naam NoSQL is enigszins misleidend omdat veel databases die in de categorie passen SQL-ondersteuning hebben (in plaats van "NoSQL" -ondersteuning). Beschouw de naam in plaats daarvan als "Niet alleen SQL. “

De NoSQL-aanbiedingen die vandaag beschikbaar zijn, kunnen worden onderverdeeld in vier verschillende categorieën, op basis van hun ontwerp en hun doel:

• Key-value winkels: Dit aanbod biedt een manier om elke soort op te slaan van gegevens zonder een schema te gebruiken. Dit staat in tegenstelling tot relationele databases, waar u het schema (de tabelstructuur) moet definiëren voordat er gegevens worden ingevoegd. Omdat voor sleutelwaardevoorraden geen schema nodig is, hebt u een grote flexibiliteit om gegevens in vele indelingen op te slaan.

  In een sleutel / waarde-opslag bestaat een rij simpelweg uit een sleutel (een identifier) ​​en een waarde, die van een geheel-getalwaarde tot een grote binaire datastring kan zijn. Veel implementaties van winkels met belangrijke waarden zijn gebaseerd op Amazon's Dynamo-papier.

• Kolomfamilieopslag: Hier hebt u databases waarin kolommen zijn gegroepeerd in kolomfamilies en samen op schijf zijn opgeslagen.

  Strikt genomen zijn veel van deze databases niet kolomgeoriënteerd, omdat ze zijn gebaseerd op Google's BigTable-papier, dat gegevens opslaat als een multidimensionale gesorteerde kaart.

• Documentarchieven: Dit aanbod is gebaseerd op collecties van vergelijkbare gecodeerde en opgemaakte documenten om de efficiëntie te verbeteren.Documentarchieven maken het voor afzonderlijke documenten in een verzameling mogelijk om slechts een subset van velden op te nemen, dus alleen de gegevens die nodig zijn, worden opgeslagen. Voor verspreide gegevenssets, waar veel velden vaak niet worden ingevuld, kan dit zich vertalen in aanzienlijke ruimtebesparingen.

  Lege kolommen in relationele databasetabellen daarentegen nemen ruimte in beslag. Documentarchieven maken ook schemaflexibiliteit mogelijk, omdat alleen de benodigde velden worden opgeslagen en nieuwe velden kunnen worden toegevoegd. Nogmaals, in tegenstelling tot relationele databases, worden tabelstructuren vooraf gedefinieerd voordat gegevens worden opgeslagen en is het wijzigen van kolommen een vervelende taak die gevolgen heeft voor de gehele gegevensset.

• Grafiekdatabases: Hier hebt u databases met grafiekstructuren - afbeeldingen die entiteitenverzamelingen (hoekpunten of knooppunten) en hun relaties (randen) met elkaar tonen. Deze structuren maken het mogelijk dat grafedatabases uitermate geschikt zijn voor het opslaan van complexe structuren, zoals de koppelingsrelaties tussen alle bekende webpagina's. (Individuele webpagina's zijn bijvoorbeeld knooppunten en de randen die ze verbinden zijn links van de ene pagina naar de andere.)

  Google is natuurlijk helemaal bezig met grafiektechnologie en heeft een grafische verwerkingsengine ontwikkeld met de naam Pregel om de PageRank van stroom te voorzien algoritme. (En ja, er is een witboek over Pregel.) In de Hadoop-community is er een Apache-project met de naam Giraph (gebaseerd op het Pregel-document), een grafische verwerkingsengine die is ontworpen om grafieken te verwerken die zijn opgeslagen in HDFS.

De opties voor gegevensopslag en -verwerking die beschikbaar zijn in Hadoop zijn in veel gevallen implementaties van de hier vermelde NoSQL-categorieën. Op deze manier kunt u de oplossingen die voor u beschikbaar zijn beter evalueren en bekijken hoe Hadoop traditionele datawarehouses kan aanvullen.