лытдыбр 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 программазм Добавил скрытие удалённых книг при создании индексов.
Попробую вечером на полном архиве, но, по-моему, не особо нужно.

лытдыбр nih программазм Посмотрел git log
Куча strange <элемент данных> fix, сопровождаемая more strange <элемент данных> fix
А ещё, надо бы посмотреть, как сделать замену книг на базе данных из .inp, но это уже вкусовщина, если честно.

лытдыбр программазм Обработка полного объёма прошла на удивление быстро — за ночь, а не за сутки, как при sqlite.
Работает шустрее (список книг у того же Лукьяненки выдаётся за пару секунд, а не периодические 502 при малейшей сторонней нагрузке с sqlite), поправил несколько опечаток типа использования имени автора вместо названия серии.
Выяснил, что забыл про пагинацию. Ну, скажем, в авторах, сериях и их книгах она не требуется. А вот в жанрах fbreader может и не так понять.
Надо будет сделать на неделе.
Вобщем, предварительное тестирование подтвердило: проц в апельсинке не успевает за диском. Сильно не успевает... Хранилище на нём ещё нормально делать, а вот приложения лучше запускать где-то ещё. Ну ок, пусть будет интерфейс к файлам, раз БД не катит. Может, к лету и поменяю, а до того времени будет работать так.

лытдыбр программазм Сравнил скорость обработки zip на нетбуке с N3350 и на апельсинке с Cortex-A53.
Ну что я могу выразить... Разница раз в 6, причём на нетбуке упирается в диск (zip лежали на microsd, iowait процентов в 10-15), а на апельсинке — в проц (iowait нет, нормальный диск воткнут в usb 3.0).
Вобщем, второтег, ибо с оплатой универа дочери на нормальный домашний сервер денег в ближайший год вряд ли будет.

лытдыбр программазм Плюнул на всякие ijson, сделал для больших данных формат jsonl (многострочный файл, где одна строка — один json). Как минимум, оно точно работает и при этом не требует странных приседаний и установки чего-либо вне дистрибутива (не доверяю я всяким pip).
Теперь осталось протестить на полном объёме (основное — там ещё надо сгенерировать данные для вебморды из zip) и заняться косметикой типа "сортировать так, чтоб кирилица была спереди" (уже делал, надо только адаптировать из функций sqlite в параметры sorted) и т.п.

лытдыбр программазм Наткнулся на то, что простых путей по чтению объектов из очень большого json в потоке немного.
БОльшая часть — низкоуровневые, после которых объект надо собирать с нуля.
Несколько высокоуровневых тупо не умеют читать массивы.
В принципе, могу плюнуть и читать промежуточные результаты по одному файлу на каждый .zip, но это а) некрасиво, б) поиск так реализовывать несколько сложновато и общий индекс по книгам всё равно нужен.

лытдыбр программазм Вчера пытался сгенерить статические данные на весь объём библиотеки (~170ГБ .zip).
На апельсинке нормально генерация не заработала — не влазит в память.
На нетбуке нет места — староват-с...
Плюнул, утащил промежуточные данные на работу и сгенерил там.
du выдал 8.3ГБ мелких файлов.
В принципе, терпимо. Но таскать туда-сюда данные не есть правильно, по-моему.
Надо всё же переделать обработку на дофига проходов (скажем, по сотне авторов за раз).

лытдыбр программазм Обнаружил, что скрипт для получения статических индексов на полной базе кушает несколько больше, чем может быть выделено на orange pi.
Похоже, надо либо поменять формат хранения на добавляемый (json на это как-то не тянет), либо каким-то образом собирать данные потоково (есть сомнения), либо делать дохрена проходов поверх промежуточных данных (в принципе, будет примерно столько же по времени, как и подготовка БД sqlite, наверное).
Впрочем, для первого запуска сделаю свап в zram, там нехватает буквально сотни три МБ.

лытдыбр программазм Таки микрокомпутерное хоронилище с его 0.1 bogomips/МГц и реальным максимумом в 1.44ГГц не шибко тянет фиговину на питоне. Проявляется на поиске и на выводе больших списков.
Для сравнения — в моём нетбуке при 800МГц получается 2188.80 bogomips, что несколько опережает по мощности. Более, чем на порядок.
Надо будет подумать либо в сторону чего-нибудь компилируемого, либо плюнуть и сделать генератор статического сайта с простым поиском на базе грепа или чего-то подобного.

лытдыбр программазм Открыл для себя github.com
Это получается примерный аналог того, как маршрутизируются запросы в Flask (параметры в путях и т.п.).

лытдыбр программазм google-driven development в полный рост, но сервис таки работает. Осталось понять, а то ли я понаписал, но вроде ТЗ соответствует.