О больших архивах

[vitus_wagner]

Попробовал тут разгрести описанным в предыдущем посте скриптом архив либрусэка завалявшийся с 2009 года.

Получилось - из менее чем 200000 книг 2176 попросту not well-formed XML. В основном от того что народ использует знаки больше-меньше (даже не сдвоенные) в вместо кавычек-елочек, а какие-то распространенные тулзы генерации FB2 это не отслеживают и не заменяют встретившийся в тексте зна < на соответствующий entity. Аналогичные проблемы возникают с амперсэндами.

Ну и плюс к тому куча пробелов, неразрывных пробелов, кавычек, скобочек в полях "имя автора". В принципе можно скрипт пофиксить, чтобы все символы, не участвующие в сортировке по библиографическим правилам, резал.

Но вообще, конечно, все это добро нуждается в вычитки и чистке от артефактов сканирования и распознавания. Поэтому я и держу настолько маленькую библиотеку, что в ней мне все-таки не лень слазить и руками исправить ошибки в XML и метаданных.

А то и пройтись по всему тексту и правильно оформить тэгами разбиение на главы.

Comments

[vitus_wagner]

Речь с самого начала не о файлохранилище либрусека. А о МОЕМ файлохранилище.
В котором какой-то древний архив либрусэка составляет 4 процента.

Если вы не умеете пользоваться файловой системой, то у вас и sql-база будет тормозить секунды на простейших запросах.

Файловая система иерархична. Разбейте ее на 3 уровня, и миллион превратится в сотню.

Что касается sql-Я то я могу точно сказать, что им еще надо уметь пользоваться. Работая в компании, которая занимается как раз базами данных причем и консалтингом тоже, я имею об этом некоторое представление.

Я не понимаю, что вы собираетесь искать по паре миллионов файлов? Цитату? По всей базе без разбора?
Но тут вас никакие архивы не спасут.

Если же нужно найти книгу, по автору и заглавию или по любой другой метаинформации вынесенной в структуру файловой системы, то никакого "поиска по 2 миллионам" тут нет. Вы идете и берете
Шаг первый - имя автора начинается с этой буквы. Вариантов примерно полсотни.
Шаг второй - имя автора такое-то. Внутри буквы здесь может быть до нескольких тысяч вариантов, но современные файловые системы с таким вполне справляются. Хотя вот тут человек описывал создание префиксов из 4-х букв и группировку их в более-менее равные по численности группы. Правда, в такой схеме completion работать не будет, и этот шаг придется делать какими-то нестандартными средствами.
Шаг третий - у этого автора книга называется так-то. Даже Жюль Верн за свою долгую и плодотворную жизнь написал меньше двух сотен томов.

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

Я на самом деле пользовался поначалу базой данных от mylibru, ее, правда, проектировал какой-то школьник, не имеющий никакого представления о реляционной теории. Но при МИЗЕРНЫХ объемах, которые имеют каталоги библиотек, это не страшно.

После нахождения нужной книги ее надо извлечь из соответствующего архива. А zip-архивы, конечно, лучше tar.gz оптимизированы на скорость произвольного доступа, но сильно уступают в этом файловым системам.

Потом извлеченную книгу скопировать на устройство.

Вообще представления о том, что миллилоны это много, это миф, сохранившийся со времен MS-DOS c 640Кb enough for everyone. Современные компьютеры имеют гигабайты памяти, то есть туда впишутся если тупо грузить в более-менее оптимизированные структуры данных, десятки миллионов каталожных карточек.

[brmail]

бедненький сценарий поиска вы предложили. В реальности будет так: "помнится была книжка из серии фантастика или научная фантастика. Автора не помню. Вроде в названии было что-то про звезды. Как бы мне ее найти?" Все, у тебя после этого перебор 2-х миллионов файлов навсегда. И никакая иерархия твою файловую систему не спасет. И никакие гигабайты памяти. Собственно к памяти этот процесс поиска вообще не имеет отношения. Так как тормозить будет процесс перебора файлов, открытия их и чтения тегов из каждого.
Альтернатива одна - Строим индексы, кладем их в базу разница в скорости поиска будет не в разы, в десятки, если не сотни раз.
А как оно там хранится в самих архивах в принципе вообще все равно. По хорошему можно вообще все тексты в базу загнать чтобы дать пользователю и по тексту искать, но это уже напряг для базы - полнотекстовый поиск. Хотя все равно будет быстрее чем открывать пофайлово

[anonim_legion]

>напряг для базы - полнотекстовый поиск

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

[vitus_wagner]

Так поиск по метаинформации из FB2 чем занимаются все эти католлогизаторы, проблемы не решит.

А решит проблему, например, полнотекстовый индекс. Посторить который над кучкой аккуратно разложенных файлов я запросто могу с помощью любого инструмента полнотекстового поиска - хоть omega, хоть lucene. Нужно только правильный конвертер присобачить, чтобы он некоторым полям из метаинформации больший вес ставил, чем просто тексту.

Вопрос в том что большая монолитная программа-каталогизатор практически недоступна для расширения. Даже если у нее есть развитая система плагинов, освоение ее потребует слишком много времени.

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

[brmail]

нет, естественно оправдание собственному желанию продолжать трахаться и трахаться с открытым кодом доводя тупиковую идею до совершенства, а потом прикручивая к нему базу, так как все равно без нее работать не будет ... Не нужны никому стандартные средства работы, универсальные api и прочие базвордс. Пользователю нужна база от либрусека на 170+ Gb, готовый каталогизатор, и возможность скачать через год не новые 170 и все что набежало за год, а только добавку и индекс. И плевать пользователю что там ssl не свежая. И то что программа не обновляется часто - так же плевать ибо работает. Ну а тому кому шашечки, а не ехать - те велком в мир тех самых открытых стандартов итд по списку

[tzirechnoy [lj.rossia.org]]

>напряг для базы - полнотекстовый поиск.

Если это один человек со средним современным десктопом наперевес и пол-тэрабайта текстов -- то не сказать чтобы и напряг.

[legolegs]

>нескольких тысяч вариантов, но современные файловые системы с таким вполне справляются.

Они и с миллионами файлов в директории справляются. Только гуёвые файловые менеджеры плохо работают и ls тормозит. Конечно, это всё не про fat.