vitus_wagner (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
vitus_wagner) wrote2017-01-22 05:58 pm
vitus_wagner) wrote2017-01-22 05:58 pm
Entry tags:
О больших архивах
Попробовал тут разгрести описанным в предыдущем посте скриптом архив либрусэка завалявшийся с 2009 года.
Получилось - из менее чем 200000 книг 2176 попросту not well-formed XML. В основном от того что народ использует знаки больше-меньше (даже не сдвоенные) в вместо кавычек-елочек, а какие-то распространенные тулзы генерации FB2 это не отслеживают и не заменяют встретившийся в тексте зна < на соответствующий entity. Аналогичные проблемы возникают с амперсэндами.
Ну и плюс к тому куча пробелов, неразрывных пробелов, кавычек, скобочек в полях "имя автора". В принципе можно скрипт пофиксить, чтобы все символы, не участвующие в сортировке по библиографическим правилам, резал.
Но вообще, конечно, все это добро нуждается в вычитки и чистке от артефактов сканирования и распознавания. Поэтому я и держу настолько маленькую библиотеку, что в ней мне все-таки не лень слазить и руками исправить ошибки в XML и метаданных.
А то и пройтись по всему тексту и правильно оформить тэгами разбиение на главы.
Получилось - из менее чем 200000 книг 2176 попросту not well-formed XML. В основном от того что народ использует знаки больше-меньше (даже не сдвоенные) в вместо кавычек-елочек, а какие-то распространенные тулзы генерации FB2 это не отслеживают и не заменяют встретившийся в тексте зна < на соответствующий entity. Аналогичные проблемы возникают с амперсэндами.
Ну и плюс к тому куча пробелов, неразрывных пробелов, кавычек, скобочек в полях "имя автора". В принципе можно скрипт пофиксить, чтобы все символы, не участвующие в сортировке по библиографическим правилам, резал.
Но вообще, конечно, все это добро нуждается в вычитки и чистке от артефактов сканирования и распознавания. Поэтому я и держу настолько маленькую библиотеку, что в ней мне все-таки не лень слазить и руками исправить ошибки в XML и метаданных.
А то и пройтись по всему тексту и правильно оформить тэгами разбиение на главы.
no subject
Альтернатива одна - Строим индексы, кладем их в базу разница в скорости поиска будет не в разы, в десятки, если не сотни раз.
А как оно там хранится в самих архивах в принципе вообще все равно. По хорошему можно вообще все тексты в базу загнать чтобы дать пользователю и по тексту искать, но это уже напряг для базы - полнотекстовый поиск. Хотя все равно будет быстрее чем открывать пофайлово
no subject
Для специализированной базы - не напряг. Их уже уйму понаписали. Да и в постгресе полнотекстовый поиск хорошо работает, насколько я помню к движку БД что-то специализированно-поисковое прикрутили разработчики Авито.
no subject
А решит проблему, например, полнотекстовый индекс. Посторить который над кучкой аккуратно разложенных файлов я запросто могу с помощью любого инструмента полнотекстового поиска - хоть omega, хоть lucene. Нужно только правильный конвертер присобачить, чтобы он некоторым полям из метаинформации больший вес ставил, чем просто тексту.
Вопрос в том что большая монолитная программа-каталогизатор практически недоступна для расширения. Даже если у нее есть развитая система плагинов, освоение ее потребует слишком много времени.
А когда у меня система хранения расчитана на максимальное использование стандартных средств работы с файловой системой, которые не надо осваивать не только мне, но и авторам тех специализированных инструментов, которые могут мне понадобиться (систем полнотекстового поиска, например), гораздо проще собрать из кубиков все, что требуется.
no subject
no subject
Если это один человек со средним современным десктопом наперевес и пол-тэрабайта текстов -- то не сказать чтобы и напряг.