Во-первых, вы хотите рассмотреть ключи, с помощью которых осуществляется доступ к данным. Именно эти ключи вы хотите хэшировать - и, если вы знаете точные ключи, к которым вы хотите получить доступ, вы можете хэшировать их, чтобы определить, какой сервер запрашивать, что устраняет необходимость запрашивать каждый сервер.
Ситуация усложняется, если вы не знаете точных ключей (как я подозреваю в вашей ситуации) - LSH генерирует полный порядок для ваших записей - где похожие записи могут (но не гарантировано) иметь одинаковый хеш , Я считаю это, например, отображением гиперплоскостей по длине их нормального вектора от начала координат ... отсюда, например, если выполняется поиск аналогичной (но не идентичной) гиперплоскости с такой, которая находится между 4 и 5 единицы от начала координат, хорошее место, чтобы начать искать среди других гиперплоскостей между 4 и 5 единицами от начала координат. Следовательно, если это «расстояние от источника» является вашей хеш-функцией, чувствительной к местоположению, вы можете осколить ваши данные, используя ее, и, тем самым - вы можете уменьшить нагрузку (увеличивая задержку в худшем случае), выполнив поиск осколок с соответствующим «расстоянием от происхождения» LCH. С этим конкретным LCH, где сходство линейно коррелирует с хешем, было бы возможно получить окончательный результат при доступе только к подмножеству распределенных серверов. Это не относится ко всем функциям LSH.
ИМХО, все зависит от вашей функции LSH - и выбор зависит от специфики вашего приложения.