Может ли кто-нибудь дать объяснение, как работает DHT?
Ничего слишком тяжелого, просто основы.
Простое базовое объяснение таблицы распределенного хеша (DHT)
Ответ 1
Хорошо, это принципиально простая идея. DHT предоставляет вам словарь-подобный интерфейс, но узлы распределяются по сети. Трюк с DHT заключается в том, что node, который получает для хранения определенного ключа, определяется путем хэширования этого ключа, так что ваши ведра хэш-таблицы теперь являются независимыми узлами в сети.
Это дает много отказоустойчивости и надежности и, возможно, некоторую производительность, но также вызывает множество головных болей. Например, что происходит, когда node покидает сеть, отказывая или иным образом? И как вы перераспределяете ключи, когда присоединяется node, так что загрузка грубо сбалансирована. Подумайте об этом, как вы равномерно распределите ключи? И когда присоединяется node, как вы избегаете переигрывать все? (Помните, что вам придется делать это в обычной хэш-таблице, если вы увеличиваете количество ковшей).
Одним из примеров DHT, который решает некоторые из этих проблем, является логическое кольцо из n узлов, каждый из которых берет на себя ответственность за 1/n пространства ключей. Как только вы добавите в сеть node, он найдет место на ринге, чтобы сидеть между двумя другими узлами, и берет на себя ответственность за некоторые из ключей в своих дочерних узлах. Красота этого подхода заключается в том, что ни один из других узлов в кольце не затронут; только два узла-брата должны перераспределять ключи.
Например, скажем, в три кольца node первый node имеет ключи 0-10, второй 11-20 и третий 21-30. Если четвертый node приходит и вставляет себя между узлами 3 и 0 (помните, что они находятся в кольце), он может взять на себя ответственность за половину из 3-х ключей, поэтому теперь он имеет дело с 26-30 и node 3 - 21-25.
Существует много других структур наложения, которые используют маршрутизацию на основе контента, чтобы найти правильный node, на котором будет храниться ключ. Поиск ключа в кольце требует одновременного поиска по кольцу node (если вы не держите локальную таблицу поиска, проблемную в DHT из тысяч узлов), которая представляет собой маршрутизацию O (n) -hop. Другие структуры, в том числе дополненные кольца, гарантируют маршрутизацию O (log n) -hop и некоторые претензии к маршрутизации O (1) -hop за счет большего обслуживания.
Прочитайте страницу wikipedia, и если вы действительно хотите узнать немного, посмотрите эту курс в Гарварде, где есть довольно полный список литературы.
Ответ 2
DHT предоставляют интерфейс такого же типа пользователю как обычную хеш-таблицу (смотрите значение по ключу), но данные распределяются по произвольному количеству подключенных узлов. В Википедии есть хорошее базовое введение, которое я бы по сути было изрыгаю, если напишу больше -
Ответ 3
Я бы хотел добавить полезный ответ HenryR, поскольку у меня просто было понимание последовательного хэширования. Нормальный/наивный поиск хэшей - это функция двух переменных, одним из которых является количество ведер. Красота последовательного хэширования заключается в том, что мы исключаем количество ведер "n" из уравнения.
В наивном хэшировании первая переменная является ключом объекта, который будет храниться в таблице. Мы назовем ключ "x". Вторая переменная - это количество ведер, "n". Итак, чтобы определить, в каком ведре/машине хранится объект, вам нужно вычислить: hash (x) mod (n). Поэтому, когда вы меняете количество ведер, вы также меняете адрес, на котором хранится почти каждый объект.
Сравните это с последовательным хешированием. Пусть определим "R" как диапазон хэш-функции. R является лишь некоторой константой. В последовательном хэшировании адрес объекта находится в хеш (x)/R. Поскольку наш поиск больше не является функцией количества ведер, мы получаем меньше переназначений, когда мы меняем количество ведер.
Ответ 4
Посмотрите эту статью в Википедии Или это powerpoint slide
Ответ 5
проверить Amazon Dynamo, он объясняет простую, но новую версию DHT, основанную на согласованном хешировании окружения.