imported>Saehrimnir: BKL Fix

2025-07-28T07:40:57Z

BKL Fix

Neue Seite

Eine '''verteilte Hashtabelle''' ({{enS|distributed hash table}}, DHT) ist eine [[Datenstruktur]], die beispielsweise verwendet wird, um den Speicherplatz einer Datei in einem [[Peer-to-Peer|P2P-System]] effizient zu verteilen.

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 Hashfunktion|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:
* [[Hardware-Fehlertoleranz|Fehlertoleranz]]: Das System sollte zuverlässig funktionieren, auch wenn Knoten ausfallen oder das System verlassen.
* [[Lastverteilung (Informatik)|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 [[Nummerung|Schlüssel]] in einem [[Linearität (Mathematik)|linearen]] [[Zielmenge|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 [[Kommunikationsprotokoll|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 [[Routingtabelle]]n.

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 (Rechnernetz)|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 [[Euklidischer Raum|euklidischen Raum]] platziert, könnte den Knoten mit dem geringsten [[Euklidischer Abstand|euklidischen Abstand]] zu einem Schlüssel wählen. Die Routingtabellen sollen es jedem Knoten erlauben, den nächsten Knoten zu einem Schlüssel in [[Landau-Symbole|''O''(log ''n'')]] Suchschritten zu erreichen.

Durch eine generische Schnittstelle, die nur zwei Funktionen <code>publish(Schlüssel, Inhalt)</code> und <code>lookup(Schlüssel)</code> 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 [[Konsistente Hashfunktion|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 [[Hashtabelle]]n 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 <math>\delta(k_1, k_2)</math> verwendet. Diese gibt die Distanz zwischen zwei Schlüsseln <math>k_1</math> und <math>k_2</math> an. Die Distanz ist dabei unabhängig von der geographischen Distanz oder der Latenz im Netzwerk. Außerdem erhält jeder Knoten <math>x</math> des Netzwerks einen Schlüssel, welchen wir seinen Identifikator <math>i_x</math> (ID von Knoten <math>x</math>) nennen. Jeder Knoten ist dann für die Speicherung derer Elemente zuständig, deren Distanz zu seiner ID am geringsten ist: <math>x = \operatorname{argmin}_y \delta(k, i_y)</math>.

Beispielsweise setzt Chord konsistentes Hashing ein, wobei die Knoten als Punkte auf einem Kreis und <math>\delta (k_{1},k_{2})</math> als der Kreisbogen von <math>k_1</math> nach <math>k_2</math> 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 <math>i_1</math> und <math>i_2</math> zwei im Kreis aufeinander folgende Knoten-IDs sind, dann ist der Knoten <math>i_1</math> für alle Schlüssel zwischen <math>i_1</math> und <math>i_2</math> zuständig.

=== Rendezvous-Hashing ===
Beim Rendezvouz-Hashing benutzen alle Clients, welche einen Schlüssel auf einen der <math>n</math> Knoten abbilden wollen, die gleiche, zu Beginn gewählte Hashfunktion <math>h()</math>. Außerdem haben alle Clients die gleiche Liste von IDs <math>\{S_1, S_2, ..., S_n \}</math>, eine für jeden Knoten. Um den richtigen Knoten für einen Schlüssel <math>k</math> zu bestimmen, werden zunächst <math>n</math> Hash-Gewichte <math>w_1 = h(S_1, k),\ w_2 = h(S_2, k),\ ...,\ w_n = h(S_n, k)</math> berechnet. Der Schlüssel wird dann mit dem dem Maximum dieser Werte entsprechenden Knoten assoziiert. Ein Knoten mit ID <math>S_x</math> ist also für alle Schlüssel <math>k_m</math> zuständig, deren Hash-Gewicht <math>h(S_x, k_m)</math> 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|Schwarmintelligenz-Paradigma]] beruht.<ref>{{cite journal |last1=Forestiero |first1=Agostino |last2=Leonardi |first2=Emilio |last3=Mastroianni |first3=Carlo |last4=Meo |first4=Michela |title=Self-Chord: A Bio-Inspired P2P Framework for Self-Organizing Distributed Systems |journal=IEEE/ACM Transactions on Networking |date=2010-10 |volume=18 |issue=5 |pages=1651–1664 |doi=10.1109/TNET.2010.2046745 |url=http://porto.polito.it/2370172/ |language=en }}</ref> 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 <math>k</math> weiß jeder Knoten entweder die ID des Knotens, der für <math>k</math> zuständig ist, oder er hat einen Link zu einem Knoten, dessen ID näher an <math>k</math> ist, definiert durch ein Distanzmaß in Abschnitt Partitionierung des Schlüsselraums. Eine Nachricht kann dann einfach an den zuständigen Knoten von <math>k</math> geroutet werden: Bei jedem Schritt wird die Nachricht an denjenigen Knoten weitergeleitet, dessen ID <math>k</math> 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.

{| class="wikitable"
|-
! Max. Knotengrad !! Max. Routenlänge !! Benutzt in !! Bemerkung
|-
| <math>O(1)</math> || <math>O(n)</math> || || Schlechtestmögliche Routenlänge, Anfragen werden sehr langsam
|-
| <math>O(\log n)</math> || <math>O(\log n)</math> || [[Chord (Peer-to-Peer)|Chord]] <br/> [[Kademlia]] <br/> [[Pastry (DHT)|Pastry]] <br/> [[Tapestry (DHT)|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)
|-
| <math>O(\log n)</math> || <math>O(\log n/\log (\log n))</math> || [[Koorde]] ||
Wohl komplexere Implementierung aber Anfragen können schneller sein (niedrigere Worst-Case-Schranke)
|-
| <math>O(\sqrt{n})</math> || <math>O(1)</math> || ||
Höchste lokale Speicherplatzanforderungen, hohe Kommunikationslast nach Beitritt und Austritt eines Knotens

|}

<math>O(\log n)</math> 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<ref>{{Cite book |url=https://infoscience.epfl.ch/record/130838?ln=en |title=Designing peer-to-peer overlays a small-world perspective |author=Sarunas Girdzijauskas |date=2009 |publisher=EPFL |language=en}}</ref>.

Die maximale Routenlänge ist eng verwandt mit dem [[Durchmesser (Graphentheorie)|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<ref>{{cite web |url=http://maite71.upc.es/grup_de_grafs/table_g.html |title=The (Degree,Diameter) Problem for Graphs |publisher=Maite71.upc.es |accessdate=2012-01-10 |archiveurl=https://web.archive.org/web/20120217054532/http://maite71.upc.es/grup_de_grafs/table_g.html/ |archivedate=2012-02-17 |url-status=dead |language=en}}</ref>. Die Routenlänge kann auch größer als der Durchmesser sein, da der greedy Routingalgorithmus kürzeste Pfade eventuell nicht findet<ref>Gurmeet Singh Manku, Moni Naor, Udi Wieder: [http://citeseer.ist.psu.edu/naor04know.html "Know thy Neighbor's Neighbor: the Power of Lookahead in Randomized P2P Networks"]. Proc. STOC, 2004.</ref>.

=== 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.<ref>Ali Ghodsi: {{Webarchiv |wayback=20070522060750 |url=http://www.sics.se/~ali/thesis/ |text=Distributed k-ary System: Algorithms for Distributed Hash Tables}}. KTH – Royal Institute of Technology, 2006.</ref> 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<ref>{{cite journal |last1=Castro |first1=Miguel |last2=Costa |first2=Manuel |last3=Rowstron |first3=Antony |title=Should we build Gnutella on a structured overlay? |journal=ACM SIGCOMM Computer Communication Review |date=2004-01-01 |volume=34 |issue=1 |pages=131 |doi=10.1145/972374.972397 |url=http://nms.lcs.mit.edu/HotNets-II/papers/structella.pdf |language=en }}</ref>, das Flooding und Random Walks auf einem Pastry-Overlay implementiert, sowie DQ-DHT, das einen dynamischen Query-Suchalgorithmus über einem Chord-Netzwerk implementiert.<ref>{{cite journal |last1=Talia |first1=Domenico |last2=Trunfio |first2=Paolo |title=Enabling Dynamic Querying over Distributed Hash Tables |journal=Journal of Parallel and Distributed Computing |date=2010-12 |volume=70 |issue=12 |pages=1254–1265 |doi=10.1016/j.jpdc.2010.08.012 |language=en }}</ref>

== 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 <math>b</math> 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 <math>O(b + n)</math> Zeit mit [[Bucketsort]] möglich, wobei <math>n</math> 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.<ref>{{Literatur |Autor=Peter Sanders, Kurt Mehlhorn, Martin Dietzfelbinger, Roman Dementiev |Titel=Sequential and Parallel Algorithms and Data Structures |Verlag=Springer |Seiten=135 f.}}</ref>

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 (DHT)|KAD]] – Entwicklung des [[eMule]]-Entwicklungsteams, basierend auf dem Kademlia-Algorithmus, um die mit der Zeit ausfallenden Server des [[eDonkey2000]]-Netzwerks zu ersetzen.
** [[Mojito DHT|Mojito]] – Entwicklung des [[LimeWire]]-Entwicklungsteams zur schnellen Quellenermittlung innerhalb des [[Gnutella]]-Netzwerks.

== Anwendungen ==
=== DHTs zur Datenspeicherung ===
* [https://github.com/savoirfairelinux/opendht OpenDHT]
* [http://www.bamboo-dht.org/ Bamboo]
* [http://www.pdos.lcs.mit.edu/chord/ The Chord/DHash Project]
* [http://www.freepastry.org/ FreePastry]
* [http://tomp2p.net/ TomP2P]

=== Software ===
* apt-p2p ([[Paketverwaltung]]ssystem): Verteiltes Update auf Basis von [[Advanced Packaging Tool|apt]]
* [[Vuze]]: [[BitTorrent]]-Client
* [[BitComet]]: [[BitTorrent]]-Client
* [[BitTorrent (Client)|BitTorrent]] (ab Version 4.1.0)
* [[Coral (Netzwerk)|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 (DHT)|Kad]]
* [[Free Download Manager]]: freier [[Download-Manager]], der auch [[BitTorrent]] und DHT beherrscht
* [[Hyphanet (Software)|Freenet]]: Anonymer [[Datenspeicher]].
* [[Halite]]: [[BitTorrent]]-Client
* [[KTorrent]]: [[BitTorrent]]-Client
* [[LimeWire]] (Name: [[Mojito DHT|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 (Protokoll)|Tox]]: Instant Messenger
* [[Transmission (Software)]]: [[BitTorrent]]-Client

* [[YaCy]]: verteilte [[Suchmaschine]]

=== DHT-Forschung ===
* {{Toter Link | date= 2017-11-23 | url=http://iris.csail.mit.edu/ | text=Project IRIS }} (Infrastructure for Resilient Internet Systems)

== Einzelnachweise ==
<references />

[[Kategorie:Datenstruktur]]
[[Kategorie:Hash]]

Verteilte Hashtabelle - Versionsgeschichte

imported>Saehrimnir: BKL Fix