Поиск по [1] названию, [2] автору, [3] тексту выбранной книги

[audetv]

          > Подумал, что мы же можем применить те же регулярные выражения и даже методы callkewords и qcallsuggest из мантикоры и, например, запустить новый процесс парсинга, который будет каждый параграф делить по разделителю «пробел» и пропускать каждое слове через фильтр, фильтр ещё надо придумать: регулярное выражение, callkewords, qcallsuggest. В итоге мы можем получить сначала новую базу данных в postgress и потом запустить новую индексацию на новых данных.

То есть callkeywords и qcallsuggest выполнять на входе индексатора базы из постгрес?

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

Надо бы к ней добавить все остальные базы — словари, географию и концептуальную.

По использованию пока заметил, что не хватает поиска по названию / автору книги, а также ограничения поиска конкретной книгой. А там и до жанров недалеко.

Originally posted by @iprst in https://github.com/terratensor/regular-library/issues/1#issuecomment-1742143077

[iprst]

Наблюдения за время работы с большой библиотекой.

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

В качестве быстрого варианта работы с книгой можно расширить функционал контекста: показывать можно такую же страницу как сейчас (± параграфы до и после выбранного), но эта страница оснащается пагинатором, который в обе стороны ограничен размерами выбранной книги.

---

Другой сложностью является установление так сказать степени доверия выбранному источнику. Для начала хотя бы на уровне концепции — наша или чужая. Задача не вполне тривиальная, возможно что-то вроде https://github.com/terratensor/LLM-KOB-DOTU/issues/4 будет полезным.

[audetv]

Самые большие недостатки библиотеки это во-первых невозможность работать с отдельной книгой, набором книг, разделом, жанром и так дале; во-вторых невозможность сохранить найденные результаты поиска; и в-третьих отсутствие возможности скопировать подходящий параграф и название книги одной кнопкой.

Надо запланировать работы и провести обновление.

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

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

С жанрами хуже, пока ничего для этого нет, кроме самих книг. Деления по категориям в текущей реализации отсутствует.

Сохранить результаты поиска для себя, чтобы потом легче воспользоваться прошлыми изысканиями. Логично, замечал, эту потребность, надо сделать. Вести некоторый лог запросов и дать возможность добавлять запросы в избранное. Формировать некий список ссылок на результаты поиска и дать возможность его просматривать, редактировать, удалять добавлять запросы/записи.

Реализация функционала копирование параграфа и названия книги, да согласен. Надо реализовать. https://github.com/terratensor/kob-library-app/issues/38

В качестве быстрого варианта работы с книгой можно расширить функционал контекста: показывать можно такую же страницу как сейчас (± параграфы до и после выбранного), но эта страница оснащается пагинатором, который в обе стороны ограничен размерами выбранной книги.

Я что-то подобное делал ранее в библиотеке КОБ, но после обсуждения убрал: https://github.com/terratensor/kob-library-app/pull/34 Да это можно реализовать.

Другой сложностью является установление так сказать степени доверия выбранному источнику. Для начала хотя бы на уровне концепции — наша или чужая. Задача не вполне тривиальная, возможно что-то вроде terratensor/LLM-KOB-DOTU#4 будет полезным.

Мысль интересная про степень доверия. Пока не понятно технически. Варится в котелке. Надо работать в этом направлении.

В итоге изменений на целую новую версию. Запланирую буду реализовывать.

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

[audetv]

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

Хотя здесь я возможно и не прав по поводу возни с БД. С учетом полученного уже после реализации библиотеки опыта есть мысль избавится от БД postgres вообще, и уйти от индексатора мантикоры. Т.е. сделать реализацию с RT таблицей. Так деланы комментарии на ФКТ. так сделан feed.svodd.ru. Так что скорее всего возни с БД уже не будет. Есть мысли как этого избежать. Более того я планирую улучшить код парсера, чтобы он в несколько потоков обрабатывал книги и записывал сразу в мантикору пачками по 10 000 записей. Если все сделать правильно, то процесс создания БД из файлов с нуля будет занимать примерно 20 минут. Это время может быть скорректировано, если не удастся реализовать некоторые задумки, но все же думаю, что это будет что-то в этом пределе.

Мысль направилась в новую реализацию, сделаю проще и функциональнее. Но пока от докера не избавится.

[iprst]

Мысль интересная про степень доверия. Пока не понятно технически. Варится в котелке. Надо работать в этом направлении.

Технически нужно направить вордовские файлы в сторону @terekon1 и посмотреть в итоге, в какой степени обучаемый LLM робот и можно ли формулировать задачи как нужно, и не формулировать как не нужно (с)

[audetv]

Сделал реализацию на коленке с workerpool. Каждый файл подается как задача на выполнение парсинга отдельному worker'у. При запуске можно указать разное количество воркеров в пуле. Протестировал на сете из 1000 файлов с разными значениями concurrency на компьютере Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz 2.90 GHz 6 процессоров 6 потоков. В идеале рекомендуют отдельную задачу выделять на один проток, но я пробовал значения больше чем количество процессоров. По монитору ресурсов процессоры заняты все на 100% при работе парсера.

concurreny 1
2024/05/01 18:56:16 books_djvu_prose_voronkova_lf04.docx #999 done
2024/05/01 18:56:16 all files done
2024/05/01 18:56:16 Обработка завершена за : 3m23.19880515s

concurreny 6
2024/05/01 18:59:33 books_djvu_prose_voronkova_lf04.docx #999 done
2024/05/01 18:59:33 all files done
2024/05/01 18:59:33 Обработка завершена за : 54.926487935s

concurreny 10
2024/05/01 19:01:02 books_djvu_prose_voronkova_lf04.docx #999 done
2024/05/01 19:01:02 all files done
2024/05/01 19:01:02 Обработка завершена за : 51.301609281s

concurreny 24
2024/05/01 19:02:27 books_djvu_prose_voronkova_lf04.docx #999 done
2024/05/01 19:02:27 all files done
2024/05/01 19:02:27 Обработка завершена за : 46.53749221s

concurreny 12
2024/05/01 19:04:40 books_djvu_prose_voronkova_lf04.docx #999 done
2024/05/01 19:04:40 all files done
2024/05/01 19:04:40 Обработка завершена за : 48.075617646s

Итого если пересчитать на 150 к, то парсер в 1 поток с записью в БД postgress будет работать 8 часов. Потом еще нужно примерно столько же времени на индексацию в мантикору из БД (хочу пропустить этот шаг) Я если честно и не помню как было на самом деле, надо поискать возможно где-то в issues есть статистика, но видимо да, примерно такое время, иначе зачем заморачиваться с передачей БД через торрент.

А вот если взять 12 workeroв / потоков. то это уже 48 сек на 1000 файлов, т. е. в пересчете на 150 к это всего 2 часа. 2 часа это точно не 20 минут, которые я объявил в начале темы, сильно ошибся. Но это не и 8 часов. Если вести запись сразу в мантикору, то по идее за эти же 2 часа можно получить готовую сборку, это уже проще, чем качать торрент.

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

[audetv]

Протестировал на рабочем компьютере 12th Gen Intel(R) Core(TM) i7-12700 2.10 GHz Общее количество ядер 12 Максимальное число потоков 20

concurreny 40
Task books_djvu_prose_voronkova_lf04.docx processed
2024/05/01 20:30:52 all files done
2024/05/01 20:30:52 Обработка завершена за : 15.4410917s

concurreny 20
Task books_djvu_prose_voronkova_lf04.docx processed
2024/05/01 20:33:17 all files done
2024/05/01 20:33:17 Обработка завершена за : 16.408816s

Т. е. можно выставлять concurrency равное количеству потоков процессора и это будет оптимально, для ускорения можно поиграть параметром. Сделаю файл конфигурации или параметр командной строки для указания количества worker. По умолчанию надо сделать функцию, которая прочитает в системы доступное количество потоков и установит это число по умолчанию.

В общем скорость обработки будет зависеть от доступной мощности компьютера.

[audetv]

По жанрам. В наименованиях файлов содержится жанр/рубрика:

Биология, биофизика, биохимия _Ярбус А — Роль движений глаз в процессе зрения.docx Боевая фантастика_Tomon_1 — Выжившие.docx

Можно для начала выделить это из имени файла в отдельное поле в БД для фильтрации, есть в этом смысл?

[iprst]

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

[audetv]

Обработал 143 865 doc файлов 40,2 ГБ (43 206 465 029 байт) Получил БД postgres. 31 096 820 параграфов (65 Гб база)

Worker 10 processes task - рауль.docx
Task рауль.docx processed
2024/05/01 21:21:26 all files done
2024/05/01 21:21:26 Обработка завершена за : 32m45.2541254s

Результатом доволен. Очень сильно сокращает время сборки, если запустить в 20 потоков.

Так что в ближайшее время постараюсь сразу сделать запись в мантикору минуя БД и сравнить.

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

Хорошо, если пойти далее , в наименовании содержится и имя автора и наименование книги, может стоит их все разделить на 3 отдельных поля? Жанр, автор, наименование. Для поиска и фильтрации. Полезность пока не ясна, но технически эта задача не является сложной, можно сделать.

[iprst]

2024/05/01 21:21:26 Обработка завершена за : 32m45.2541254s

Огонь.

Хорошо, если пойти далее , в наименовании содержится и имя автора и наименование книги, может стоит их все разделить на 3 отдельных поля? Жанр, автор, наименование. Для поиска и фильтрации. Полезность пока не ясна, но технически эта задача не является сложной, можно сделать.

Да, да. Файлы назывались целенаправленно, с экспортом из базы, при экспорте из кучи архивов файлами присваивалась формула. В оригинале файлы имеют нечитаемые номера типа id в базе с датой или что-то вроде, и всё это запаковано в несколько сотен или тысяч архивов. Если пойти дальше, то ещё какие-то поля можно вынуть из оригинальной базы, там они есть. В простейшем виде так, но есть и более развёрнутые представления:

[audetv]

Сделал версию, которая пишет в мантикору, разделяет имя файла, на жанр, автора и наименование. Прогнал уже пару раз на всей библиотеке 150к, наметил улучшения, пока результат такой:

…
Worker 8 processes task - Язычество_Чуруксаев Олег — Тайная книга Волховства.docx
Task Язычество_Чуруксаев Олег — Тайная книга Волховства.docx processed
Worker 5 processes task - рауль.docx
Task рауль.docx processed
2024/05/03 13:57:23 all files done
2024/05/03 13:57:23 Обработка завершена за : 56m48.6198957s

20 потоков, 57 минут от док файлов до готовой базы. 167,3 Гб БД indexed_documents: 31 096 811

Пример ответа на запрос Монте-Альбан limit=2:

{
    "index": "library",
    "highlight": {
        "fields": [
            "genre",
            "author",
            "title",
            "text"
        ],
        "limit": 0,
        "pre_tags": "<mark>",
        "post_tags": "</mark>"
    },
    "query": {
        "query_string": "Монте-Альбан"
    },
    "limit": 2,
    "offset": 0,
    "max_matches": 1000
}

Details Response Body

``` { "took": 17, "timed_out": false, "hits": { "total": 543, "total_relation": "eq", "hits": [ { "_id": "4398164253416954104", "_score": 2893, "_source": { "genre": "История", "author": "Соди Деметрио", "title": "Великие культуры Месоамерики", "text": "

Испанский вариант М. Леона-Портильи. – Прим. авт.

)

Итак, вместе с Кецалькоатлем завершается еще один период древней мексиканской истории.

Оахака и побережье мексиканского залива

В нашем кратком обзоре Месоамерики нельзя не рассказать, пусть и в сжатой форме, об Оахаке и хотя бы перечислить основные черты культур побережья Мексиканского залива.

Оахака

Древняя история Оахаки тесно связана с археологическим центром Монте-Альбан, одним из самых впечатляющих в данном районе. Его название используется и для периодизации оахакской археологии. Р. Пинья-Чан выделяет следующие хронологические этапы:

Заселение Оахаки

Монте-Альбан-I

(Поздний доклассический период – 800– 300 лет до н. э.)

Зарождение сапотекской культуры

Монте-Альбан-II

(Протоклассический период – 300—100 гг. до н. э.)

Расцвет сапотекской ку

льтуры

Монте-Альбан-III-а и III-б

(Классический период – 100—800 гг.)

Упадок сапотекской культуры

Монте-Альбан-IV и V

(Постклассический период 800—1521 гг.)

Долина Оахаки была колыбелью целого ряда цивилизаций, представленных в различные эпохи в целом неизвестными нам народами.

Митла, Саачила и особенно Монте-Альбан, расположенный неподалеку от нынешней столицы штата г. Оахаки, позволяют нам довольно точно датировать культуры, получившие распространение в Долине до Конкисты. По всей вероятности, Монте-Альбан был заселен предшественниками сапотеков где-то в VIII—VII вв. до н. э. Эти племена соответствовали представителям месоамериканских культур позднего доклассического периода. Видимо, они были археологическими ольмеками, которые начали создавать архитектуру и скульптуру.

В период Монте-Альбан-II благодаря прибытию новых поселенцев, возможно выходцев из Чьяпаса и Гватемалы, смешавшихся с ольмеками, первыми обитателями этих мест, началось развитие культуры, ставшей в дальнейшем сапотекской. Однако эта культура получила свое признание лишь благодаря теотиуаканскому влиянию, распространившемуся в конце Монте-Альбана-II. Культура Теотиуакана значительно превышала уровень развития проживавших там ольмеков и майя.

", "position": 79, "length": 2265 }, "highlight": { "genre": [ "История" ], "author": [ "Соди Деметрио" ], "title": [ "Великие культуры Месоамерики" ], "text": [ "

Испанский вариант М. Леона-Портильи. – Прим. авт.

)

Итак, вместе с Кецалькоатлем завершается еще один период древней мексиканской истории.

Оахака и побережье мексиканского залива

В нашем кратком обзоре Месоамерики нельзя не рассказать, пусть и в сжатой форме, об Оахаке и хотя бы перечислить основные черты культур побережья Мексиканского залива.

Оахака

Древняя история Оахаки тесно связана с археологическим центром Монте-Альбан, одним из самых впечатляющих в данном районе. Его название используется и для периодизации оахакской археологии. Р. Пинья-Чан выделяет следующие хронологические этапы:

Заселение Оахаки

Монте-Альбан-I

(Поздний доклассический период – 800– 300 лет до н. э.)

Зарождение сапотекской культуры

Монте-Альбан-II

(Протоклассический период – 300—100 гг. до н. э.)

Расцвет сапотекской ку

льтуры

Монте-Альбан-III-а и III-б

(Классический период – 100—800 гг.)

Упадок сапотекской культуры

Монте-Альбан-IV и V

(Постклассический период 800—1521 гг.)

Долина Оахаки была колыбелью целого ряда цивилизаций, представленных в различные эпохи в целом неизвестными нам народами.

Митла, Саачила и особенно Монте-Альбан, расположенный неподалеку от нынешней столицы штата г. Оахаки, позволяют нам довольно точно датировать культуры, получившие распространение в Долине до Конкисты. По всей вероятности, Монте-Альбан был заселен предшественниками сапотеков где-то в VIII—VII вв. до н. э. Эти племена соответствовали представителям месоамериканских культур позднего доклассического периода. Видимо, они были археологическими ольмеками, которые начали создавать архитектуру и скульптуру.

В период Монте-Альбан-II благодаря прибытию новых поселенцев, возможно выходцев из Чьяпаса и Гватемалы, смешавшихся с ольмеками, первыми обитателями этих мест, началось развитие культуры, ставшей в дальнейшем сапотекской. Однако эта культура получила свое признание лишь благодаря теотиуаканскому влиянию, распространившемуся в конце Монте-Альбана-II. Культура Теотиуакана значительно превышала уровень развития проживавших там ольмеков и майя.

" ] } }, { "_id": "4398164253415741870", "_score": 2876, "_source": { "genre": "История", "author": "Непомнящий Николай", "title": "100 великих городов древности", "text": "

А самая загадочная находка из Монте-Альбана — хрустальные человеческие черепа. Горный хрусталь — один из самых твердых минералов на земле. В 1970 г. один из этих черепов был исследован авторитетными экспертами. Они пришли к заключению, что череп вырезан из одного куска хрусталя вместе с нижней челюстью. Резать горный хрусталь нельзя ничем, кроме алмаза. Но сапотеки все-таки сумели обработать этот материал. При такой твердости материала это более чем загадочно.

Примерно 6 тыс. лет назад в долине Оахаки уже появлялись отдельные поселения. После утраты значения Сан-Хосе-Моготе — самого важного места в долине, Монте-Альбан, вероятно, был основан в VI в. до н. э.

Монте-Альбан

Первые календарные знаки, главным образом символы из 260-дневного календаря (тцолкина), высеченные на камне, — вероятно, самые ранние отпечатки цивилизации. Были ли первые поселенцы и строители храмов сапотеками, остается неизвестным.

Период Монте-Альбан I (600–200 гг. до н. э.) характеризуется художественными особенностями ольмеков. Между 500 и 400 гг. до н. э. развивается практически уже городское поселение, от которого остались простые могилы с керамикой, высеченные из камня блоки с барельефами человеческих фигур и 260-дневных календарей.

В период Монте-Альбан II (200 г. до н. э. — 100 г. н. э.) становится очевидным влияние доклассических майя с юга. Этот стиль характеризуют керамика лучшего качества, завершенный календарь и большие сооружения.

Следующие фазы Монте-Альбан Ша (примерно до 400 г.) и Монте-Альбан IIIb (примерно до 800 г.) знаменуют культурный расцвет. Строятся важнейшие здания в стиле Талуд-Таблеро (вертикальные панели чередуются с наклонными стенами), появляются сложные погребальные комнаты с красивыми фресками и урнами из глины разнообразных форм.

В первой половине этого периода проявляются стилистические элементы цивилизации Теотиуакан с центрального плато. К концу периода обнаружено культурное влияние мицтеков (миштеков).

", "position": 311, "length": 2023 }, "highlight": { "genre": [ "История" ], "author": [ "Непомнящий Николай" ], "title": [ "100 великих городов древности" ], "text": [ "

А самая загадочная находка из Монте-Альбана — хрустальные человеческие черепа. Горный хрусталь — один из самых твердых минералов на земле. В 1970 г. один из этих черепов был исследован авторитетными экспертами. Они пришли к заключению, что череп вырезан из одного куска хрусталя вместе с нижней челюстью. Резать горный хрусталь нельзя ничем, кроме алмаза. Но сапотеки все-таки сумели обработать этот материал. При такой твердости материала это более чем загадочно.

Примерно 6 тыс. лет назад в долине Оахаки уже появлялись отдельные поселения. После утраты значения Сан-Хосе-Моготе — самого важного места в долине, Монте-Альбан, вероятно, был основан в VI в. до н. э.

Монте-Альбан

Первые календарные знаки, главным образом символы из 260-дневного календаря (тцолкина), высеченные на камне, — вероятно, самые ранние отпечатки цивилизации. Были ли первые поселенцы и строители храмов сапотеками, остается неизвестным.

Период Монте-Альбан I (600–200 гг. до н. э.) характеризуется художественными особенностями ольмеков. Между 500 и 400 гг. до н. э. развивается практически уже городское поселение, от которого остались простые могилы с керамикой, высеченные из камня блоки с барельефами человеческих фигур и 260-дневных календарей.

В период Монте-Альбан II (200 г. до н. э. — 100 г. н. э.) становится очевидным влияние доклассических майя с юга. Этот стиль характеризуют керамика лучшего качества, завершенный календарь и большие сооружения.

Следующие фазы Монте-Альбан Ша (примерно до 400 г.) и Монте-Альбан IIIb (примерно до 800 г.) знаменуют культурный расцвет. Строятся важнейшие здания в стиле Талуд-Таблеро (вертикальные панели чередуются с наклонными стенами), появляются сложные погребальные комнаты с красивыми фресками и урнами из глины разнообразных форм.

В первой половине этого периода проявляются стилистические элементы цивилизации Теотиуакан с центрального плато. К концу периода обнаружено культурное влияние мицтеков (миштеков).

" ] } } ] } } ```

В случае если не удалось распознать жанр, автора и наименование регулярным выражением, то имя файла, без расширения полностью сохраняется в поле title, жанр и автор пустые.

[iprst]

Круто. А как получилось, что база мантикоры на 100 Гб меньше текущих 254 Гб?

[audetv]

Да, интересно, не обратил внимание, предполагаю, что это связано с тем, что я подключил RT Columnar таблицу https://manual.manticoresearch.com/Creating_a_table/Data_types#Row-wise-and-columnar-attribute-storages

Проверю позже просто на RT row-wise - traditional storage available in Manticore Search out of the box будет ли разница. Но получается, что разница по объему с локальной таблицей, а раньше была local table, очень ощутима.

Columnar рекомендуют использовать, если вся таблица не вмещается в память, наш объем не помещается и я использовал колоночный тип, получили бонусом уменьшения размера? из-за «the blocks are stored compressed. »

Проверю еще row-wise

With the columnar storage:

• each attribute is stored independently of all other attributes in its separate "column"
• storage is split into blocks of 65536 entries
• the blocks are stored compressed. This often allows storing just a few distinct values instead of storing all of them like in the row-wise storage. High compression ratio allows reading from disk faster and makes the memory requirement much lower
• when data is indexed, storage scheme is selected for each block independently. For example, if all values in a block are the same, it gets "const" storage and only one value is stored for the whole block. If there are less than 256 unique values per block, it gets "table" storage and stores indexes to a table of values instead of the values themselves
• search in a block can be early rejected if it's clear the requested value is not present in the block.

The columnar storage was designed to handle large data volume that does not fit into RAM, so the recommendations are:

• if you have enough memory for all your attributes you will benefit from the row-wise storage
• otherwise, the columnar storage can still give you decent performance with a much lower memory footprint which will allow you to store much more documents in your table

[audetv]

После индексации колоночного типа получено было 3659 файлов, выглядит так:

Details


Разбито на чанки и запаковано.

[iprst]

Да, похоже колоночная схема позволяет удачно компрессировать такие текстовые данные. В текущей базе всего 46 файлов, притом самый большой 110 Гб.

[audetv]

Результат для просто rowwise RT table не сильно отличается от колоночной, результат такой же по времени, на уровне погрешности +/- пара минут.

Worker 20 processes task - рауль.docx
Task рауль.docx processed
Worker 19 processes task - Язычество_Чуруксаев Олег — Тайная книга Волховства.docx
Task Язычество_Чуруксаев Олег — Тайная книга Волховства.docx processed
Worker 8 processes task - Язычество_Черкасов Илья — Зов Гипербореи.docx
Task Язычество_Черкасов Илья — Зов Гипербореи.docx processed
2024/05/03 17:30:26 all files done
2024/05/03 17:30:26 Обработка завершена за : 54m32.9639748s

168.2 Гб indexed_documents 31 096 811

Кол-во файлов в папке около 27 000 штук. После завершения видно, что мантикора работает и проводит какие то оптимизации с файлами, и через несколько минут их уже было около 25 000 штук. и пока процесс не завершен, но парсер отработал и все записи сохранены. Позже проверю, что с файлами, уменьшилось ли занимаемое место.

Возможно в колоночной было что-то подобное с количеством файлов, просто я не обратил внимание, т.к. уже видел результат после завершения, через некоторое время. Интересно, проверю потом.

[iprst]

Прогресс налицо. Интересно, какой вариант работает быстрее всего на слабых виртуальных машинах.

[audetv]

Спустя час уже около 5000 файлов, мантикора все это время работает фоном, я так понимаю, собирает несколько файлов, проиндексированных, которые ей будет проще закидывать целиком в память.

Details


Прогресс налицо. Интересно, какой вариант работает быстрее всего на слабых виртуальных машинах.

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

Конечный результат на диске в колоночном варианте получаем раньше, условно 3000+ файлов, в режиме rowwise похоже еще требуется более часа для оптимизации индекса. Надо будет сделать 2 варианта и потестировать. Но точно от локальной таблицы надо уходить. локальная таблица — это наш самый первый пилотный вариант.

[iprst]

Неожиданная разница во времени из-за оптимизации.

[iprst]

локальная таблица — это наш самый первый пилотный вариант

Было бы всё равно неплохо заменить локальную базу 250 Гб на 150 Гб в новом варианте ))

[audetv]

Работаю над новой версией, парсер уже протестировал несколько раз, прогонял на разных движках (таблиц мантикоры). Выделили поля жанр, автор и книга для фильтрации. Думаю в ближайшее время сделаю обновление. На компьютере с i7 12 процессора 20 потоков, парсер собирает БД за 50 мин - 1 час 10мин. на компьютере 6 проц. 6 потоков это уже происходит за 3-4 часа.

Плюс потом нужно какое-то время (~несколько часов), когда мантиокра работает фоном и оптимизирует индекс и файлы. Но в это время можно искать, искать можно сразу, как только запустил парсер (по мере добавления записей в БД). Но после операции оптимизации время поиска сокращается в разы.

Так что будет позже вопрос. Будем ли новый индекс БД раздавать через торрент или все же попробуем собрать на локальной машине из исходников. Но видимо все же надо в любом случае будет описать оба варианта в инструкции. Собрать из старых записей обновленную инструкцию.

В работе

[audetv]

Вообще судя по тому что я вижу, получается уже (близко, связь заметил) парсер, который можно использовать для создания индекса любой своей локальной библиотеки. С любыми своими наборами документов и книг. КОБ, военно-историческая, любая другая. Метод один и тот же. В планах в том числе допилить КОБ и обновить нашу онлайн КОБ библиотеку http://kob.svodd.ru по единому принципу с приведением длины параграфов к среднему значению в 3600 символов.

[audetv]

https://github.com/terratensor/svodd/issues/321#issuecomment-2283730242 Установим связь с оформлением карточки.