Verteilte Hashtabelle

Eine verteilte Hashtabelle (englisch distributed hash table, DHT) ist eine Datenstruktur, die zum Beispiel dazu genutzt werden kann, den Speicherort einer Datei in einem P2P-System zu speichern. Dabei steht die Dezentralisierung und die Effizienz der Datenspeicherung im Vordergrund.

Die Daten werden möglichst gleichmäßig über die vorhandenen Speicherknoten verteilt. Jeder Speicherknoten entspricht dabei einem Eintrag in der Hashtabelle. Die selbstorganisierende Datenstruktur kann den Ausfall, Beitritt und Austritt von Knoten abbilden. Die Grundlage für verteilte Hashtabellen bilden konsistente Hash-Funktionen.

Man unterscheidet DHTs nach dem Speicherschema. Die Daten können direkt innerhalb der DHT abgelegt werden (direct storage) oder in der DHT kann ein Verweis auf die Daten vorgehalten werden (indirect storage). Direct Storage bietet sich nur für kleine Daten (< 1 kB) an, da sonst das System zu unflexibel werden würde.

Eigenschaften

Eigenschaften von DHTs sind:

• Fehlertoleranz: Das System sollte zuverlässig funktionieren, auch wenn Knoten ausfallen oder das System verlassen.
• Lastenverteilung: Schlüssel werden gleichmäßig auf alle Knoten verteilt.
• Robustheit: Das System sollte „korrekt“ funktionieren können, auch wenn ein Teil (möglicherweise ein Großteil) der Knoten versucht, das System zu stören.
• Selbstorganisation: Es ist keine manuelle Konfiguration nötig.
• Skalierbarkeit: Das System sollte in der Lage sein, auch mit einer großen Anzahl von Knoten funktionsfähig zu bleiben.

Prinzipielle Arbeitsweise

Mittels einer Hashfunktion werden den Datenobjekten Schlüssel in einem linearen Wertebereich vergeben, welcher möglichst gleichmäßig über die Knoten der Knotenmenge verteilt wird. Für jeden Teilbereich des Schlüsselraumes ist dabei mindestens ein Knoten zuständig. Oft sind jedoch auch mehrere Knoten für denselben Bereich verantwortlich, wobei sich die Zuständigkeiten dynamisch ändern. Ein Beitrittsprotokoll regelt die Aufnahme neuer Knoten in das existierende System. Das Protokoll stellt dann die Verbindungen zu den Nachbarknoten her und regelt üblicherweise auch die Konstruktion von Routingtabellen.

Die Routingtabellen werden von den DHT-Knoten zur Ermittlung anderer Knoten benutzt, die für bestimmte Datensätze zuständig sind. Die Definition der „Entfernung“ ist dabei mit der Struktur und der Topologie verbunden und variiert in unterschiedlichen Systemen. Sie muss nicht zwingend mit der physischen Organisation der Knoten übereinstimmen. Eine verteilte Hashtabelle, die ihre Knoten in einem euklidischen Raum platziert, könnte den Knoten mit dem geringsten euklidischen Abstand zu einem Schlüssel wählen. Die Routingtabellen sollen es jedem Knoten erlauben, den nächsten Knoten zu einem Schlüssel in O(log n) Suchschritten zu erreichen.

Durch eine generische Schnittstelle, die nur zwei Funktionen publish(Schlüssel, Inhalt) und lookup(Schlüssel) anbietet, lassen sich die implementierten Algorithmen auswechseln.

Partitionierung des Schlüsselraums

Bei den meisten DHTs geschieht die Abbildung von Schlüsseln auf Knoten mittels einer Variante von konsistentem Hashing oder Rendezvouz-Hashing. Diese beiden Varianten wurden wohl gleichzeitig, aber unabhängig entwickelt, um das DHT-Problem zu lösen.

Sowohl konsistentes Hashing als auch Rendezvouz-Hashing haben die grundlegende Eigenschaft, dass sich bei Beitritt oder Austritt eines Knotens nur die Schlüssel der benachbarten Knoten ändern und alle anderen Knoten nicht beeinträchtigt werden. In konventionellen Hashtabellen hingegen wird bei hinzufügen oder entfernen eines Buckets fast der vollständige Schlüsselbereich neu verteilt. Wenn sich die Zuständigkeit von Datenobjekten ändert, ist eine Daten-Umverteilung notwendig. Diese belastet das Netzwerk und die Datenbandbreite. Deshalb werden DHTs so gestaltet, dass sie auch häufige Ein- und Austritte von Knoten effizient unterstützen können.

Konsistentes Hashing

Beim konsistenten Hashing wird eine Distanzfunktion $\delta (k_{1},k_{2})$ verwendet. Diese gibt die Distanz zwischen zwei Schlüsseln $k_{1}$ und $k_{2}$ an. Die Distanz ist dabei unabhängig von der geographischen Distanz oder der Latenz im Netzwerk. Außerdem erhält jeder Knoten $x$ des Netzwerks einen Schlüssel, welchen wir seinen Identifikator $i_{x}$ (ID von Knoten $x$) nennen. Jeder Knoten ist dann für die Speicherung derer Elemente zuständig, deren Distanz zu seiner ID am geringsten ist: $x=\operatorname {argmin} _{y}\delta (k,i_{y})$.

Beispielsweise setzt Chord konsistentes Hashing ein, wobei die Knoten als Punkte auf einem Kreis und $\delta (k_{1},k_{2})$ als der Kreisbogen von  $k_{1}$ nach $k_{2}$ im Uhrzeigersinn aufgefasst werden. Der kreisförmige Schlüsselraum besteht also aus zusammenhängenden Segmenten, deren Endpunkte die Knoten-IDs sind. Wenn also zum Beispiel $i_{1}$ und $i_{2}$ zwei im Kreis aufeinander folgende Knoten-IDs sind, dann ist der Knoten $i_{1}$ für alle Schlüssel zwischen $i_{1}$ und $i_{2}$ zuständig.

Rendezvous-Hashing

Beim Rendezvouz-Hashing benutzen alle Clients, welche einen Schlüssel auf einen der $n$ Knoten abbilden wollen, die gleiche, zu Beginn gewählte Hashfunktion $h()$. Außerdem haben alle Clients die gleiche Liste von IDs $\{S_{1},S_{2},...,S_{n}\}$, eine für jeden Knoten. Um den richtigen Knoten für einen Schlüssel $k$ zu bestimmen, werden zunächst $n$ Hash-Gewichte $w_{1}=h(S_{1},k),\ w_{2}=h(S_{2},k),\ ...,\ w_{n}=h(S_{n},k)$ berechnet. Der Schlüssel wird dann mit dem dem Maximum dieser Werte entsprechenden Knoten assoziiert. Ein Knoten mit ID $S_{x}$ ist also für alle Schlüssel $k_{m}$ zuständig, deren Hash-Gewicht $h(S_{x},k_{m})$ höher als die Hash-Gewichte aller anderen Knoten für den Schlüssel ist.

Lokalitätserhaltendes Hashing

Lokalitätserhaltendes Hashing stellt sicher, dass ähnliche Schlüssel auch ähnlichen Knoten zugeteilt werden. Dadurch können effizientere Range Queries ermöglicht werden. Dabei kann es allerdings vorkommen, dass die Verteilung des Schlüsselraums auf die Knoten und damit deren Auslastung nicht mehr uniform zufällig ist. Das Framework Self-Chord zum Beispiel macht Objektschlüssel von Knoten-IDs unabhängig und sortiert Schlüssel entlang eines Ringspeichers mit Hilfe eines statistischen Ansatzes, der auf dem Schwarmintelligenz-Paradigma beruht. Das Sortieren stellt sicher, dass benachbarte Knoten für ähnliche Schlüssel zuständig sind und Abfragen wie z. B. Range Queries so in logarithmischer Zeit ausgeführt werden können.

Overlay-Netz

Das Overlay-Netz verbindet die Knoten, sodass diese den jeweiligen zuständigen Knoten für Schlüssel finden können. Dabei hält jeder Knoten in einer Routingtabelle Verbindungen zu anderen Knoten (seinen Nachbarn). Ein Knoten wählt seine Nachbarn entsprechend der Netzwerktopologie (Struktur des Netzwerks).

Alle DHT-Topologien verbindet eine grundlegende Eigenschaft: für jeden Schlüssel $k$ weiß jeder Knoten entweder die ID des Knotens, der für $k$ zuständig ist, oder er hat einen Link zu einem Knoten, dessen ID näher an $k$ ist, definiert durch ein Distanzmaß in Abschnitt Partitionierung des Schlüsselraums. Eine Nachricht kann dann einfach an den zuständigen Knoten von $k$ geroutet werden: Bei jedem Schritt wird die Nachricht an denjenigen Knoten weitergeleitet, dessen ID $k$ am nächsten ist, bis der zuständige Knoten erreicht wird. Dieser Algorithmus ist im Allgemeinen nicht global optimal. Manchmal wird dieses Verfahren Schlüssel-basiertes Routing genannt.

Das Overlay-Netz hat zwei Parameter, welche einen großen Einfluss auf seine Leistung haben. Die maximale Routenlänge sollte klein sein, damit Pakete schnell ankommen, und der maximale Knotengrad sollte klein sein, damit der Overhead pro besuchtem Knoten klein ist. Dabei stehen die beiden Parameter in einem Tradeoff-Verhältnis. Einige typische Verhältnisse sind in der folgenden Tabelle beschrieben.

Max. Knotengrad	Max. Routenlänge	Benutzt in	Bemerkung
$O(1)$	$O(n)$		Schlechtestmögliche Routenlänge, Anfragen werden sehr langsam
$O(\log n)$	$O(\log n)$	Chord Kademlia Pastry Tapestry	Am verbreitetsten aber nicht optimal (Nachbargrad/Routenlänge-Verhältnis). Chord ist die einfachste Version, Kademlia scheint die beliebteste optimierte Variante zu sein (sollte verbesserte durschn. Zeit für Anfragen haben)
$O(\log n)$	$O(\log n/\log(\log n))$	Koorde	Wohl komplexere Implementierung aber Anfragen können schneller sein (niedrigere Worst-Case-Schranke)
$O({\sqrt {n}})$	$O(1)$		Höchste lokale Speicherplatzanforderungen, hohe Kommunikationslast nach Beitritt und Austritt eines Knotens

$O(\log n)$ als maximaler Nachbargrad und maximale Routenlänge ist die am weitesten verbreitete Parametrisierung. Obwohl der Nachbargrad/Routenlänge-Tradeoff bei ihr nicht optimal ist, ermöglicht sie oft eine höhere Flexibilität bei der Wahl der Nachbarn. Viele DHTs nutzen diese Flexibilität, um Nachbarn mit möglichst geringer Latenz im darunterliegenden physikalischen Netzwerk auszuwählen. Im Allgemeinen erstellen DHTs navigierbare kleine-Welt-Netzwerk-Topologien mit dem Tradeoff zwischen Routenlänge und Netzwerkgrad.

Die maximale Routenlänge ist eng verwandt mit dem Durchmesser (des Netzwerks): der maximalen Anzahl Hops in einem beliebigen kürzesten Pfad zwischen zwei Knoten. Die Worst-Case-Routenlänge des Netzwerks ist offensichtlich mindestens so groß wie der Durchmesser, folglich haben DHTs die in der Graphentheorie fundamentale Limitierung des Knotengrad/Durchmesser-Tradeoffs. Die Routenlänge kann auch größer als der Durchmesser sein, da der greedy Routingalgorithmus kürzeste Pfade eventuell nicht findet.

Algorithmen für Overlay-Netze

Neben Routing gibt es viele Algorithmen, welche die Struktur von Overlay-Netzen in DHTs ausnutzen, um Nachrichten an alle Knoten oder eine Teilmenge zu senden. Diese Algorithmen werden von Anwendungen für Overlay-Multicasts, Range Queries oder zum Sammeln von Statistiken eingesetzt. Zwei auf diesem Ansatz basierende Systeme sind Structella, das Flooding und Random Walks auf einem Pastry-Overlay implementiert, sowie DQ-DHT, das einen dynamischen Query-Suchalgorithmus über einem Chord-Netzwerk implementiert.

Implementierungen

Auf vielen Rechnern ist das Senden von Nachrichten deutlich teurer als lokale Hashtabellen-Zugriffe. Deshalb ist eine Bündelung vieler Nachrichten in einen Batch sinnvoll. Die Nachrichten werden unter der Annahme, dass jeder Knoten einen lokalen Batch von maximal $b$ Nachrichten hat, wie folgt gebündelt. Jeder Knoten sortiert seinen lokalen Batch zunächst nach der ID des für die Nachricht zuständigen Knotens. Dies ist in $O(b+n)$ Zeit mit Bucketsort möglich, wobei $n$ die Knotenanzahl in der DHT ist. Falls es in einem Batch mehrere Operationen für denselben Key gibt, wird der Batch noch vor dem Senden reduziert. Zum Beispiel können mehrere Anfragen für denselben Key zu einer reduziert werden oder mehrere inkrement-Operationen zu einer add-Operation. Dies kann mit einer lokalen Hashtable realisiert werden. Schließlich werden die Operationen an die jeweiligen Knoten geschickt.

Derzeit existieren unter anderem folgende Implementierungen verteilter Hashtabellen:

• IPFS
• Kademlia – Strukturen basierend auf diesem Algorithmus existieren in mehreren P2P-Netzwerken, sind allerdings meist nicht untereinander kompatibel. Implementierungen:
  • KAD – Entwicklung des eMule-Entwicklungsteams, basierend auf dem Kademlia-Algorithmus, um die mit der Zeit ausfallenden Server des eDonkey2000-Netzwerks zu ersetzen.
  • Mojito – Entwicklung des LimeWire-Entwicklungsteams zur schnellen Quellenermittlung innerhalb des Gnutella-Netzwerks.

Anwendungen

DHTs zur Datenspeicherung

• OpenDHT
• Bamboo
• The Chord/DHash Project
• FreePastry
• TomP2P

Software

• apt-p2p (Paketverwaltungssystem): Verteiltes Update auf Basis von apt
• Vuze: BitTorrent-Client
• BitComet: BitTorrent-Client
• BitTorrent (ab Version 4.1.0)
• Coral: Verteilungsnetzwerk für Inhalte
• CSpace: Instant Messenger mit Kademlia
• Deluge (BitTorrent-Client)
• eDonkey2000, Name: Overnet
• eMule (ab Version 0.40) und aMule (ab Version 2.1.0), Name: Kad
• Free Download Manager: freier Download-Manager, der auch BitTorrent und DHT beherrscht
• Freenet: Anonymer Datenspeicher.
• Halite: BitTorrent-Client
• KTorrent: BitTorrent-Client
• LimeWire (Name: Mojito)
• MLDonkey (Overnet und Kademlia)
• µTorrent: BitTorrent-Client
• qBittorrent: BitTorrent-Client
• RetroShare: serverloser Instant Messenger, anonymes/Filesharing, Newsgroup, Voice over IP, E-Mail
• rTorrent: BitTorrent-Client
• Tox: Instant Messenger
• Transmission (Software): BitTorrent-Client
• YaCy: verteilte Suchmaschine

DHT-Forschung

• @1@2Vorlage:Toter Link/iris.csail.mit.eduProject IRIS (Seite nicht mehr abrufbar, festgestellt im November 2017. Suche in Webarchiven) (Infrastructure for Resilient Internet Systems)