Попытка понять, как согласованное хеширование работает лучше на серверах баз данных - PullRequest
0 голосов
/ 23 мая 2019

Что касается дизайна в Twitter или Instagram Разделение на основе идентификатора пользователя: мы можем попытаться сохранить все данные пользователя на одном сервере. При хранении мы можем передать идентификатор пользователя нашей хэш-функции, которая отобразит пользователя на сервер базы данных, где мы будем хранить все твиты пользователя, избранное, подписки и т. Д. При запросе твитов / подписок / избранных пользователя мы может спросить нашу хеш-функцию, где мы можем найти данные пользователя и затем прочитать их оттуда. Этот подход имеет несколько проблем:

Что если пользователь станет горячим? На сервере, содержащем пользователя, может быть много запросов. Эта высокая нагрузка повлияет на производительность нашего сервиса. Со временем некоторые пользователи могут в конечном итоге хранить много твитов или иметь много подписчиков по сравнению с другими. Поддерживать равномерное распределение растущих пользовательских данных довольно сложно. Для выхода из этих ситуаций мы должны либо перераспределить / перераспределить наши данные, либо использовать Sharding на основе TweetID: наша хеш-функция отобразит каждый TweetID на случайный сервер, где мы будем хранить этот Tweet. Чтобы искать твиты, мы должны запросить все серверы, и каждый сервер вернет набор твитов. Централизованный сервер агрегирует эти результаты, чтобы вернуть их пользователю. Давайте посмотрим на пример генерации временной шкалы; Вот количество шагов, которые наша система должна выполнить, чтобы сгенерировать временную шкалу пользователя:

Наш сервер приложений (приложений) найдет всех людей, за которыми следует пользователь. Сервер приложений отправит запрос всем серверам баз данных, чтобы найти твиты от этих людей. Каждый сервер базы данных найдет твиты для каждого пользователя, отсортирует их по времени и вернет лучшие твиты. Сервер приложений объединит все результаты и снова отсортирует их, чтобы вернуть пользователю лучшие результаты. Этот подход решает проблему горячих пользователей, но, в отличие от шардинга по идентификатору пользователя, мы должны запросить все разделы базы данных, чтобы найти твиты пользователя, что может привести к более высоким задержкам.

Мой вопрос: как здесь помогает постоянное хеширование? Последовательное хеширование создает кольцо и пытается поставить равномерно распределенные серверы с виртуальными репликами. Как именно помогает последовательное хеширование для популярного твита или горячей области?

1 Ответ

0 голосов
/ 23 мая 2019

https://www.toptal.com/big-data/consistent-hashing

Согласованное хеширование полезно при добавлении и удалении серверов без перефразирования всей базы данных, а только с использованием только необходимых частей отображения, в среднем перефразирование только с изменением размера k / n, где k - ключи данных, а n - количество серверов.

https://medium.com/vimeo-engineering-blog/improving-load-balancing-with-a-new-consistent-hashing-algorithm-9f1bd75709ed

...