Работа с большими объёмами данных.

[Bepec]

Приветствую уважаемых знатоков и новичков

Имеется программа для работы с файлами. Собственно часть её работы - проверка файлов на уникальность и создание списков файлов.

Данные сохраняются в структуру данных, содержащую путь к файлу и его хеш.  (примерно 150 символов в общем).

Проблема: При количестве файлов более 2,5 млн (100 гб файлов) программа потребляет более 2 гб памяти и вываливается в эксепшн (ограничение x86 программ).

Собственно я вижу два варианта решения проблемы:

1) Забитие данных в базу Sql и работа с ней (запросами). Но в этом случае страдает скорость при проверке и заполнении базы.

2) Разбитие данных на куски по алфавиту (ориентируемся на хеш) и обрабатывает только ту часть, что подпадает под условие. Но в это случае проблема решается % на 20 и нет никаких гарантий, что хеши на букву А не превысят цифру 2,5 млн файлов.

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

[Igors]

2) Разбитие данных на куски по алфавиту (ориентируемся на хеш)

Правильная идея, но без алфавита. Данные разбиваются на блоки (страницы). Если блока нет в памяти - он подгружается с диска. При этом, возможно, наименее используемый блок сбрасывается на диск.   

[_OLEGator_]

А чем собственно второй вариант отличается от создания своей версии БД?

[xokc]

В общем-то ничем. Любой современный движок БД умеет кешировать страницы данных. Правда тут я бы noSql (key-value) БД использовал если сложные выборки не нужны.

[Bepec]

Собственно во втором варианте имеется проблема. Нужно проверять уникальность, т.е. проходить по всему массиву и проверять совпадение.

noSql я не пробовал. Не можете посоветовать простую библиотеку (простую в смысле доступную (free) и желательно с документацией и примерами).

[Old]

1) Забитие данных в базу Sql и работа с ней (запросами). Но в этом случае страдает скорость при проверке и заполнении базы.

Ну вы же в уже сами чувствуете, что пришло время использовать нормальное хранилище?

А так, переходите на 64 битную платформу, там таких ограничений нет.

[Igors]

[А так, переходите на 64 битную платформу, там таких ограничений нет.

Популярная иллюзия за которую приходится платить (иногда дорого)

[Old]

Популярная иллюзия за которую приходится платить (иногда дорого)

В вашем случае я не удивлен...

То Верес: То дядька пугает...

[Bepec]

Я согласен с igors - пока что > 70% компов x86 ) А 4 гб будет явно нехватать для 7 млн файлов

[Igors]

Популярность заблуждения в том что, мол, "вот теперь у меня 150 терабайт адресного пр-ва - и похрен мне все отказы памяти". Да, в 64 это возможно - но увы, за это часто приходится заплатить скоростью работы которая падает в десять и более раз (вся силенка уходит в свап)

[Old]

(вся силенка уходит в свап)

Ну с дуру можно и ... поломать.

[Bepec]

То есть совет простой - или x64, или noSql db?

[Old]

То есть совет простой - или x64, или noSql db?

Для хранения и обработки больших объемов информации БД подходят лучше всего.

[xokc]

noSql я не пробовал. Не можете посоветовать простую библиотеку (простую в смысле доступную (free) и желательно с документацией и примерами).

Сам лично с noSql  в таком контексте как у тебя не пользовался. Под такую задачу вроде бы MemcahedDB подходит, но это - скорее сервер БД, использующий в качестве хранилища BerkeleyDB. Если софт однопользовательский, то с BerkeleyDB я бы и начал. Интересно было бы сравнить результаты по производительности/памяти после внедрения такой БД.

[Bepec]

Мда, сколько открывается перед программистом, когда объём данных превышает четыре гига

Попробую noDb присобачить...