Consistent hashen - Consistent hashing

In de informatica is consistente hashing een speciaal soort hash- techniek, zodat wanneer de grootte van een hashtabel wordt gewijzigd, alleen de sleutels gemiddeld opnieuw hoeven te worden toegewezen, waarbij het aantal sleutels en het aantal slots is. In de meeste traditionele hash-tabellen zorgt een verandering in het aantal array-slots er daarentegen voor dat bijna alle sleutels opnieuw worden toegewezen, omdat de toewijzing tussen de sleutels en de slots wordt gedefinieerd door een modulaire bewerking . ${\displaystyle n/m}$${\displaystyle n}$${\displaystyle m}$

Geschiedenis

De term "consistent hashing" werd geïntroduceerd door David Karger et al. bij MIT voor gebruik in gedistribueerde caching , met name voor het web . Dit academische artikel uit 1997 in Symposium on Theory of Computing introduceerde de term "consistent hashing" als een manier om verzoeken te verspreiden onder een veranderende populatie van webservers. Elk slot wordt dan vertegenwoordigd door een server in een gedistribueerd systeem of cluster. Het toevoegen van een server en het verwijderen van een server (tijdens schaalbaarheid of uitval) vereist dat alleen items opnieuw worden geschud wanneer het aantal slots (dwz servers) verandert. De auteurs noemen lineaire hashing en de mogelijkheid om opeenvolgende toevoegingen en verwijderingen van servers af te handelen, terwijl consistente hashing het mogelijk maakt servers in willekeurige volgorde toe te voegen en te verwijderen. Het papier kreeg later een nieuwe bestemming om de technische uitdaging aan te gaan om een ​​bestand bij te houden in peer-to-peer-netwerken , zoals een gedistribueerde hash-tabel . ${\displaystyle num\_keys/num\_slots}$

Teradata gebruikte deze techniek in hun gedistribueerde database, uitgebracht in 1986, hoewel ze deze term niet gebruikten. Teradata gebruikt nog steeds het concept van een hashtabel om precies dit doel te bereiken. Akamai Technologies werd in 1998 opgericht door de wetenschappers Daniel Lewin en F. Thomson Leighton (co-auteurs van het artikel dat "consistente hashing" noemt). In het content delivery-netwerk van Akamai wordt consistente hashing gebruikt om de belasting binnen een cluster van servers te verdelen , terwijl een stabiel huwelijksalgoritme wordt gebruikt om de belasting over clusters te verdelen.

Consistente hashing is ook gebruikt om de impact van gedeeltelijke systeemstoringen in grote webapplicaties te verminderen om robuuste caching te bieden zonder de systeembrede fall-out van een storing. Consistente hashing is ook de hoeksteen van gedistribueerde hash-tabellen (DHT's), die hash-waarden gebruiken om een ​​sleutelruimte te verdelen over een gedistribueerde set knooppunten, en vervolgens een overlay-netwerk van verbonden knooppunten construeren dat efficiënte knooppuntophaling per sleutel mogelijk maakt. Rendezvous hashing , ontworpen in 1996, is een eenvoudigere en meer algemene techniek. Het bereikt de doelen van consistente hashing met behulp van het zeer verschillende algoritme met het hoogste willekeurige gewicht (HRW).

Basistechniek

In dit geval zou het gebruik van consistente hashing ertoe leiden dat de "BLOB" opgeslagen server 139 krijgt. Een BLOB wordt toegewezen aan de volgende server die met de klok mee op de cirkel verschijnt totdat deze een server bereikt die ${\displaystyle \zeta \leq {\text{server-ID}}}$

In het probleem van load balancing , bijvoorbeeld, wanneer een BLOB-object moet worden toegewezen aan een van de servers op een cluster , zou een standaard hash-functie kunnen worden gebruikt op een zodanige manier dat we de hash-waarde voor die BLOB berekenen, uitgaande van de resulterende waarde van de hash is , we voeren een modulaire bewerking uit met het aantal servers ( in dit geval) om de server te bepalen waarin we de BLOB kunnen plaatsen: ; vandaar dat de BLOB in de server wordt geplaatst waarvan de opvolger in dit geval is. Echter, wanneer een server wordt toegevoegd of verwijderd tijdens uitvalt schalen (bij veranderingen), alle blobs in elke server moet worden toegewezen en drijven omdat herkauwen , maar deze bewerking is duur. ${\displaystyle n}$${\displaystyle \beta}$${\displaystyle n}$${\displaystyle \zeta =\beta \\%\ n}$${\displaystyle {\text{server-ID}}}$${\displaystyle \zeta}$${\displaystyle n}$

Consistente hashing is ontworpen om te voorkomen dat elke BLOB opnieuw moet worden ontworpen wanneer een server in het cluster wordt toegevoegd of verwijderd. Het centrale idee is dat we een hash-functie gebruiken die zowel de BLOB als de servers willekeurig toewijst aan een eenheidscirkel, meestal radialen. Bijvoorbeeld (waar is de hash van een BLOB- of server-ID, zoals IP-adres of UUID ). Elke BLOB wordt vervolgens toegewezen aan de volgende server die met de klok mee op de cirkel verschijnt. Gewoonlijk wordt een binair zoekalgoritme of lineair zoeken gebruikt om een ​​"spot" of server te vinden om die specifieke BLOB in respectievelijk complexiteiten te plaatsen; en in elke iteratie, die met de klok mee gebeurt, wordt een bewerking (waar is de waarde van de server binnen het cluster) uitgevoerd om de server te vinden om de BLOB te plaatsen. Dit zorgt voor een gelijkmatige verdeling van BLOB's naar servers. Maar wat nog belangrijker is, als een server uitvalt en uit de cirkel wordt verwijderd, hoeven alleen de BLOB's die aan de defecte server zijn toegewezen, met de klok mee opnieuw te worden toegewezen aan de volgende server. Evenzo, als een nieuwe server wordt toegevoegd, wordt deze toegevoegd aan de eenheidscirkel en hoeven alleen de BLOB's die aan die server zijn toegewezen, opnieuw te worden toegewezen. ${\displaystyle 2\pi}$${\displaystyle \zeta =\Phi \ \%\ 360}$${\displaystyle \Phi}$${\displaystyle O(\log N)}$${\displaystyle O(N)}$${\ Displaystyle \ zeta \ \ leq \ \ Psi}$${\displaystyle \Psi}$

Belangrijk is dat wanneer een server wordt toegevoegd of verwijderd, de overgrote meerderheid van de BLOB's hun eerdere servertoewijzingen behoudt, en de toevoeging van een server zorgt er slechts voor dat een fractie van de BLOB's wordt verplaatst. Hoewel het proces van het verplaatsen van BLOB's over cacheservers in het cluster afhangt van de context, identificeert de nieuw toegevoegde cacheserver gewoonlijk de "opvolger" en verplaatst alle BLOB's. In het geval van webpaginacaches is er in de meeste implementaties echter geen sprake van verplaatsen of kopiëren, ervan uitgaande dat de BLOB in de cache klein genoeg is. Wanneer een verzoek een nieuw toegevoegde cacheserver bereikt, gebeurt er een cachemisser en wordt een verzoek aan de eigenlijke webserver gedaan en wordt de BLOB lokaal in de cache opgeslagen voor toekomstige verzoeken. De redundante BLOB's op de eerder gebruikte cacheservers zouden worden verwijderd volgens het cache-uitzettingsbeleid . ${\displaystyle n^{de}}$${\displaystyle 1/n}$

Implementatie

Laten en zijn de hash-functies die worden gebruikt voor respectievelijk de BLOB en de unieke identifier van de server. In de praktijk wordt een binaire zoekboom (BST) gebruikt om de binnen een cluster of hashring dynamisch te onderhouden en om de opvolger of het minimum binnen de BST te vinden, wordt tree traversal gebruikt. ${\displaystyle h_{b}(x)}$${\displaystyle h_{s}(x)}$${\displaystyle {\text{server-ID}}}$

• Invoegen in het cluster${\displaystyle x}$

Laat de hash-waarde van een BLOB zijn zodat, waar en . Om in te voegen , zoek de opvolger van in de BST van s. Als groter is dan alle s, wordt de BLOB in de server met de kleinste waarde geplaatst.${\displaystyle \beta}$${\displaystyle h_{b}(x)=\beta \ \%\ 360}$${\displaystyle x\in BLOB}$${\displaystyle h_{b}(x)=\zeta}$${\displaystyle x}$${\displaystyle \zeta}$${\displaystyle {\text{server-ID}}}$${\displaystyle \zeta}$${\displaystyle {\text{server-ID}}}$${\displaystyle {\text{server-ID}}}$

• Verwijderen uit het cluster${\displaystyle x}$

Zoek de opvolger van in de BST, verwijder de BLOB uit de geretourneerde . Als er geen opvolger is, verwijder dan de BLOB van de kleinste van de s.${\displaystyle \zeta}$${\displaystyle {\text{server-ID}}}$${\displaystyle \zeta}$${\displaystyle {\text{server-ID}}}$

• Een server in cluster invoegen

Laat de hash-waarde van de identifier van een server zijn, zodat, waar en . Verplaats alle BLOB's van de server waarvan de opvolger is van . Als de grootste van alle s is, verplaats dan de BLOB's van de kleinste van de s naar .${\displaystyle \Phi}$${\displaystyle h_{s}(x)=\Phi \ \%\ 360}$${\displaystyle x\in \{{\text{IP-adres, UUID}}\}}$${\displaystyle h_{s}(x)=\theta}$${\displaystyle {\text{server-ID}}}$${\displaystyle \theta}$${\displaystyle \theta}$${\displaystyle {\text{server-ID}}}$${\displaystyle {\text{server-ID}}}$${\displaystyle \theta}$

• Een server uit cluster verwijderen

Zoek de opvolger van in de BST, verplaats de BLOB's van naar de opvolgerserver. Als er geen opvolger is, verplaats dan de BLOB's naar de kleinste van de s.${\displaystyle \theta}$${\displaystyle \theta}$${\displaystyle \theta}$${\displaystyle {\text{server-ID}}}$

Reductie variantie

Om scheefheid van meerdere knooppunten binnen de radiaal te voorkomen, die optreden als gevolg van een gebrek aan willekeur in de distributie van de servers binnen het cluster, worden meerdere labels gebruikt. Die dubbele labels worden "virtuele knooppunten" genoemd, dat wil zeggen meerdere labels die verwijzen naar een enkel "echt" label of server binnen het cluster. Het aantal virtuele knooppunten of dubbele labels dat voor een bepaalde server binnen een cluster wordt gebruikt, wordt het "gewicht" van die bepaalde server genoemd.

Praktische uitbreidingen

Om in de praktijk effectief gebruik te maken van consistente hashing voor load balancing zijn een aantal uitbreidingen op de basistechniek nodig. In het bovenstaande basisschema, als een server uitvalt, worden alle BLOB's opnieuw toegewezen aan de volgende server met de klok mee, waardoor de belasting van die server mogelijk wordt verdubbeld. Dit is misschien niet wenselijk. Om een ​​meer gelijkmatige herverdeling van BLOB's bij serverstoringen te garanderen, kan elke server naar meerdere locaties in de eenheidscirkel worden gehasht. Wanneer een server uitvalt, worden de BLOB's die aan elk van zijn replica's op de eenheidscirkel zijn toegewezen, opnieuw toegewezen aan een andere server met de klok mee, waardoor de BLOB's gelijkmatiger worden verdeeld. Een andere uitbreiding betreft een situatie waarin een enkele BLOB "hot" wordt en een groot aantal keren wordt benaderd en op meerdere servers moet worden gehost. In deze situatie kan de BLOB worden toegewezen aan meerdere aangrenzende servers door de eenheidscirkel met de klok mee te doorlopen. Een meer complexe praktische overweging ontstaat wanneer twee BLOB's dicht bij elkaar in de eenheidscirkel worden gehasht en beide tegelijkertijd "heet" worden. In dit geval gebruiken beide BLOB's dezelfde set aangrenzende servers in de eenheidscirkel. Deze situatie kan worden verbeterd door elke BLOB een andere hash-functie te kiezen voor het toewijzen van servers aan de eenheidscirkel.

Vergelijking met Rendezvous Hashing en andere alternatieven

Rendezvous-hashing , ontworpen in 1996, is een eenvoudigere en meer algemene techniek en maakt volledig gedistribueerde overeenstemming mogelijk over een reeks opties uit een mogelijke reeks opties. Het kan in feite worden aangetoond dat consistent hashen een speciaal geval is van rendez-vous hashing. Vanwege zijn eenvoud en algemeenheid wordt Rendezvous Hashing nu in veel toepassingen gebruikt in plaats van Consistent Hashing. ${\displaystyle k}$${\displaystyle n}$

Als sleutelwaarden altijd monotoon toenemen , kan een alternatieve benadering met behulp van een hashtabel met monotone sleutels geschikter zijn dan consistente hashing.

Complexiteit

Asymptotische tijdcomplexiteit voor knooppunten (of slots) en sleutels ${\displaystyle N}$${\displaystyle K}$

	Klassieke hasjtafel	Consistente hashing
een knooppunt toevoegen	${\displaystyle O(K)}$	${\displaystyle O(K/N+\log N)}$
een knoop verwijderen	${\displaystyle O(K)}$	${\displaystyle O(K/N+\log N)}$
een sleutel toevoegen	${\displaystyle O(1)}$	${\displaystyle O(\log N)}$
een sleutel verwijderen	${\displaystyle O(1)}$	${\displaystyle O(\log N)}$

Het zijn gemiddelde kosten voor herverdeling van sleutels en de complexiteit voor consistent hashen komt van het feit dat een binaire zoekopdracht tussen knooppuntenhoeken vereist is om het volgende knooppunt op de ring te vinden. ${\displaystyle O(K/N)}$${\displaystyle O(\log N)}$

Voorbeelden

Bekende voorbeelden van consistent hashing-gebruik zijn onder meer:

• Couchbase geautomatiseerde gegevenspartitionering
• OpenStack's Object Storage Service Swift
• Partitioneringscomponent van Amazon's opslagsysteem Dynamo
• Gegevenspartitionering in Apache Cassandra
• Gegevenspartitionering in Voldemort
• De consistente hash-router van Akka
• Riak , een gedistribueerde database met sleutels
• Gluster , een op een netwerk aangesloten opslagbestandssysteem
• Akamai- netwerk voor inhoudslevering
• Onenigheid chat-applicatie
• Maglev netwerk load balancer
• Gegevenspartitionering in Azure Cosmos DB

Referenties

• Roughgarden, Tim; Valiant, Gregory (28 maart 2021). "De moderne algoritmische toolbox, inleiding tot consistent hashen" (PDF) . Stanford-universiteit . Gearchiveerd (PDF) van het origineel op 25 juli 2021 . Ontvangen 7 oktober 2021 .
• Moitra, Ankur (10 februari 2016). "Geavanceerde algoritmen, 6.854" (PDF) . Massachusetts Instituut voor Technologie . Gearchiveerd (PDF) van het origineel op 13 april 2021 . Ontvangen 8 oktober 2021 .

Externe links

• Consistente hashing begrijpen
• Consistent hashen door Michael Nielsen op 3 juni 2009
• Consistente hashing, Danny Lewin en de creatie van Akamai
• Jump Consistent Hashing: een snel, minimaal geheugen, consistent hash-algoritme
• Rendezvous Hashing: een alternatief voor Consistent Hashing
• Implementaties in verschillende talen:
  • C
  • C++
  • C#
  • Erlang
  • Gaan
  • Java
  • PHP
  • Robijn
  • Python
  • Python (opnieuw)
  • Perl
  • Perl6