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

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

Какое-то перевернутое хранилище?

Есть ли что-то, что можно сделать с Postgres?

При необходимости я готов откатить собственное хранилище.

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

Детали:

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

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

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

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

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

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

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

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

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

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


person Philippe Ombredanne    schedule 15.03.2011    source источник
comment
В наши дни 128-битный хеш на самом деле не является криптографическим. Вы пробовали НЕ использовать индексы, а разбивать на разделы, скажем, на основе первых 8 бит хеша?   -  person Tyler Eaves    schedule 15.03.2011
comment
@Tyler 128 бит MD5 или усеченный SHA1 для меня - приличная криптовалюта. По крайней мере, он хорошо использует диапазон клавиш. Я пробовал не использовать индексы, и производительность поиска ужасна. Не могли бы вы подробнее рассказать о разделении ключей?   -  person Philippe Ombredanne    schedule 15.03.2011
comment
Так что используйте индексы и возьмите дисковое пространство. Оптимизируйте по скорости или пространству, выберите один.   -  person Tyler Eaves    schedule 15.03.2011
comment
@Tyler: спасибо, но имхо есть место как для оптимизации скорости, так и для оптимизации пространства, и, честно говоря, в этом масштабе они начинают тесно связаны друг с другом: меньше места означает больше скорости   -  person Philippe Ombredanne    schedule 15.03.2011


Ответы (1)


Вы можете создать таблицу только с идентификатором и хешем, а другие данные - с индексом, метаданными и hashId. Таким образом вы можете предотвратить запись одного и того же хэша в таблицу до 100 тысяч раз.

person Tokk    schedule 15.03.2011
comment
Интересно, просто. Это действительно имеет смысл! - person Philippe Ombredanne; 15.03.2011
comment
Есть ли индексы лучше, чем btrees для хеш-индекса? - person Philippe Ombredanne; 15.03.2011
comment
Я играл с этим подходом, плюс построил перевернутое хранилище в postgres (также известную как таблица ключ / значение со значением, представляющим собой массив кортежей, расширенных при обновлении с помощью указателей, на самом деле список публикаций) ... они обеспечивают интересное уменьшение размера, да создание Время / update действительно замедляется: теперь я действительно ошибаюсь в пользу реального и специализированного перевернутого контейнера хранения, такого как zettair, sphinx или xapian. - person Philippe Ombredanne; 30.03.2011