Calibre 8.6.0: значительно повышена скорость восстановления базы данных

Пожалуй, одной из самых больших проблем Calibre до недавнего времени была скорость работы базы данных, в которой хранятся эти самые книги. Чем больше книг в библиотеке пользователя, тем медленнее происходила работа с базой данных. Когда в твоей библиотеке несколько десятков или сотен книг - это не так заметно. Но когда в библиотеке тысячи книг - это может вызвать боль…

В свежем обновлении Calibre проблема со скоростью работы базы данных была решена радикально.

Откуда это взялось? Опять «более живая манера подачи»?

https://calibre-ebook.com/whats-new

Restoring database: Improve performance by an order of magnitude

И всё.

Откуда это взялось?

По ссылке написано + https://github.com/kovidgoyal/calibre/pull/2796

(с обвинением ошибся)

Прямо по ссылке написано про долгое открытие.

Вот это уровень английского! Впрочем, неудивительно.
Ты же до сих пор не различаешь «чтобы» от «что бы».

Разве в правилах где то есть про обязательный перевод 1 в 1 с английского? У fail2ban все написано понятно, и правдиво.

И уж точно нету правила на то что бы в новостях была информация только из скудного changelogа. Именно поэтому я читаю условный OpenNet а не NEWS/ChangeLog, там больше информации собирают.

и правдиво

Нет. В https://github.com/kovidgoyal/calibre/pull/2796 добавили две строки, выполняющихся при восстановлении метаданных.

Пожалуй, одной из самых больших проблем Calibre до недавнего времени была скорость работы базы данных, в которой хранятся эти самые книги. Чем больше книг в библиотеке пользователя, тем медленнее происходила работа с базой данных.

А это вводит в заблуждение. Как будто что-то кардинально оптимизировали.

Эти две строки не были добавлены, там другой код но он относится тоже к restore. Да, fail2ban стоит переписать по другому, что бы было понятно что изменения относятся именно к restore. Твой изначальный комментарий можно интерпретировать по другому, как отрицание серьезной оптимизации связанной с БД.

По словам одного из разработчиков, время восстановления базы данных из 5.5 тысяч книг сократилось с более чем 5 часов до 5 минут.

Вспомнилась цитата @geek про аналогичную новость про драйвера ati/amd

Типа драйвера амд были ещё большим говном, чем выглядели

restore my 5.5k book database

Это не человек, это робот с обучением на текстах

По словам одного из разработчиков, время восстановления базы данных из 5.5 тысяч книг сократилось с более чем 5 часов до 5 минут.

Не удивлён. Старые версии Calibre конвертировали одну книгу в fb2 до 15 минут. А всё потому, что человек, писавший код сохранения, не знал, что строки в питоне неизменяемые, и при конкатенации происходит копирование памяти. В итоге, тысячи операций конкатенации при разбиении строки base64 на равномерные отрезки приводили к экспоненциальному росту сложности. Отправил пул-реквест с исправлением и fb2 стали сохраняться мгновенно.

SQLite ...

день добрый, господа колдуны!
поясните в 3х словах необходимость использования «движков» (пусть даже и маленьких) в таких и подобных «частно/приватно/корманных» прилажухах.
- кол-во книг/полей - очень мало
- потеря/порча записи бд - риск потерять вообще «все» (тут «ковычки» а не «истерика»: о, потеряно все... а тут смайлик :о)

учитывая, конечно, что это «частная коллекция» (у меня, у вас на ноутбуке ... все, типа того)

спасибо :о)

p.s. в процессе институтации/какадемации - пилил под себя «текствый движек», «запиПсулька» работает до сих пор, ни разу не сбоила (с 2000 года)

ЯННП

необходимость использования «движков» (пусть даже и маленьких) в таких и подобных «частно/приватно/корманных» прилажухах.

Индексация. У каждой книжки есть название, автор, серия например. Запихиваешь каждый этот параметр в бд как поле в таблице и поиск ускоряется многократно.

кол-во книг

Оно варьируется.

кол-во полей

Из-за небольшого количества полей размер бд, даже с большим количеством книг не особо велик. Я помню для myrulib в библиотеке в 300 Гб книг у меня бд занимала несколько гигабайт.

Потому что это 1) удобно 2) уже существует 3) проверено сообществом и временем 4) экспертиза есть как у разработчиков, так и пользователей 5) стандартные и известные методы работы с бд - экспорт, бекап и тд.

И вряд ли кто-то захочет разбираться с твоими запиПсульками, особенно если код, комменты и документация в таком же стиле, как это сообщение. Если они вообще есть.

Кстати, недавно нашел себе альтернативу калибре - audiobookshelf (https://github.com/advplyr/audiobookshelf). Из плюсов - поднял безголовый контейнер, доступ отовсюду через веб, слушаю аудиокниги и читаю обычные через клиентов или прямо в браузере. С моментальной синхронизацией прогресса.

Не пользуюсь, но одобряю.

оно уже перестало падать на файлах, бо́льших чем пара килобайт?

недавно нашел себе альтернативу калибре

Потому что не понравился интерфейс MyLibrary 4.0? :)

Потому что не понравился интерфейс MyLibrary 4.0? :)

Шедеврально, спасибо за ссылку :)

Но у меня линукс только на серверах и без графики, плюс я не люблю гном и гтк. Плюс куча устройств и мест работы, так что один эндпоинт в вебе для доступа - самое лучшее.

значительно повышена скорость восстановления базы данных

Восстановления после чего?

Вместо повышения надежности увеличивают скорость ремонта?

ну дак я и хотел сказать - не оптимально использовать движек с базой данных, в противовес с обычным «текстовым движком» (можно так оформить «структуру» тхт-файла, что он будет комфортно читаться в любом тхт-просмотрщике, легкий пример - ini-формат)

имхо :о)

Потому что это 1234

ну... блин, это и так понятно «технарю» с разбега. интересовал бОлее глУбинные смумслии :о)

а вот

с твоими запиПсульками

я не просил разбираться, не надо натягивать бочку на голову :о) наличие «движка» - я привел как пример «простоты и ядерной надежности», если вы не поняли, то - вот, я дополняю свою мымсль... :о)

запиПсулька

это полно-размерный GUI/CLI-записная книжка (и комменты я оставляю для себя такие, какие мне НУЖНЫ, помогают работать и... внезапно - нравятся :о)

ну теперь мы пОняли др-др?! :о)

да, вот это меня бОлее и сповергло «спросить парней»... :о)

работаем с падениями - зато ремонтируем быстро

Восстановления после чего?

Например, https://manual.calibre-ebook.com/ru/faq.html#the-list-of-books-in-calibre-is-blank:

Список книг в calibre пуст!

Чтобы понять, почему это произошло, вы должны понимать, что такое библиотека calibre. На самом базовом уровне библиотека calibre - это просто папка. Всякий раз, когда вы добавляете книгу в calibre, файлы этой книги копируются в эту папку (сгруппированные по подпапкам по автору и названию). Внутри папки библиотеки calibre на верхнем уровне вы увидите файл с именем metadata.db. В этом файле calibre хранит метаданные, такие как название/автор/рейтинг/теги, для каждой книги в вашей библиотеке calibre. Список книг, который отображает calibre, создается путём чтения содержимого этого файла metadata.db.

Существует две причины, по которым Calibre показывает пустой список книг:

• Папка вашей библиотеки calibre изменила свое местоположение. Это может произойти, если он был на внешнем диске и буква диска для этого диска изменилась. Или если вы случайно переместили папку. В этом случае calibre не может найти свою библиотеку и вместо этого запускается с пустой библиотекой. Для исправления щёлкните правой кнопкой мыши значок calibre на панели инструментов calibre и выберите «Переключить / создать библиотеку». Щёлкните по маленькому синему значку, чтобы выбрать новое расположение библиотеки calibre, и после выбора расположения нажмите OK. Если вы не знаете новое местоположение, найдите на своем компьютере файл metadata.
• Ваш файл metadata.db был удален / поврежден. В этом случае вы можете указать calibre восстановить файл metadata.db из его резервных копий. Щёлкните правой кнопкой мыши значок calibre на панели инструментов calibre и выберите «Обслуживание библиотеки - Восстановление базы данных». calibre автоматически перестроит файл metadata.db.

Иногда читаю книги череж это.

По словам одного из разработчиков, время восстановления базы данных из 5.5 тысяч книг сократилось с более чем 5 часов до 5 минут.

Это не соответствует действительности, как уже было подмечено выше. Разработчик воспользовался результатом работы пользователя Calibre по точной идентификации причины проблемы, подтверждённое на практике патчем. Разработчик реализовал альтернативное решение, якобы более надёжное, но не упомянул в коммите значительный вклад того пользователя.

Надо будет потыкать. Спасибо.

Как же печально и ненативно смотрится Qt на macOS :(

Юзабельно по сравнению MyHomeLib и на больших архивах (флибуста, либрусек)?

Может кто объяснить, как настроить отправку на обычный андроид планшет?

Много-много лет пользуюсь этим софтом. Небыстрая, но отличная программа.

спасибо тебе добрый человек, давно искал нечто подобное

Или через MTP, или через драйвер папки.

Вот когда они переделают это всё на postgresql по-умолчанию тогда и поговорим

И многопользовательский интерфейс! Загнать туда всё содержимое РГБ и радоваться (потому что иначе, зачем там постгрес?).

Чего именно? Посылочного ящика из отделения Почты России?? ;D :)))

Для андроид есть приложение данное?

Не волнует, банк сам разберётся) А вот СДЭКу надо научиться доставлять книги…

Этого нет. Но большинство читалок умеют в локальную библиотеку с фильтрацией.

иначе, зачем там постгрес

Ну я видел на LOR людей, которые жаловались на то, что calibre тормозит из-за того, что в одной директории скапливается много книг.

Тушки книг можно было бы помещать не в файловую систему, а через СУБД.

SQLite …

поясните в 3х словах необходимость использования «движков» (пусть даже и маленьких) в таких и подобных «частно/приватно/корманных» прилажухах.

Поясняю. SQLite это один из настоящих алмазов современного программостроения. Это маленькая, функциональная, производительная библиотека, покрытая каким-то безумным числом тестов, используемая на всех мыслимых платформах. В любом смартфоне сотни sqlite баз.

Если ты сохраняешь данные, у тебя всегда встаёт вопрос о том, как это делать. Файловая система с радостью испортит твой файл. А если файлов два - файловая система с радостью сделает любую неконсистентную бяку. При этом авторы sqlite сделали огромные усилия, чтобы в этих условиях БД работала корректно. Усилия, про которые ты даже не подозреваешь и которые ты с вероятностью 99% не повторишь.

Поэтому для абсолютно любых данных, которые хоть сколько-нибудь ценны, лучше использовать sqlite. А уж для данных, которые хранятся в табличной форме, это вообще, как говорится, ноу-брейнер.

Риск порчи и потери данных при самопальной системе хранения гораздо больше, чем при использовании sqlite.

Звучит как гонево, но даже и так — проще не хранить все файлы в одной директории, банальное правило «один набор авторов → один каталог» позволит решить проблему.

Я б зашёл с другого боку. Здесь риск потери данных не важен, БД всегда можно переиндексировать. Главное, SQLite — стандарт. Все знают как с ним работать, как пользоваться, как чинить, какие особенности на каких данных возникают, есть куча документации и людей, у которых можно попросить помощи. В случае самодельного велосипеда — ничего этого нет.

Бывают случаи, когда каждый процент скорости важен, тут можно заморачиваться и извращаться, но в Calibre явно не та ситуация.

Риск порчи и потери данных при самопальной системе хранения гораздо больше, чем при использовании sqlite.

про sqlite-потерю не будем вспоминать (в данном разрезе, коли есть такие темы как «улучшено востановление и бла-бла-бла»), а вот «свой движ» юзается очень давно и ни разу ни чихнул, используются обычные функции доступа к ф.с./файлам (а учитывая, что программирование это «сопутствующее» а не основное, то... еще раз упс! :о)

и еще раз - я не к тому, что мой движёк супер-пупер (наоборот), но, тем не менее в данном конкретном случае база данных, основанная на файловой системе и простом файле - оказалась как ни есть идеальна! (писалось именно для небольшого простого приложения, для себя, для вредного :о)

а в нашем случае, как-то «менеджер книг» ... ну ребята, ну сами посудите!

каталог книг можно сделать так-же, полагаясь на «файловую систему»: создаем корневую папку «каталогизатора» и в нем делаем мыслиммо/немыслеммую систему «каталогов» с книгами, как нам душе угодно.

если к.л. книга/книги лежат вне «каталога», можно добавить «текстовый файл» с полными путями + добавить туда-же «описание от себя» и какие-либо необходимые поля.

а вот собственно, для чего база нужна, так это для «псевдо-данных», а именно: описание книги (от себя), тек.страница/строка, какие-то выделение, подчеркивания, ремарки на полях итд. так можно-же к каждой книге добавить свой txt-файл и положить его рядом с книгой и смотреться это будет очень даже:

из раннего - хочу бабу.txt
из раннего - хочу бабу.pdf
из раннего - хочу бабу.jpg 

а движку каталагизатора остается только работать с файловой системой.

Файловая система с радостью испортит твой файл

равноценно, с удовольтсвием испортит как мой txt-файл, так и файл базы данных :о).
если ф.с. что-то портит, то это уже проблемы на гОлову выше! и уж тем более надо-бы заняться именно этими проблемами, а не «книжками».
это такой-же «вязкий» довод по поводу механических часов, что они надежнее и «а вдруг» в магазинах не будет батареек к ним.
так вот, я думаю, если не будет батареек к часам, хозяину часов явно будет не до часов, в случае такого катаклизма... а если вы к тому, что «много сил» вложено на то, что-бы следить за сохранностью файла базы, бекапить его итд... блин, ну бред-же! кодинг ради кодинга, как китайские пинанеры)
и возвращаемся к нашим батарейкам, может лучше позаботиться о том, что-бы система работала стабильно (ну. т.е. как задумано изначально?), а уж если так сильно надо, то «обычным бекапом» владеет любой худо-бедно соображаюший человек. не призываю к «помидоро-киданю», но «эта» проблема на уровень выше чем «пользовательские софтины», если система глючит и портит файлы, то о чем вообще можно говорить?! :о)

в моем движке - «все примерно так» и работает: файловая система и файлы (с 2000 года ни разу не чихнула... и вопрос: оно того стОит, что-бы вот так работать и не доставлять ни каких проблем?! сейчас, пожалуй, даже не найду «исходников», так давно это было :о)

априори на вопрос:
- а время поиска / чтения...?!
отвечаю:
- какие проблемы-то с нынешними-то скоростями доступа/кешированием итд?

ни чего не имею против «движков», но для соотв. направления: мощные вычисления, серьезные базы итд или там, где он действительно нужен а не ... иногда «портит» базу :о)
но в данном случае: каталагизатор книг, для личного пользования (да даже для какого угодного) - достаточно простая по функционалу софтина(я не говорю, что это вообще никакая софтина, только то, что сказал)
не нужно из простой приложухи делать КДЕ/Плазму! вспомните старого гнома, он хоть и был «нечто» по сравнению с «остальными», но работал без вопросов и очень надежно :о)

p.s. все имхо, с любой критикой согласен заранее :о)

Ты предлагаешь реализовать базу данных на основе фс. Смысл делать велосипед, если есть нормальная бд? Просто потому, что можешь?

я где-то это предлагал?! смысл выкладки был совсем в другом!

реализовать базу данных на основе фс.

база данных уже по умолчанию использует ф.с. :о)

база данных уже по умолчанию использует ф.с.

Ой ли??.. ;)

где хранятся файлы баз данных? на фирменных модулях RAM с бат.запиткой? раньше хранились на том-же жестком диске в виде файлов, как дела нынче с этим? (может я отстал, всяко бывает :о)

SQlite – вполне себе пример простоты и ядерной надежности. И при этом не надо городить никаких велосипедов.

БД хранится в виде файла.

БД хранится в виде файла.

ну таки, я о чем?! :о)

где хранятся файлы баз данных?

Какой именно базы данных??..

И, туда же: почему именно «файлы»??..