О больших архивах
Jan. 22nd, 2017 05:58 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПопробовал тут разгрести описанным в предыдущем посте скриптом архив либрусэка завалявшийся с 2009 года.
Получилось - из менее чем 200000 книг 2176 попросту not well-formed XML. В основном от того что народ использует знаки больше-меньше (даже не сдвоенные) в вместо кавычек-елочек, а какие-то распространенные тулзы генерации FB2 это не отслеживают и не заменяют встретившийся в тексте зна < на соответствующий entity. Аналогичные проблемы возникают с амперсэндами.
Ну и плюс к тому куча пробелов, неразрывных пробелов, кавычек, скобочек в полях "имя автора". В принципе можно скрипт пофиксить, чтобы все символы, не участвующие в сортировке по библиографическим правилам, резал.
Но вообще, конечно, все это добро нуждается в вычитки и чистке от артефактов сканирования и распознавания. Поэтому я и держу настолько маленькую библиотеку, что в ней мне все-таки не лень слазить и руками исправить ошибки в XML и метаданных.
А то и пройтись по всему тексту и правильно оформить тэгами разбиение на главы.
Получилось - из менее чем 200000 книг 2176 попросту not well-formed XML. В основном от того что народ использует знаки больше-меньше (даже не сдвоенные) в вместо кавычек-елочек, а какие-то распространенные тулзы генерации FB2 это не отслеживают и не заменяют встретившийся в тексте зна < на соответствующий entity. Аналогичные проблемы возникают с амперсэндами.
Ну и плюс к тому куча пробелов, неразрывных пробелов, кавычек, скобочек в полях "имя автора". В принципе можно скрипт пофиксить, чтобы все символы, не участвующие в сортировке по библиографическим правилам, резал.
Но вообще, конечно, все это добро нуждается в вычитки и чистке от артефактов сканирования и распознавания. Поэтому я и держу настолько маленькую библиотеку, что в ней мне все-таки не лень слазить и руками исправить ошибки в XML и метаданных.
А то и пройтись по всему тексту и правильно оформить тэгами разбиение на главы.
no subject
Date: 2017-01-22 06:41 pm (UTC)Мне не нужна отдельная программа-каталогизатор книг. У меня вообще-то calibre есть, хотя используется исключительнор для снятия DRM с амазоновских книг.
Я хочу добиться того, чтобы для поиска нужной книги можно было эффективно использовать файловую систему.
Потому что к файловой системе есть множество возможных интерфейсов.
Допустим, мне потребовалось найти у себя дома нужную книгу, зайдя туда по ssh через три nat-а и два vpn-а, причем с телефона. Очевидно, что ни freelib, ни calibre этой задачи не решат. А правильно структурированное хранилище в файловой системе - решит.
Далее, читать я все равно буду fbreader-ом, что на десктопе, что на телефоне. Он имеет встроенные средства каталогизации. И для того чтобы они нормально работали, а также для того чтобы книгу правильно воспринял какой-нибудь coolreader у человека, с которым я хочу поделиться, внутри самой книги должна быть правильная метаинформация.
Электронная книга должна быть правильной, независимо от программ, которые с ней работают. А флибусте бы надо на аплоаде валидатор прикрутить и не позволять аплоадить книги, невалидные с точки зрения схемы FictionBook. Ну и некие базовые проверки метаинформации вида "А вот у вас написано автор А.Толстой. У нас уже есть авторы Алексей Константинович Толстой и Алексей Николаевич Толстой, может быть вы имели в виду одного из них?"
Этот пост про то что файлы, лежащие на либрусеке и флибусте в 2% случаев вообще well-formed XML не являются, через xmllint я их еще не все гонял, поэтому процент попадания в схему сказать не могу, хотя может и стоило бы.
При этом в 90% случаев это правится одной-двумя глобальными заменами.
no subject
Date: 2017-01-22 07:11 pm (UTC)Файловая система неплоха когда файлов тысячи. А поиск по паре миллионов - увольте.
no subject
Date: 2017-01-22 08:21 pm (UTC)В котором какой-то древний архив либрусэка составляет 4 процента.
Если вы не умеете пользоваться файловой системой, то у вас и sql-база будет тормозить секунды на простейших запросах.
Файловая система иерархична. Разбейте ее на 3 уровня, и миллион превратится в сотню.
Что касается sql-Я то я могу точно сказать, что им еще надо уметь пользоваться. Работая в компании, которая занимается как раз базами данных причем и консалтингом тоже, я имею об этом некоторое представление.
Я не понимаю, что вы собираетесь искать по паре миллионов файлов? Цитату? По всей базе без разбора?
Но тут вас никакие архивы не спасут.
Если же нужно найти книгу, по автору и заглавию или по любой другой метаинформации вынесенной в структуру файловой системы, то никакого "поиска по 2 миллионам" тут нет. Вы идете и берете
Шаг первый - имя автора начинается с этой буквы. Вариантов примерно полсотни.
Шаг второй - имя автора такое-то. Внутри буквы здесь может быть до нескольких тысяч вариантов, но современные файловые системы с таким вполне справляются. Хотя вот тут человек описывал создание префиксов из 4-х букв и группировку их в более-менее равные по численности группы. Правда, в такой схеме completion работать не будет, и этот шаг придется делать какими-то нестандартными средствами.
Шаг третий - у этого автора книга называется так-то. Даже Жюль Верн за свою долгую и плодотворную жизнь написал меньше двух сотен томов.
Это получится намного быстрее, чем запустить специальную программу оболоочку, найти базу данных и выполнить запрос.
Я на самом деле пользовался поначалу базой данных от mylibru, ее, правда, проектировал какой-то школьник, не имеющий никакого представления о реляционной теории. Но при МИЗЕРНЫХ объемах, которые имеют каталоги библиотек, это не страшно.
После нахождения нужной книги ее надо извлечь из соответствующего архива. А zip-архивы, конечно, лучше tar.gz оптимизированы на скорость произвольного доступа, но сильно уступают в этом файловым системам.
Потом извлеченную книгу скопировать на устройство.
Вообще представления о том, что миллилоны это много, это миф, сохранившийся со времен MS-DOS c 640Кb enough for everyone. Современные компьютеры имеют гигабайты памяти, то есть туда впишутся если тупо грузить в более-менее оптимизированные структуры данных, десятки миллионов каталожных карточек.
no subject
Date: 2017-01-22 08:55 pm (UTC)Альтернатива одна - Строим индексы, кладем их в базу разница в скорости поиска будет не в разы, в десятки, если не сотни раз.
А как оно там хранится в самих архивах в принципе вообще все равно. По хорошему можно вообще все тексты в базу загнать чтобы дать пользователю и по тексту искать, но это уже напряг для базы - полнотекстовый поиск. Хотя все равно будет быстрее чем открывать пофайлово
no subject
Date: 2017-01-22 09:41 pm (UTC)Для специализированной базы - не напряг. Их уже уйму понаписали. Да и в постгресе полнотекстовый поиск хорошо работает, насколько я помню к движку БД что-то специализированно-поисковое прикрутили разработчики Авито.
no subject
Date: 2017-01-23 06:51 am (UTC)А решит проблему, например, полнотекстовый индекс. Посторить который над кучкой аккуратно разложенных файлов я запросто могу с помощью любого инструмента полнотекстового поиска - хоть omega, хоть lucene. Нужно только правильный конвертер присобачить, чтобы он некоторым полям из метаинформации больший вес ставил, чем просто тексту.
Вопрос в том что большая монолитная программа-каталогизатор практически недоступна для расширения. Даже если у нее есть развитая система плагинов, освоение ее потребует слишком много времени.
А когда у меня система хранения расчитана на максимальное использование стандартных средств работы с файловой системой, которые не надо осваивать не только мне, но и авторам тех специализированных инструментов, которые могут мне понадобиться (систем полнотекстового поиска, например), гораздо проще собрать из кубиков все, что требуется.
no subject
Date: 2017-01-23 07:16 am (UTC)no subject
Date: 2017-01-23 10:31 am (UTC)Если это один человек со средним современным десктопом наперевес и пол-тэрабайта текстов -- то не сказать чтобы и напряг.
no subject
Date: 2017-01-23 07:43 am (UTC)Они и с миллионами файлов в директории справляются. Только гуёвые файловые менеджеры плохо работают и ls тормозит. Конечно, это всё не про fat.