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.

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 ${\displaystyle k}$ weiß jeder Knoten entweder die ID des Knotens, der für ${\displaystyle k}$ zuständig ist, oder er hat einen Link zu einem Knoten, dessen ID näher an ${\displaystyle k}$ ist, definiert durch ein Distanzmaß in Abschnitt Partitionierung des Schlüsselraums. Eine Nachricht kann dann einfach an den zuständigen Knoten von ${\displaystyle k}$ geroutet werden: Bei jedem Schritt wird die Nachricht an denjenigen Knoten weitergeleitet, dessen ID ${\displaystyle 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
${\displaystyle O(1)}$	${\displaystyle O(n)}$		Schlechtestmögliche Routenlänge, Anfragen werden sehr langsam
${\displaystyle O(\log n)}$	${\displaystyle 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)
${\displaystyle O(\log n)}$	${\displaystyle O(\log n/\log(\log n))}$	Koorde	Wohl komplexere Implementierung aber Anfragen können schneller sein (niedrigere Worst-Case-Schranke)
${\displaystyle O({\sqrt {n}})}$	${\displaystyle O(1)}$		Höchste lokale Speicherplatzanforderungen, hohe Kommunikationslast nach Beitritt und Austritt eines Knotens

${\displaystyle 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.

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 ${\displaystyle 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 ${\displaystyle O(b+n)}$ Zeit mit Bucketsort möglich, wobei ${\displaystyle 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

Einzelnachweise

1. ↑ Agostino Forestiero, Emilio Leonardi, Carlo Mastroianni, Michela Meo: Self-Chord: A Bio-Inspired P2P Framework for Self-Organizing Distributed Systems. In: IEEE/ACM Transactions on Networking. 18. Jahrgang, Nr. 5, Oktober 2010, S. 1651–1664, doi:10.1109/TNET.2010.2046745 (polito.it). 
2. ↑ Sarunas Girdzijauskas: Designing peer-to-peer overlays a small-world perspective. EPFL, 2009 (epfl.ch). 
3. ↑ The (Degree,Diameter) Problem for Graphs. Maite71.upc.es, archiviert vom Original am 17. Februar 2012; abgerufen am 10. Januar 2012. 
4. ↑ Gurmeet Singh Manku, Moni Naor, Udi Wieder: "Know thy Neighbor's Neighbor: the Power of Lookahead in Randomized P2P Networks". Proc. STOC, 2004.
5. ↑ Ali Ghodsi: Distributed k-ary System: Algorithms for Distributed Hash Tables (Memento vom 22. Mai 2007 im Internet Archive). KTH – Royal Institute of Technology, 2006.
6. ↑ Miguel Castro, Manuel Costa, Antony Rowstron: Should we build Gnutella on a structured overlay? In: ACM SIGCOMM Computer Communication Review. 34. Jahrgang, Nr. 1, 1. Januar 2004, S. 131, doi:10.1145/972374.972397 (mit.edu [PDF]). 
7. ↑ Domenico Talia, Paolo Trunfio: Enabling Dynamic Querying over Distributed Hash Tables. In: Journal of Parallel and Distributed Computing. 70. Jahrgang, Nr. 12, Dezember 2010, S. 1254–1265, doi:10.1016/j.jpdc.2010.08.012. 
8. ↑ Peter Sanders, Kurt Mehlhorn, Martin Dietzfelbinger, Roman Dementiev: Sequential and Parallel Algorithms and Data Structures. Springer, S. 135 f.