Советы по созданию очень большой базы данных хешей

Вопрос: С каким решением или советами вы могли бы иметь дело с очень большой (многотерабайтной) базой данных, проиндексированной на сильных хэшах с высокой избыточностью?

Что-то вроде перевернутого хранилища?

Можно ли что-нибудь сделать с Postgres?

Я готов откатить собственное хранилище, если это необходимо.

(Подсказка: должен быть открытый исходный код, без Java, должен работать в Linux, должен быть дисковым, предпочтительно C / C ++ / Python)

Подробности:

Мне нужно создать очень большую базу данных, в которой каждая запись содержит:

• произвольные метаданные (некоторые текстовые поля), включая некоторый первичный ключ
• , один хэш (128-битный хэш, сильный MD5-подобный)

Объем записей - это то, что я будет считаться довольно большим: от нескольких 10 до 100 миллиардов). Существует значительная избыточность хэшей по строкам (более 40% записей имеют общий хеш-код по крайней мере с другой записью, некоторые хеш-значения существуют в 100 КБ записях )

Основное использование - поиск по хешу, затем получение метаданных. Вторичное использование - поиск по первичному ключу, а затем получение метаданных.

Это база данных аналитического типа, поэтому общая нагрузка средняя, ​​в основном чтение, мало записей, в основном пакетные записи.

Текущий подход заключается в использовании Postgres с индексом по первичному ключу и индексом по хеш-столбцу. Таблица загружается пакетно с выключенным индексом по хешу.

Все индексы являются b-деревьями. Индекс в столбце хеширования становится огромным, до размеров самой таблицы. Для таблицы размером 120 ГБ на воссоздание индекса уходит около суток. Однако производительность запросов неплохая.

Проблема заключается в том, что прогнозируемый размер целевой базы данных будет более 4 ТБ на основе тестов с меньшим набором данных в 400 ГБ, что составляет около 10% от общего целевого объема. После загрузки в Postgres более 50% хранилища, к сожалению, используется индексом SQL в столбце хэша.

Это слишком велико. И я считаю, что избыточность хешей - это возможность хранить меньше.

Обратите внимание, что, хотя это описывает проблему, есть несколько таких таблиц, которые необходимо создать.