Какую базу данных или механизм хранения использовать для хранения множества уникальных предметов?

Я подумываю написать веб-сканер, который просто собирает URL-адреса страниц и ничего более (для проекта архивирования), но у меня есть проблемы с поиском правильного способа хранения результатов.

Требования заключаются в том, что какой бы механизм хранения ни использовался, он мог обрабатывать сотни тысяч элементов (желательно с возможностью добавления метаданных к каждой записи, хотя это и не обязательно), и чтобы существующие элементы можно было игнорировать (чтобы избежать дублирования) без значительное снижение производительности.

Двигатели, на которые я смотрел:

  • MySQL: становится значительно медленнее проверять существующие элементы по мере роста базы данных.
  • SQLite: та же проблема, что и выше, но еще хуже.
  • memcache и Redis: набор данных может стать достаточно большим, чтобы сделать хранение в ОЗУ невозможным.
  • MongoDB: не уверен, будет ли производительность приемлемой, если большая часть набора данных хранится на диске, на основе объяснение на их веб-сайте.

Что вы думаете о пригодности MongoDB (поскольку у меня нет опыта работы с большими наборами данных в MongoDB), и знаете ли вы о каких-либо лучших (бесплатных) механизмах хранения, существующих для этой цели?


person Sven Slootweg    schedule 22.11.2012    source источник


Ответы (2)


Похоже, решение NoSQL вам подойдет.

Тем более, что вы просто хотите куда-то сбрасывать различные гибкие данные под «id» URL-адреса.

Я использовал lucene, но mongo тоже хороший выбор.

person Bohemian♦    schedule 22.11.2012
comment
Не будет ли MongoDB вызывать проблемы с большими наборами данных на машине с небольшим объемом оперативной памяти? Я не знаю особенностей MongoDB, но кое-что припомню, чтобы он работал (в основном?) Из ОЗУ. - person Sven Slootweg; 22.11.2012
comment
Насколько мало оперативной памяти мы говорим? - person Bohemian♦; 22.11.2012
comment
Этого достаточно для запуска базы данных nosql - person Bohemian♦; 24.11.2012

Если вы используете традиционную СУБД, вы можете создать уникальный ключ на основе хэша ваших данных (например, хешировать URL-адрес с помощью md5 или sha1). Это сохранит уникальный ключ маленьким (ish) и должно улучшить производительность.

Мне нравится PostgreSQL - возможно, вы захотите провести с ним несколько тестов.

Изменить: (см. комментарии) Хорошо, возможно, избегайте md5 в этот день и в возрасте (:

person jwd    schedule 22.11.2012
comment
+1. Вся индустрия основана на такой идее (дедупликация данных). Но, пожалуйста, не MD5. - person dmeister; 22.11.2012
comment
@dmeister Что бы вы посоветовали для хеширования? - person Sven Slootweg; 22.11.2012
comment
SHA-256 должен быть хорошим выбором. MD5 просто может создать проблемы, потому что я могу легко вычислить хеш-коллизии. Это может вызвать проблемы (потеря данных, безопасность) в определенных ситуациях. Хотя хеш-коллизии все еще возможны с SHA-256, они не могут быть созданы специально (2012) и очень, очень, очень маловероятно произойдут случайно (парадокс дня рождения). - person dmeister; 22.11.2012