Partities in NoSQL beheren - dummies

De woordpartitie wordt gebruikt voor twee verschillende concepten in NoSQL-land. Een gegevenspartitie is een mechanisme om ervoor te zorgen dat gegevens gelijkmatig over een cluster worden verdeeld. Aan de andere kant treedt een netwerkpartitie op wanneer twee delen van hetzelfde databasecluster niet kunnen communiceren.

Op zeer grote geclusterde systemen is het steeds waarschijnlijker dat er een defect aan één apparaat zal optreden. Als een netwerkswitch tussen servers in een cluster mislukt, treedt er een fenomeen op dat (in computertaal) gespleten hersenen wordt genoemd. In dit geval ontvangen individuele servers nog steeds verzoeken, maar kunnen ze niet met elkaar communiceren.

Dit scenario kan leiden tot inconsistentie van gegevens of eenvoudigweg tot verminderde capaciteit in gegevensopslag, omdat de netwerkpartitie met de minste servers uit het cluster wordt verwijderd (of "weggestemd" in echte Big Brother-mode).

Partities verdraaien

U hebt twee keuzes wanneer een netwerkpartitie zich voordoet:

• Ga verder, op een bepaald niveau, naar service lees- en schrijfbewerkingen.

• "Stem af" op een deel van de partitie en besluit de gegevens later te herstellen wanneer beide delen kunnen communiceren. Dit houdt meestal in dat het cluster een leesreplica stemt als de nieuwe master voor elk ontbrekend masterpartitieknooppunt.

Met Riak kunt u bepalen hoe vaak gegevens worden gerepliceerd (standaard drie keer, dat wil zeggen, n = 3) en hoeveel servers moeten worden opgevraagd voordat het lezen slaagt. Dit betekent dat, als de primaire master van een sleutel zich aan de verkeerde kant van een netwerkpartitie bevindt, de leesbewerkingen nog steeds kunnen slagen als de andere twee servers beschikbaar zijn (r = 2 leesbeschikbaarheid).

Riak-handles schrijven wanneer de primaire partitieserver wordt uitgeschakeld met behulp van een systeem met de naam doorschijnende overdracht . Wanneer gegevens oorspronkelijk worden gerepliceerd, wordt het eerste knooppunt voor een bepaalde sleutelpartitie geschreven, samen met (standaard) twee van de volgende aangrenzende knooppunten.

Als er niet naar de primaire kan worden geschreven, wordt naar het volgende knooppunt in de ring geschreven. Deze schrijfopdrachten worden effectief doorgegeven aan het volgende knooppunt. Wanneer de primaire server weer verschijnt, worden de schrijfopdrachten opnieuw afgespeeld naar dat knooppunt voordat het primaire schrijfbewerkingen opnieuw overneemt.

In beide bewerkingen kunnen inconsistenties in versiebeheer optreden omdat verschillende replica's zich in verschillende versietoestanden kunnen bevinden, zelfs al is het maar voor een paar milliseconden.

Riak gebruikt nog een ander systeem met de naam actieve anti - entropie om dit probleem te verhelpen. Dit systeem volgt de bijgewerkte waarden en zorgt ervoor dat replica's op een bepaald moment worden bijgewerkt, bij voorkeur vroeger of later.Dit helpt om leesconflicten te voorkomen met behoud van een hoge opnamesnelheid, waardoor een tweefasige commit wordt vermeden die wordt gebruikt door andere NoSQL-databases met master-slave, gedeelde-niets clusteringondersteuning.

Als er een leesconflict optreedt, gebruikt Riak leesreparatie om alleen de laatste gegevens te retourneren. Uiteindelijk echter, en afhankelijk van de instellingen voor consistentie en beschikbaarheid die u gebruikt, kan de clienttoepassing meerdere versies worden gepresenteerd en wordt gevraagd om zelf te beslissen.

In sommige situaties is deze afweging wenselijk en veel toepassingen kunnen intuïtief weten, op basis van de gepresenteerde gegevens, welke versie moet worden gebruikt en welke versie moet worden verwijderd.

Secundaire indexering

Secundaire indexen zijn indexen voor specifieke gegevens binnen een waarde. De meeste winkels met belangrijke waarden laten deze indexering over aan de applicatie. Riak is echter anders en maakt gebruik van een schema met de naam document - op basis van partitionering dat secundaire indexering mogelijk maakt.

Op documenten gebaseerde partitionering gaat ervan uit dat u JSON-structuren naar de Riak-database schrijft. U kunt vervolgens indexen instellen voor specifieke eigenschappen in deze JSON-structuur, zoals weergegeven:

{"order-id": 5001, "klant-ID": 1429857, "orderdatum": "2014-09-24 "," Totaal ": 134. 24}

Als u een toepassing hebt die de bestellingen van een klant van de vorige maand toont, dan wilt u alle records opvragen, zoals weergegeven, waarbij de klant-ID een vaste waarde is (1429857) en de besteldatum ligt binnen een bepaald bereik (het begin en het einde van de maand).

In de meeste sleutelwaardewinkels maakt u een andere bucket aan, waarvan de sleutel het gecombineerde klantnummer en de maand is en de waarde een lijst met bestel-id's is. In Riak voegt u echter eenvoudigweg een secundaire index toe voor zowel klant-id (geheel getal) als orderdatum (datum), die wel extra opslagruimte in beslag neemt, maar het voordeel heeft dat deze transparant is voor de ontwikkelaar van de applicatie.

Deze indexen worden ook live bijgewerkt - wat betekent dat er geen vertraging is tussen het bijwerken van een documentwaarde in Riak en het up-to-date zijn van de indexen. Deze live toegang tot gegevens is moeilijker om uit te halen dan het lijkt. Immers, als de indexen inconsistent zijn, zult u nooit de consistent gehouden gegevens vinden!

Evaluatie van Riak

Basho, de commerciële entiteit achter Riak, zegt dat de aankomende versie 2. 0 NoSQL-database altijd een sterke consistentie heeft, een claim die andere NoSQL-leveranciers maken. De claim van NoSQL-verkopers om altijd een sterke consistentie te hebben, is als beweren een sterke vegetariër te zijn … behalve op zondag als je rosbief hebt.

Riak is geen ACID-compatibele database. De configuratie kan niet zodanig worden gewijzigd dat deze in de ACID-conformiteitsmodus werkt. Cliënten kunnen inconsistente gegevens krijgen tijdens normale bewerkingen of tijdens netwerkpartities. Riak ruilt absolute consistentie in voor verhoogde beschikbaarheid en partitietolerantie.

Als Riak wordt uitgevoerd in de modus voor sterke consistentie, worden de leesreplica's tegelijkertijd met de primaire master bijgewerkt. Dit omvat een COMMIT in twee fasen - in feite het hoofdknooppunt dat naar de andere knooppunten schrijft voordat het bevestigt dat de schrijfbewerking voltooid is.

Op het moment van schrijven ondersteunt de sterke consistentiemodus van Riak geen secundaire indexen of complexe gegevenstypen (bijvoorbeeld JSON). Hopelijk lost Basho dit probleem op in de komende releases van de database.

Riak Search (een rebranded en geïntegreerde Apache Solr-zoekmachine maakt gebruik van een uiteindelijk consistent updatemodel) kan valse positieven opleveren bij gebruik van sterke consistentie. Deze situatie doet zich voor omdat gegevens kunnen worden geschreven en de transactie vervolgens wordt gestaakt, maar de gegevens worden nog steeds gebruikt voor indexering - waardoor een "vals positief" zoekresultaat overblijft - het resultaat is niet langer geldig voor de zoekopdracht.

Riak gebruikt ook een afzonderlijk sentinelproces om te bepalen welk knooppunt een meester in failover-omstandigheden wordt. Dit proces is echter niet erg beschikbaar, wat betekent dat het voor een paar seconden mogelijk is dat een nieuw exemplaar van het sentinelproces online wordt gebracht, maar er kan geen nieuw knooppunt worden toegevoegd of een nieuw knooppunt. meester gekozen. U moet op de hoogte zijn van deze mogelijkheid in omstandigheden met hoge stressstoornissen.

Riak heeft enkele leuke functies voor applicatieontwikkelaars, zoals secundaire indexering en ingebouwde ondersteuning voor JSON-waarden. Database-replicatie voor noodherstel naar andere datacenters is alleen beschikbaar in de betaalde versie, waarvan de prijs te vinden is op hun website (getoonde huurprijzen, prijzen voor eeuwigdurende licenties die alleen op aanvraag worden gegeven).

Het Riak Control-clusterbewakingsinstrument staat ook niet hoog aangeschreven vanwege de vertragingstijd bij het bewaken van clusters. Riak heeft veel belofte en als Basho meer enterprise - niveau clusterbeheerfaciliteiten zal toevoegen in toekomstige versies, zal het een best-in-class product worden.