Gemeenschappelijke kenmerken van NoSQL - dummies

NoSQL-boeken en blogs bieden verschillende meningen over wat een NoSQL-database is. Vier kernfuncties van NoSQL, weergegeven in de volgende lijst, zijn van toepassing op de meeste NoSQL-databases. De lijst vergelijkt NoSQL met traditioneel relationeel DBMS:

• Schema agnostisch: Een databaseschema is de beschrijving van alle mogelijke gegevens- en gegevensstructuren in een relationele database. Met een NoSQL-database is een schema niet vereist, waardoor u de vrijheid heeft om informatie op te slaan zonder eerst een schema te maken.

• Niet-relationeel: Relaties in een database leggen verbanden tussen tabellen met gegevens. Een lijst met transactiegegevens kan bijvoorbeeld worden verbonden met een afzonderlijke lijst met bezorgingsgegevens. Met een NoSQL-database wordt deze informatie opgeslagen als een aggregaat: één record met alles over de transactie, inclusief het afleveradres.

• Goederenhardware: Sommige databases zijn ontworpen om het beste (of alleen) te werken met gespecialiseerde hardware voor opslag en verwerking. Met een NoSQL-database kunnen goedkope kant-en-klare servers worden gebruikt. Door meer van deze goedkope servers toe te voegen, kunnen NoSQL-databases opschalen om meer gegevens te verwerken.

• Zeer goed te distribueren: Gedistribueerde databases kunnen een reeks gegevens op meer dan één apparaat opslaan en verwerken. Met een NoSQL-database kan een cluster van servers worden gebruikt om een ​​enkele grote database te bevatten.

Schema agnostic

NoSQL-databases zijn schema-agnostisch. U hoeft niet veel voorontwerpwerk te doen voordat u gegevens in NoSQL-databases kunt opslaan. U kunt beginnen met coderen en gegevens opslaan en ophalen zonder te weten hoe de database intern wordt opgeslagen en gewerkt. (Als en wanneer u geavanceerde functionaliteit nodig hebt, kunt u handmatig verdere indexen toevoegen of structuurstructuren voor gegevens aanpassen.) Schema-agnosticisme is mogelijk het belangrijkste verschil tussen NoSQL en relationele databases.

Het grote voordeel voor een schema-agnostische database is dat de ontwikkeltijd wordt verkort. Dit voordeel neemt toe naarmate u meerdere ontwikkelversies doorloopt en de interne gegevensstructuren in de database moet wijzigen.

In een traditioneel RDBMS doorloopt u bijvoorbeeld een proces van schemaherontwerp. Het schema geeft de database instructies over welke gegevens moeten worden verwacht. Wijzig de opgeslagen gegevens of structuren en u moet de database opnieuw instrueren met behulp van een aangepast schema. Als u een wijziging aanbrengt, moet u veel tijd besteden aan het bepalen van hoe u de bestaande gegevens opnieuw moet ontwerpen. In NoSQL-databases slaat u eenvoudig een andere datastructuur op. Het is niet nodig om de database vooraf te vertellen.

Het kan zijn dat u uw query's dienovereenkomstig moet aanpassen, misschien kunt u af en toe een specifieke index toevoegen (zoals een index met een geheel getalbereik om minder dan en groter dan specifieke query's van het gegevenstype toe te staan), maar het hele proces is veel minder pijnlijk dan bij een RDBMS.

RDBMS is van start gegaan vanwege de flexibiliteit en omdat het, door SQL te gebruiken, het aanpassen van een query bespoedigde. NoSQL-databases bieden deze flexibiliteit voor het wijzigen van zowel het schema als de query, wat een van de belangrijkste redenen is dat ze in de loop van de tijd steeds vaker worden goedgekeurd.

Zelfs als u een query uitvoert, hoeft u zich niet al te veel zorgen te maken over het kennen van de schemawijzigingen - overweeg een index over een veldrekeningnummer, waarbij rekeningnummer overal in een document kan worden gevonden dat is opgeslagen in een NoSQL-database. U kunt de structuur wijzigen en verplaatsen waar rekeningnummer is opgeslagen, en als het element elders in het document dezelfde naam heeft, is het nog steeds beschikbaar voor query's zonder wijzigingen in uw querymechanisme.

Merk op dat niet alle NoSQL-databases volledig schema-agnostisch zijn. Sommige, zoals HBase, vereisen dat u de database stopt om kolomdefinities te wijzigen. Ze worden nog steeds beschouwd als NoSQL-databases, omdat niet alle gedefinieerde velden (kolommen in dit geval) van tevoren moeten worden bekendgemaakt voor elke record - alleen de kolomfamilies.

RDBMS maakt het mogelijk afzonderlijke velden in records te identificeren als null -waarden. Het probleem met een RDBMS is dat de opgeslagen gegevensgrootte en -prestaties negatief worden beïnvloed wanneer opslag wordt gereserveerd voor lege waarden, voor het geval de record op een later tijdstip een waarde in die kolom zou kunnen hebben. In Cassandra levert u eenvoudigweg de gegevens van die kolom niet op, waardoor het probleem wordt opgelost.

Niet-relationele

Relationele databasebeheersystemen zijn al meer dan 20 jaar de belangrijkste manier om applicatiegegevens op te slaan. Er is veel wiskundig werk gedaan om de theorie te bewijzen die daaraan ten grondslag ligt.

Deze onderbouwing beschrijft hoe tabellen zich tot elkaar verhouden. Een rij met één rij kan betrekking hebben op veel rijen met bezorgingsadres, maar elke rij met leveringsadressen heeft ook betrekking op meerdere rijen met orders. Dit is een veel - tot - veel relatie .

NoSQL-databases hebben dit concept van relaties tussen hun records niet. In plaats daarvan denormaliseren ze gegevens. Dit betekent dat in een NoSQL-database een bestelstructuur zou zijn met het bezorgadres ingesloten. Dit betekent dat het bezorgadres wordt gedupliceerd in elke rij Bestelling die het gebruikt. Deze benadering heeft het voordeel dat er geen complexe querytijdsamenvoegingen nodig zijn voor meerdere gegevensstructuren (tabellen).

NoSQL-databases slaan geen informatie op over hoe individuele records zich verhouden tot andere records in de database, wat als een beperking kan klinken. NoSQL-databases zijn echter flexibeler in termen van datastructuren die u kunt opslaan.

Overweeg een bestelling van een online verkoper. De bestelling kan productcodes, hoeveelheden, artikelprijzen en artikelbeschrijvingen omvatten, evenals informatie over de persoon die bestelt, zoals afleveradres en betalingsinformatie.

In plaats van tien rijen in verschillende tabellen in een relationele database in te voegen, kunt u in plaats daarvan één structuur opslaan voor al deze orderinformatie, bijvoorbeeld als een JSON- of XML-document.

In de relationele databasetheorie is het doel om uw gegevens te normaliseren (dat wil zeggen om de velden en tabellen te organiseren om dubbele gegevens te verwijderen). In NoSQL-databanken - met name document- of geaggregeerde databases - u vaak met opzet gegevens denormaliseert en sommige gegevens meerdere keren opslaat. U kunt bijvoorbeeld 'Klantbezorgingsadres' meerdere keren opslaan in veel bestellingen die een klant in de loop van de tijd maakt, in plaats van het eenmaal op te slaan en ernaar te verwijzen in meerdere bestellingen. Hiervoor hebt u extra opslagruimte nodig en een beetje voorzichtigheid bij het beheer van uw toepassing. Dus waarom doen?

Er zijn twee voordelen aan het meerdere keren opslaan van gegevens:

Eenvoudig opslaan en ophalen:

• Gewoon opslaan en een enkele record ophalen. Query-snelheid:

• In relationele databases voegt u informatie toe en voegt u tijdens de query beperkingen toe aan de tabellen. Dit kan vereisen dat de database-engine veel tabellen evalueert. Hoe meer querybeperkingen u hebt over verschillende tabellen, hoe meer u uw querysnelheid verlaagt. (Dit is de reden waarom een ​​RDBMS vooraf berekende weergaven heeft.) In een NoSQL-database bevindt alle informatie die u nodig hebt om uw query te evalueren zich in een enkel document. Daarom kunt u snel de lijst met overeenkomende documenten bepalen. Relationele weergaven en NoSQL-denormalisaties zijn verschillende benaderingen van het probleem van gegevensverspreiding over records. In NoSQL moet u mogelijk meerdere denormalisaties uitvoeren die verschillende weergaven van dezelfde gegevens vertegenwoordigen. Deze aanpak verhoogt de opslagkosten maar geeft u veel betere query-tijd.

Gezien de steeds lagere kosten van opslag en de verhoogde snelheid van ontwikkeling en bevraging, zijn gedenormaliseerde gegevens (ook bekend als

gematerialiseerde weergaven ) geen goede reden om NoSQL-oplossingen te verlagen. Het is gewoon een andere manier om hetzelfde probleem te benaderen, met zijn eigen voor- en nadelen. NoSQL is sterk distribueerbaar en gebruikt standaardhardware

In veel NoSQL-databases is een belangrijke ontwerpbeslissing om meerdere computers te gebruiken om gegevens voor één database op te slaan, in plaats van de hele database op één server te hebben.

Het opslaan van gegevens op meerdere machines en het mogelijk maken deze te controleren, is moeilijk. U moet de vraag verzenden naar alle servers en wachten op een antwoord. Hopelijk zet je de machines zo neer dat ze snel genoeg zijn om met elkaar te communiceren om gedistribueerde vragen te behandelen!

Het belangrijkste voordeel van deze aanpak is in het geval van zeer grote gegevenssets, omdat voor sommige opslagvereisten zelfs de grootste beschikbare enkele server niet alle gegevens kan opslaan of verwerken die u nodig hebt. Overweeg alle berichten op Twitter en Facebook. Je hebt een gedistribueerd mechanisme nodig om al die gegevens effectief te beheren, ook al gaat het meestal om wat mensen hadden voor het ontbijt en schattige kattenvideo's.

Een voordeel van het distribueren van uw database is dat u goedkopere servers kunt gebruiken, commodity-servers genoemd.Zelfs voor kleinere datasets kan het goedkoper zijn om drie commodity-servers te kopen in plaats van een enkele server met een hogere stroomvoorziening. Een ander belangrijk voordeel is dat het toevoegen van hoge beschikbaarheid eenvoudiger is; je bent al halverwege daar door je gegevens te verspreiden. Als u uw gegevens één of twee keer repliceert op andere servers in het cluster, blijven uw gegevens toegankelijk, zelfs als een van de servers crasht, brandt en sterft.

Niet alle open-source databases ondersteunen hoge beschikbaarheid, tenzij u de ondersteunde betaalde versie van de database koopt van het bedrijf dat de database heeft ontwikkeld.

Een uitzondering op de in hoge mate te verdelen regel is die van grafiedatabases. Om bepaalde grafische query's tijdig te kunnen beantwoorden, moeten de gegevens op één server worden opgeslagen. Niemand heeft dit specifieke probleem al opgelost.

Overweeg zorgvuldig of u een drievoudige winkel of een grafische winkel nodig heeft. Triple-winkels zijn over het algemeen verspreidbaar, terwijl grafische winkels dat niet zijn. Welke je nodig hebt, hangt af van de vragen die je moet ondersteunen.