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
Мне не нужна отдельная программа-каталогизатор книг. У меня вообще-то calibre есть, хотя используется исключительнор для снятия DRM с амазоновских книг.
Я хочу добиться того, чтобы для поиска нужной книги можно было эффективно использовать файловую систему.
Потому что к файловой системе есть множество возможных интерфейсов.
Допустим, мне потребовалось найти у себя дома нужную книгу, зайдя туда по ssh через три nat-а и два vpn-а, причем с телефона. Очевидно, что ни freelib, ни calibre этой задачи не решат. А правильно структурированное хранилище в файловой системе - решит.
Далее, читать я все равно буду fbreader-ом, что на десктопе, что на телефоне. Он имеет встроенные средства каталогизации. И для того чтобы они нормально работали, а также для того чтобы книгу правильно воспринял какой-нибудь coolreader у человека, с которым я хочу поделиться, внутри самой книги должна быть правильная метаинформация.
Электронная книга должна быть правильной, независимо от программ, которые с ней работают. А флибусте бы надо на аплоаде валидатор прикрутить и не позволять аплоадить книги, невалидные с точки зрения схемы FictionBook. Ну и некие базовые проверки метаинформации вида "А вот у вас написано автор А.Толстой. У нас уже есть авторы Алексей Константинович Толстой и Алексей Николаевич Толстой, может быть вы имели в виду одного из них?"
Этот пост про то что файлы, лежащие на либрусеке и флибусте в 2% случаев вообще well-formed XML не являются, через xmllint я их еще не все гонял, поэтому процент попадания в схему сказать не могу, хотя может и стоило бы.
При этом в 90% случаев это правится одной-двумя глобальными заменами.
no subject
Файловая система неплоха когда файлов тысячи. А поиск по паре миллионов - увольте.
no subject
В котором какой-то древний архив либрусэка составляет 4 процента.
Если вы не умеете пользоваться файловой системой, то у вас и sql-база будет тормозить секунды на простейших запросах.
Файловая система иерархична. Разбейте ее на 3 уровня, и миллион превратится в сотню.
Что касается sql-Я то я могу точно сказать, что им еще надо уметь пользоваться. Работая в компании, которая занимается как раз базами данных причем и консалтингом тоже, я имею об этом некоторое представление.
Я не понимаю, что вы собираетесь искать по паре миллионов файлов? Цитату? По всей базе без разбора?
Но тут вас никакие архивы не спасут.
Если же нужно найти книгу, по автору и заглавию или по любой другой метаинформации вынесенной в структуру файловой системы, то никакого "поиска по 2 миллионам" тут нет. Вы идете и берете
Шаг первый - имя автора начинается с этой буквы. Вариантов примерно полсотни.
Шаг второй - имя автора такое-то. Внутри буквы здесь может быть до нескольких тысяч вариантов, но современные файловые системы с таким вполне справляются. Хотя вот тут человек описывал создание префиксов из 4-х букв и группировку их в более-менее равные по численности группы. Правда, в такой схеме completion работать не будет, и этот шаг придется делать какими-то нестандартными средствами.
Шаг третий - у этого автора книга называется так-то. Даже Жюль Верн за свою долгую и плодотворную жизнь написал меньше двух сотен томов.
Это получится намного быстрее, чем запустить специальную программу оболоочку, найти базу данных и выполнить запрос.
Я на самом деле пользовался поначалу базой данных от mylibru, ее, правда, проектировал какой-то школьник, не имеющий никакого представления о реляционной теории. Но при МИЗЕРНЫХ объемах, которые имеют каталоги библиотек, это не страшно.
После нахождения нужной книги ее надо извлечь из соответствующего архива. А zip-архивы, конечно, лучше tar.gz оптимизированы на скорость произвольного доступа, но сильно уступают в этом файловым системам.
Потом извлеченную книгу скопировать на устройство.
Вообще представления о том, что миллилоны это много, это миф, сохранившийся со времен MS-DOS c 640Кb enough for everyone. Современные компьютеры имеют гигабайты памяти, то есть туда впишутся если тупо грузить в более-менее оптимизированные структуры данных, десятки миллионов каталожных карточек.
no subject
Альтернатива одна - Строим индексы, кладем их в базу разница в скорости поиска будет не в разы, в десятки, если не сотни раз.
А как оно там хранится в самих архивах в принципе вообще все равно. По хорошему можно вообще все тексты в базу загнать чтобы дать пользователю и по тексту искать, но это уже напряг для базы - полнотекстовый поиск. Хотя все равно будет быстрее чем открывать пофайлово
no subject
Для специализированной базы - не напряг. Их уже уйму понаписали. Да и в постгресе полнотекстовый поиск хорошо работает, насколько я помню к движку БД что-то специализированно-поисковое прикрутили разработчики Авито.
no subject
А решит проблему, например, полнотекстовый индекс. Посторить который над кучкой аккуратно разложенных файлов я запросто могу с помощью любого инструмента полнотекстового поиска - хоть omega, хоть lucene. Нужно только правильный конвертер присобачить, чтобы он некоторым полям из метаинформации больший вес ставил, чем просто тексту.
Вопрос в том что большая монолитная программа-каталогизатор практически недоступна для расширения. Даже если у нее есть развитая система плагинов, освоение ее потребует слишком много времени.
А когда у меня система хранения расчитана на максимальное использование стандартных средств работы с файловой системой, которые не надо осваивать не только мне, но и авторам тех специализированных инструментов, которые могут мне понадобиться (систем полнотекстового поиска, например), гораздо проще собрать из кубиков все, что требуется.
no subject
no subject
Если это один человек со средним современным десктопом наперевес и пол-тэрабайта текстов -- то не сказать чтобы и напряг.
no subject
Они и с миллионами файлов в директории справляются. Только гуёвые файловые менеджеры плохо работают и ls тормозит. Конечно, это всё не про fat.
no subject
У меня в дистрибутиве, между прочим, qt 5.3.2 и это ни разу не oldstable.
Кроме того там в дистрибутиве исходников лежат бинарные файлы - kindleindex для всех платформ и openssl-евские .dll для Windows. Причем последние - 2009 года выпуска. И ничего не сказано про то, где взять обновленные версии.
Хотя дыры в OpenSSL находят регулярно. И между прочим я уже сталкивался со случаем, когда OpenSSL 2007 года оказалась в принципе несовместимой с современным https-сайтом.
Потому что алгоритмы тоже устаревают и выводятся из эксплуатации.
В общем крайне не рекомендую freeLib. Если уж жить нельзя без каталогизатора, используйте calibre.
no subject
А Калибри как каталогизатор я не рассматривал, но это худший файл-конвертер который я когда либо видел.
no subject
А вот в случае openssl "работает не трогай" означает, что она работает НЕ В ТВОИХ ИНТЕРЕСАХ. Это библиотека, критичная для безопасности компьютера, и любая ошибка в ней - remote exploit практически автоматом.
lib.rus.ec вообще не отдает книг. Уже давно. Поэтому он меня и не интересует.
calibre, действительно является ужасным конвертером файлов. Потому что у конвертера файлов не должно быть GUI. И не должно быть своих представлений о том, где правильно хранить эти самые файлы. Вот указал пользователь входной файл, указал выходной - оно сконвертировало. Ну и естественно, автоматическая конвертация имеет существенные ограничения. Но когда надо конвертировать из проприетарных форматов в открытые, все равно конвертировать приходится.
no subject
no subject
Впрочем, с какого перепуга оно запустится на любой современной машине, оно ж 32-битное. А откуда у меня 32-битная libqt5, тем более версии более новой чем та, что у меня пришла с дистрибутивом?
Этот софт ходит на внешний сайт по HTTP. Следовательно уже уязвим к атакам. Более того, любой потенциально атакующий знает, на какой именно сайт ходят миллионы пользователей этого софта. А серверный софт написан на php. Тоже дыра-дырой. Ломаем сервер, ставим там эксплойт для древней openssl и voila - ботнет из миллиона узлов у нас в руках.
no subject
И трудно сказать как оно (32 bit) работает, но win 7 64bit его пускает прекрасно. Как видимо проблема с вашей стороны. А то, что софт ходит на внешний http - так это не бага а фича, так сказать дополнительная функциональность которой просто не стоит пользоваться. Да и собственно зачем, если локально уже все скачено, и все проиндексировано.
no subject
no subject
Кроме того, создатель malware всегда может модифицировать его до тех пор, пока оно не перестанет детектироваться антивирусами. Да, завтра антивирусы научатся детектировать и новую версию, но ущерб уже будет нанесён.
> Уверяю тебя, что троянов в интернете разбросано не так много как
> бинарников.
Но при установке на компьютер N бинарников вероятность остаться чистым падает экспоненциально. Как в русской рулетке.
no subject
no subject
Большая.
Насколько я понимаю, конкретно эта версия не подвержэна уязвимости heartbleed, но как пример того, чем можэт закончиться использование openssl с известными багами эта уязвимость хорошо подходит.
no subject
no subject
no subject