лытдыбр nih программазм Сделал усилие над собой, плюнул и добил четвертый вариант библиотеки. Надеюсь, пятого уже не будет. В худшем случае — будет продолжение третьего, ибо четвёртый делался под ТАКОЕ железо, какое лучше для сервера не использовать.

лытдыбр программазм Попытался воткнуть типы в NIH. Понял, что не знаю, как делать сложные типы в питонах (аналог сишных struct). И хрен с ним, поставлю где можно более простые пока что.

лытдыбр nih программазм На исправление багов времени не находится, а запилить ещё один пункт в вебморде — без проблем. Теперь ещё и по дате поступления, чтоб новинки посмотреть.

лытдыбр nih программазм Впервые после апгрейда на 12-й дебиан проверил исходники при помощи pylint и flake8. Могу выразить много чего про новые варнинги. Особенно за "%s" в строках.
Примерно 3/4 файлов надо бы переделать. Кое-что таки переделал, но C0209 заткнул, ибо на нетбуке тупо нельзя запустить БД, чтобы проверить результат. Оставлю до времени, когда будет возможность проверить на работе.

лытдыбр nih программазм Убрал кучу мелких запросов за именами жанров. Теперь осталось либо оптимизировать запросы с "book_id IN ( охренительный список всех книг автора )" или переделать нафиг, только надо понять на что. Пока склоняюсь к "посмотреть, может сойдёт".

лытдыбр nih программазм За 20 минут до выхода с работы решил немножечко покопаться в коде библиотеки. Докопался до того, что основные запросы к БД у меня правильные, а вот имена жанров вообще-то надо получать не по одному. Похоже, придётся немножечко загружать их из БД в память при старте и потом при помощи хеша и какой-то матери уточнять, что выводить. В принципе, это небольшой откат к предыдущему варианту, но всё же не настолько, насколько думал. А вот то, что я забыл сделать git push на работе и при этом зачем-то уходя выключил комп...

лытдыбр nih программазм Первой итерацией библиотеки у меня было "всё в БД". БД была sqlite, было не слишком быстро.
Второй итерацией было "всё в json, а что не в json — конвертируем в json". И таки да, стало побыстрее, особенно если не пользоваться штуками, жрущими проц. Но поиск всё ещё был медленным (ну да, там у меня список заголовков в пару гиг без индекса и на микрокомпе оно не шибко по нему искало).
Третья итерация снова "всё в БД". БД нынче постгрес. Поиск работает не скажу что быстро, но всё ж быстрее, чем в json, причём и по аннотациям успевает в таймаут. Но, блин, зато часть обычных списков книг выводится медленнее — там надо не просто выдать в xml/html json с диска, а собрать структуру данных из нескольких запросов.
Сейчас думаю, а не сделать ли готовую структуру в БД для страниц типа "все книги автора вне серий"?

лытдыбр nih программазм Решил таки уже сделать фильтр по языку (в рэндоме довольно часто попадается болгарский, что СИЛЬНО сбивает с толку). Но есть нюанс: поле языка у книги требуется нормализовывать до попадания в базу. То есть, для тестирования надо перегенерить тестовую базу. Ок, сделал нормализацию в скрипте индексации, запустил, но, похоже, сегодня я нихрена не займусь вебмордой.

лытдыбр nih программазм Пока с утра думал над тем, что делать с базой и нахрена всё это — запинал-таки virtualenv и requirements.txt для версии морды с базой.

лытдыбр nih программазм Смотрю на запросы к базе постгреса с книгами и понимаю, что если бы удалось запустить кликхаус на хоронилище, то а) база занимала бы в разы меньше места (от 2 до 4 по моим оценкам), б) представляла бы собой две таблицы (книжки с полной информацией и соответствие жанров, групп жанров и названий всего этого), в) работала бы значительно быстрее. Но в 2ГБ памяти кх не влезет в любом случае...

А сейчас с одной стороны оно точно работает быстрее sqlite (там у некоторых авторов 10-минутный таймаут nginx отрабатывал), с другой — даже если по explain запрос не делает фулскан таблицы, используя индексы, по статистике использования диска — делает. Похоже, надо пересматривать структуру базы, но в какую сторону смотреть — пока хз.

Ещё надо вспомнить про экономию ресурсов и прерывать запросы, если клиент отпал. Но это уже потом.

лытдыбр nih программазм Какое-то время назад посмотрел на промежуточные данные (пришлось так сделать когда-то, чтобы не перегружать апельсинку), понял, что выковыривать обложки хорошо, а вот занимать место — не очень. Сделал загрузку .gz, сейчас дошли руки протестировать. Работает, памяти дополнительно почти не жрёт, надо будет воткнуть уже на хранилище и сжать нафиг промежуточные данные уже с -9.
В принципе, можно уже пользоваться. С нюансами, типа минуты-другой на поиск по заглавиям и чуть меньше 5 минут на поиск по аннотациям. Но тут если чего и поменяется, то только после замены хоронилища на что-то более писюковое, либо если найдётся более эффективный индекс, чем по tsvector. Вообще, спасибо, что вообще работает, в предыдущей версии даже по заглавиям не шибко искало, ибо таймаут.
Думаю, пока оставлю так, в рамках запуска на orange pi сильно не улучшить.

лытдыбр nih программазм Переделал индексацию базы на batch insert.
Тестовый прогон на десктопе показал, что а) как ожидалось, работает быстрее, б) не влезет в память хоронилища.
Похоже, надо делить батчи на более мелкие... Скажем, в пределах тысячи книг, а не десяток тыщ во всём архиве разом.

лытдыбр программазм Пока *NIH делает вид, что работает, выяснил, что thermald.sh работает отлично, но запускать его надо не в кроне, а хотя бы раз в 10 секунд. Или в 5. Тогда а) точно не перегревается, б) нет потерь производительности одного потока, когда остальные уже закончили работу.
Надо будет сделать запуск по таймеру или вообще сделать цикл в скрипте, который запускать в systemd, а не в кроне, как сейчас.

лытдыбр nih программазм Плюнул на картинки и запустил индексацию книжек в базу без них уже на хранилище чисто потестить, как пойдёт. На удивление — неплохо, скорость на первых 10% на уровне десктопа и при этом температура не подскакивает до уровня, когда надо сбрасывать частоту.
Постгрес весьма экономен по процессору и памяти + скрипт, который запихивает данные в постгрес, также жрёт меньше, чем предыдущий вариант.

Похоже, после доделки обложек, этот вариант у меня приживётся, надо будет только дописать частичную переиндексацию, так как всё же перезалитие базы с нуля (пусть даже через UPDATE на те же данные) не то же самое, что залитие только нового.

лытдыбр nih программазм Начал парсить книжки полностью, ради картинок.
Обнаружил fb2, где все параграфы — вложенные.

лытдыбр программазм Всем хорош pylint, но всё же не предназначен для варианта, когда в одном проекте есть приложение flask, где есть класс работы с БД в режиме r/o и одновременно индексер, где есть класс для работы с БД уже в rw.
Индексер, конечно, читает конфиг приложения, но не более. А вот приложение к файлам индексера не лезет.
pylint нашел-таки дублирующийся код — в init() у классов, где идёт подключение к БД. Похоже, где-то пора поставить параметр для непроверки дублей.
А вообще, из реальных претензий к нему — всё же не отслеживает всякие форматирования кода, которые отслеживает flake8. Надо будет как-нибудь совместить их в пункте Lint у geany.

лытдыбр программазм Удивлён, что pylint не ругается на каждую сточку — я там местами в стиле embedded C программировал :-)

лытдыбр программазм В процессе извращений над *NIH выяснил, что либо flake8 мне недостаточно, либо дебиановский flake8 не отслеживает, к примеру, неиспользуемые параметры функций.
pylama на текущем коде выдаёт только тривиальное типа "функция переусложнена".

лытдыбр nih программазм Решил попробовать таки сделать морду к библиотеке с базой на постгресе — там есть возможность полнотексового поиска по индексам.
В сии индексы всю книгу засовывать точно не буду — местов нет, а вот аннотации/заглавия/авторов/серии точно надо.

лытдыбр nih программазм Добавил скрытие удалённых книг при создании индексов.
Попробую вечером на полном архиве, но, по-моему, не особо нужно.