О больших архивах
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:16 pm (UTC)не то чтоб это была совершенная программа, но искать - ищет, критериев поиска довольно много. Индексы свои поддерживает, не тормозит.
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.
no subject
Date: 2017-01-22 06:54 pm (UTC)У меня в дистрибутиве, между прочим, qt 5.3.2 и это ни разу не oldstable.
Кроме того там в дистрибутиве исходников лежат бинарные файлы - kindleindex для всех платформ и openssl-евские .dll для Windows. Причем последние - 2009 года выпуска. И ничего не сказано про то, где взять обновленные версии.
Хотя дыры в OpenSSL находят регулярно. И между прочим я уже сталкивался со случаем, когда OpenSSL 2007 года оказалась в принципе несовместимой с современным https-сайтом.
Потому что алгоритмы тоже устаревают и выводятся из эксплуатации.
В общем крайне не рекомендую freeLib. Если уж жить нельзя без каталогизатора, используйте calibre.
no subject
Date: 2017-01-22 07:15 pm (UTC)А Калибри как каталогизатор я не рассматривал, но это худший файл-конвертер который я когда либо видел.
no subject
Date: 2017-01-22 07:40 pm (UTC)А вот в случае openssl "работает не трогай" означает, что она работает НЕ В ТВОИХ ИНТЕРЕСАХ. Это библиотека, критичная для безопасности компьютера, и любая ошибка в ней - remote exploit практически автоматом.
lib.rus.ec вообще не отдает книг. Уже давно. Поэтому он меня и не интересует.
calibre, действительно является ужасным конвертером файлов. Потому что у конвертера файлов не должно быть GUI. И не должно быть своих представлений о том, где правильно хранить эти самые файлы. Вот указал пользователь входной файл, указал выходной - оно сконвертировало. Ну и естественно, автоматическая конвертация имеет существенные ограничения. Но когда надо конвертировать из проприетарных форматов в открытые, все равно конвертировать приходится.
no subject
Date: 2017-01-22 08:47 pm (UTC)no subject
Date: 2017-01-23 06:55 am (UTC)Впрочем, с какого перепуга оно запустится на любой современной машине, оно ж 32-битное. А откуда у меня 32-битная libqt5, тем более версии более новой чем та, что у меня пришла с дистрибутивом?
Этот софт ходит на внешний сайт по HTTP. Следовательно уже уязвим к атакам. Более того, любой потенциально атакующий знает, на какой именно сайт ходят миллионы пользователей этого софта. А серверный софт написан на php. Тоже дыра-дырой. Ломаем сервер, ставим там эксплойт для древней openssl и voila - ботнет из миллиона узлов у нас в руках.
no subject
Date: 2017-01-23 07:22 am (UTC)И трудно сказать как оно (32 bit) работает, но win 7 64bit его пускает прекрасно. Как видимо проблема с вашей стороны. А то, что софт ходит на внешний http - так это не бага а фича, так сказать дополнительная функциональность которой просто не стоит пользоваться. Да и собственно зачем, если локально уже все скачено, и все проиндексировано.
no subject
Date: 2017-01-23 10:51 am (UTC)no subject
Date: 2017-01-23 11:21 am (UTC)Кроме того, создатель malware всегда может модифицировать его до тех пор, пока оно не перестанет детектироваться антивирусами. Да, завтра антивирусы научатся детектировать и новую версию, но ущерб уже будет нанесён.
> Уверяю тебя, что троянов в интернете разбросано не так много как
> бинарников.
Но при установке на компьютер N бинарников вероятность остаться чистым падает экспоненциально. Как в русской рулетке.
no subject
Date: 2017-01-23 10:56 am (UTC)no subject
Date: 2017-01-23 10:55 am (UTC)Большая.
Насколько я понимаю, конкретно эта версия не подвержэна уязвимости heartbleed, но как пример того, чем можэт закончиться использование openssl с известными багами эта уязвимость хорошо подходит.
no subject
Date: 2017-01-22 08:56 pm (UTC)no subject
Date: 2017-01-23 07:04 am (UTC)no subject
Date: 2017-01-23 09:25 am (UTC)