Russian Qt Forum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как я понял из первого поста, то основная задачи программы быстро проверить уникальность по хешу.
Тогда можно снизить объем занимаемой памяти, за счет путей к файлам. В памяти хранить только хеши и уникальные id путей. А пути загружать только для нужных хешей с диска. И держать их в кеше, что бы не используемые убирались.
Но наверное лучше сразу перейти на БД.

Хм Хм Хм.

Выпал в осадок на третьем компиляторе при сборке leveldb noSql.  Неужели нет никаких стандартов по составлению мейкфайлов?

Вроде пишут что под винду портирована, вот только как её собрать? Чесслово в растерянности. Жуткая всё же вещь этот линукс.

А тут смотрел?
http://code.google.com/p/leveldb/source/browse/WINDOWS?name=windows

Кхм. То ли у меня истерика после отпуска :D  :o ??? :( >:( :-\ :P

Там для 2010, не могу сообразить как для 2008 сотворить. Пробую.

Кхм. Как весело оказывается собирать проекты :) Особенно под x64, особенно с непонятными инклудами :)

PS отложил до вечера. А то чую уже нервничать начинаю :D

Здесь еще такой момент. 2.5 * 150 = заметно меньше даже 1 гига, Возможно (просто возможно, необязательно) падает на попытке выделить слишком большой блок памяти. Напр QHash, насколько я помню, хранит данные 1 блоком. Во всяком случае не все ОC позволяют выделять "сколько хочу" даже если физически память есть.

Igors, вы правы, заметно меньше. Но в довесок к этой информации идёт путь к файлу. Который до 1024 символов к сожалению.

Уважаемый old предложил как раз уменьшить потребление в виде сохранения путей в индексированном контейнере на диске.

Собрал под VS2012 x64. Есть нюансы :).
1. LevelDb качать отсюда: https://nodeload.github.com/Reactive-Extensions/LevelDB/zip/master
Там есть солюшен для сборки
2. Качаем boost 1.53.
3. Если не хотим собирать еще и boost качаем уже собранные lib отсюда
http://boost.teeks99.com/bin/boost_1_53_0-vc64-bin.exe
4. Распаковываем boost и прописываем в переменную окружения BOOST путь к распакованному boost
5. Открываем LevelDB.sln в VS и проверяем, что в путях для lib указан правильный путь к boost lib.
6. Добавляем конфигурацию для x64 (если нужно), Build Solution - в папке x64\Release получаем LevelDB.dll

P.S. Подозреваю, что в Linux это всё собралось бы парой команд в консоли.

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

PS да и есть у меня подозрение непроверенное что там файл проекта VS2012. Который для VS2008 является "просто неизвестной версией файла проекта".

Точно, что не 2012 - у меня конвертировалось под 2012. Но может быть 2010 :(