Формирование выдачи результатов поиска #2
Comments
iprst
added
documentation
|
Тестирую парсер. Всё описанное в README работает, парсер парсит docx, постман ищет запросы.
|
Да точно не написано. Т.е. если в папку Можно для тестирования/экспериментов сделать так:
Добавление папки Или же можно делать совсем просто, если возникла вышеописанная ошибка при вводе команды git pull, просто удалять всю папку и клонировать репозиторий снова. Почему бы и нет).
По идее второй вариант правильнее, если по методичкам подходить, как рекомендуют. Но мы же тестируем и оба варианта могут быть для нас приемлемы.
На данный момент не могу сказать, но точно не сложнее, чем docx. Эти форматы по структуре вроде более простые. Почитаю, посмотрю. Думаю сделаем. |
|
По фронтенду, согласен, так и сделаем. Хочу предупредить, что мне надо рабочий проект закончить и придется недели две сосредоточиться на нем и решить вопросы. Я просто не смогу сейчас сделать фронтенд, как только там будет результат, переключусь обратно, иначе мне пока сложно, в том плане, что я начинаю делать задачи тут, которые интереснее, и не сделаю там. Фиксить баги и простые изменения я буду, я буду полностью доступен, и буду участвовать в обсуждениях, просто мне надо написать много кода по работе. Как только сделаю там основное и почувствую, что в рабочем проекте все ок, переключусь обратно к написанию кода тут. Так что, все нормально, просто маневры. |
|
Принято. Описанное понял, если будут вопросы задам для уточнения. |
И да надо в парсер добавить сохранение с привязкой к заголовку, посмотреть какими заголовками главы размечаются(технически в xml) и добавить в следующую версию парсера в выдачу: |
Этот вариант более логичный. Я правильно понимаю, что после того, как файл обработан, то его можно автоматически скопировать в «хранилище»? |
Изучил, могу вполне однозначно сказать, что сам ничего не сделаю. Я могу в принципе подправить какой-то готовый код, но не имею совершенно никакого представления как от представленных ссылок и содержащимся там файлов перейти к нашему book-parser64.exe, этот путь у меня отсутствует. |
Да, можно, но я ранее описывал вариант простой, когда база удаляется полностью и создаётся снова. Без дополнительного функционала, который сейчас не смогу добавить. Под дополнительным функционалом я имею ввиду, добавление записей (книг, файлов) в базу к уже существующим книгам и записям. Этого функционала сейчас нет, т.е сейчас можно только удалить всю базу и загрузить все файлы, которые надо парсить, снова. По идее, по хорошему для загрузки надо написать механизм, который будет отслеживать, что таких записей в БД еще нет. Т.е. что один и тот же файл не спарсен 2 раза. Проще всего удалять книгу по названию файла и загружать ее снова, если этот файл появился в папке для парсинга, т.е это надо будет еще написать, позже, в ближайшее время я это не сделаю. С комментариями я сделал так. Так как прошлые комментарии никогда не меняются, я так предположил,, т.е те, что попали в бд уже не могут быть изменены, и на сайте ФКТ комментарии не редактируют. Т.о. если комментарий с номером 2345678 уже есть в бд, то его не надо записывать снова, а надо записать только те номера, которых еще нет. Программа читает спарсенный файл, составляет массив id комментариев и сравнивает с массивом id в бд, и добавляет, только те записи которые отсутствуют. С книгами надо придумать свой алгоритм, по идее книга если загружена, то все она не меняется, а если в файле что-то поменялось, то проще книгу полностью удалить из БД и снова загрузить из файла, чем заниматься сравнением, что там поменялось в этом файле. При этом остальные записи и книги можно сохранить. В общем по загрузке книг надо будет подумать, как избегать дублирования, возможно есть и другие варианты, пока то, что пришло в голову. |
Да, хорошо, я ссылки оставил, чтобы было понятно, что какой-то готовый код уже есть, и его не надо будет искать снова, когда мы вернемся к этому вопросу. И я пока в фоновым процессом в голове обрабатываю и придумываю, как это применить потом. |
|
Сделал изменения. Поменял папку по умолчанию для обработки файлов на process
|
|
Работают оба варианта. |
|
Сколько результатов должен отдавать запрос |
|
У меня тоже 1 результат, можно конечно проверить, есть ли такое сокращение ещё в тексте и поискать по тексту файлов .txt попробую. Но с самого начала был 1 результат. Вообще мантикора в этом плане, не очень пригодна для статистических выборок, т.е. этот запрос по идее не должен делаться в поиске, так как с точки зрения алгоритма поиска он плохой. и найдет все... я не помню как я его придумал, связано с агрегацией в начале, потом внизу фильтр по type(который я специально сюда добавлял и в каждой записи проставил значение 1) и "max_matches": 353545 - какое то магическое большое число, которое должно быть явно большем чем кол-о записей в бд. |
|
Поиск по документам в Total Commander показывает, что Вера и Мера |
|
Возможно, но например, я сейчас не смог посмотреть все книги, открыл только первые 4: Вера и Мера https://github.com/audetv/book-parser/tree/main/books/VPSSSR/TXT , и поиском ctrl+f набрал пфу, и в этих файлах нет этого слова. Надо разобраться, где расхождение происходит. |
|
Возможно ТС нашёл в других кодировках. Если искать только в utf-8 и utf-16, то вроде бы всё совпадает, только одна сборная книга и несколько записок. Пока забудем. Наверное пока можно просто надеяться, что в базу добавлено всё и ищется всё, а потом придумаем как это проверить. |
При составлении этого запроса я имел ввиду, что с помощью него можно получить общее количество записей в базе, но нельзя определить полноту формирования... Я задумался и не знаю, как можно проверить полноту. Т.е. если бы я не доверял алгоритму и предположить, что он что-то вырезал, удалил, то как это проверить? Можно перед сохранением считать кол-во символов в параграфе и вывести результат в конце, что столько то символов сохранено, с некоторой погрешностью или полностью должно совпасть с кол-вом в docx. Но есть пустые парагарфы, есть всякий мусор, как кол-во символов посчитает ворд?
Или в других файлах, локальных не в архиве? может быть были удалены какие-то сноски при конвертации? Если ПФУ реально есть не в сносках, то это очень странно, даже если предположить что это сочетание букв в слове ....пфу.. Не приходит на ум такое слово, типа пропфушный. То если бы такие слова были в текущем архиве, то при открытии файла, используя обычный поиск ctrl+f они бы нашлись. Не знаю.
Возможно, можно держать это в уме и допустим, когда будет фронтед, то попробовать вычитать какую либо книгу, можно, например, восстановить по номерам параграфов последовательность и вывести на экран, на страницу в браузер для полноты эксперимента. И если есть символы - слова в книгах в другой кодировке, т.е. utf-8 и тут же coi8r, это конечно очень странно, но если буду такие аномалии, надо бы их выявить и отработать в парсере. Или смоделировать такую ситуацию. |
В свежем ворде в открытом файле количество слов прямо показано в нижнем левом углу, а кликом по нему вызывается вот такая табличка (файл «Вера и Мера»):
Нет, в оригинальном формате из архива медиамеры. Там был .doc |
Вкратце ситуация такова, обратите внимание на проставленные галочки в поисковом запросе:
Это однозначно проблема дешифровки кодировок — при подключении только utf и офисных форматов, обнаруживаются только актуальные вхождения. Но при подключении ANSI ASCII — ищется мусор. Если это актуально для баз данных, парсеров и тд, можно иметь в виду. Маловероятно, что слова типа «вседержительность» или даже «элита» будут сформированы в неправильной кодировке из мусора, но вот всякие «пфу», «гп» и даже «краб» — легко. |
|
Да, вижу и вижу слева на скриншоте «Сборник аналитических записок «Концептуальная власть на Руси», в котором как раз у нас мантикора и находит пфу. Хорошо, понял. |
|
Я проверил четырёхбуквенные слова типа краб, штык, крот, прок и тому подобные — ситуация аналогичная, в двух режимах ищутся совсем разные результаты. Так что четырёхбуквенные слова тоже представляют опасность, если где-то в системе возникнет подобный сценарий. Пишу просто чтобы запомнить и если в будущем когда-то где-то всплывёт, иметь представление откуда ноги могут расти. UPD. Нет, всё не так радужно, как я описал. В действительности актуальные вхождения могут быть обнаружены как в «правильном», так и в «неправильном» режиме поиска по документам — это зависит от обработчика знаков препинания в формате .doc / .docx и такое поведение я уже встречал в ворде. Пример. Ищем слово Такое поведение мне попалось при попытке заменить указатели сносок на собственно текст примечания — есть скрипт, который позволяет это сделать, но он не выполняет все вхождения, заменяет только часть. Те вхождения, которые расположены со знаками препинания, рядом с кавычками и так далее, просто не обнаруживаются и не заменяются. Это беспредел! |
|
Коротко: в выходные открыл для себя графовые БД, установил, попробовал. Итог, как раньше уже не будет, но что делать с изученной информацией пока не полностью осознал, надо составить план и двигаться в этом направлении дальше. Теперь подробно: посмотрел несколько графовых баз данных – это Nebula, Neo4J (авторитеты заявляют, что это лучшее, это лидер) и EdgeDB (надстройка postgres, не совсем графовая, скорее графо ориентирована, graph-relational model). Давно хотел изучить этот вопрос, дозрел и в выходные увлекся, что могу сказать: интересно, но пока не очень понятно, как эти БД можно применить в наших сценариях поиска, технически на практике, но именно поэтому, я и решил посмотреть графовые БД, чтобы сложить понимание как их применять. Я пока не знаю, как это будет работать в итоге, но уже ясно, что это целый новый мир и его надо изучить, тем более что концепция связности означает, что мы строим связный граф. Т.е. в общем то специализированные БД должны нам в этом вопросе помочь, но как соединить наш поиск и графы я пока ещё не понял, и надо ли это делать не знаю. Надо изучать. При беглом изучении инструментов понравилось, что в таких БД можно легко создавать узлы, как объекты, т.е. добавлять свойства и менять, в обычной реляционной БД это была бы таблица, а свойства – колонки, и чтобы изменить ее колонки надо изменить схему базы. По сути, узлы — это все, что надо спроектировать, а связи можно легко добавлять позже. Например, использование реляционной модели предполагает, что схема БД спроектирована и созданы нужные связи, так как на легко лету таблицы, ключи и связи не добавляются, потом структура БД отображается в код (map), т.е. надо знать заранее, что ты хочешь от системы и спроектировать её. Конечно, знать заранее это хорошо и правильно, но не во всех сценариях это осуществимо. В текущем процессе с графами, я еще к написанию кода не приступал, я сейчас на стадии изучения и понимания как извлекать данные по запросам из БД и создавать записи и связи, и как только в этом будет прогресс, то можно уже что-то программировать, и поэтому, возможно, я пока просто нахожусь в состоянии некоторой «эйфории», так часто бывает, когда изучаешь что-то новое, но много чего ещё не знаешь, и кажется, что это просто. Поэтому пока не могу адекватно сравнить подходы графовой и реляционных моделей, авторитеты говорят, что графы проще и лучше, надо проверять. Не хочу торопиться с выводами, но потребность поделиться изученным возникла. По сценариям использования графовой БД, самое первое, что пришло в голову это после каждого запроса в поиск, после получения результата обучать БД, строить связи на основе запроса. Поиск будет выдавать результаты из разных источников по какому-то запрошенному понятию, и он тем самым связывает это понятие и источники, а мы можем добавлять эти связи в граф и обучать систему. Предполагаю. Но по идее сейчас поиск создан, я имею в виду техническое решение как он сделан, так, чтобы в реальном времени по запросу выдавать результат, и поиск с этим справляется, зачем в этом случае граф? Сейчас поиск без модного ИИ, но, если добавить графы, у нас уже «самообучающаяся система», почти. В общем пока размышляю и сформировался вопрос, надо ли эти результаты хранить в БД, фиксировать и связывать отношениями - ребрами в нашем графе или нет. Ведь, по сути, мантикора это обычная плоская таблица, проиндексированная определённым образом по формам слов, в которой нет связей между таблицами, так как она одна, т.е. в поиск попадают тексты из уже обработанных, подготовленных, спроектированных источников (узлов), и мантикора справляется. Видимо я просто пока не придумал, зачем и как еще можно использовать графовую БД, хотя вспомнил, но надо будет об этом написать в следующем сообщении, вот это, например, одна из ваших идей в копилку, думаю хорошо ляжет в графовую БД:
Позже я пришел к выводу, что похоже все-таки данные надо проектировать, и не все так просто, как показывают во вступительных обучающих роликах. Предполагаю, что графовая БД может хорошо лечь в «геоматрицу». Там похоже это будет именно то, что надо. События, объекты и хэши связаны, при решении геодезических задач надо искать другие события и объекты и создавать связи между узлами – событиями и объектами. И вообще с точки зрения концепции вопросов нет, концепция связности строит граф. Вопросы у меня чисто прикладного характера, а как это все прикрутить и получить результат на наших сайтах сервисах. Из красоты, в nebula и в neo4J построенный граф выглядит красиво, да, предоставляемые инструменты рисуют кружки-ноды и связи между ними, и все это выглядит эффектно. Насмешил момент при просмотре одного обучающего видео, в котором какой-то китаец рассказывает об nebula, его собеседник китаец кивает, тот ему показывает итог манипуляций – граф картинку и собеседник ещё больше кивает и улыбается, теперь он всё понимает. Смешное представление. Кстати, все просмотренные БД имеют документацию на китайском, закономерно, тянут за уши китайский ЦКУ. По поводу нашего парсера книг, я попробовал схему книга-[]->параграф, позже выгружу ветку graph, в которой я написал код, чтобы делать csv файлы из книг для БД, файлы я загружал в nebula для экспериментов. Пока не очень, больше похоже на баловство. Обычная логика таблиц кажется проще. Я пробовал так: книга и параграф – 2 типа узлов, связываем их между собой отношением belong_to, и параграфы связываем между собой follow. Далее пытался делать запросы, пока не очень успешно, и поэтому преимуществ в такой схеме увидел не много, почти не увидел. Более того в этом примере с книгами все очень просто, и этот пример легко решается в логике реляционных баз, даже проще сделать обычных пару запросов в таблицы, чем городить огород с графами, но есть предположение, что с увеличением источников 100% увеличится количество написанного кода и обсуживать, и поддерживать такую систему будет не просто, запросы будут обрастать джойнами и циклами и система начнёт работать медленно и печально. Не факт, что графовая БД это изменит, не знаю, но что-то заставляет меня продолжать изучение в этом направлении. Ну, и куда же без авторитетов, которые заявляют, что такие задачи решает графовая модель хранения данных и графовая БД. Думаю, что надо как-то параллельно вести работу и начать разбираться с этими БД и смотреть, что из этого выходит, строить ПФУ и работать, сейчас у меня стадия, что я заметил эти инструменты, и надо бы выработать стереотип, для чего они нужны и отработать и реальные сценарии пользователей и попробовать это спроектировать, чтобы потом запрограммировать. Возможно, надо написать обучающую статью, пост и подключить всех желающих и вас к этому процессу, так как учиться с нуля, создавать графы, извлекать данные, можно вместе. Выбрать БД и начать проектировать нашу систему. Такие мысли, хотел коротко, но не получилось.
|
Понял. Можно сделать пробники на геоматрице. Поясню почему — во-первых, за это время у меня постепенно собрались очищенные CSV всех моих текущих баз геоданных, и хотя они слегка отличаются друг от друга заголовками полей и их количеством, это на несколько порядков лучше того беспредела, что творится с форматированием xml / kml файлов. В оригинале там полная беда, притом речь не о моих файлах, а об официально публикуемых источниках, в том числе серьёзных. Нашёл программу-парсер геоданных, которая переводит любой формат гео-данных в любой другой, включая все публикуемые проприетарные, от всех существующих гео-систем. За две недели разобрался и теперь есть несколько сотен тысяч достаточно однотипных записей, к которым можно прикручивать расчётку геохэшей и собирать всё это в базы, будь то мантикоры или любые другие. Сейчас проверяю последние несколько файлов перед публикацией в репозиторий. По остальному мысли есть, но написать пока некогда, буду комментировать далее по мере развития сюжета. |
Я когда вчера писал текст сообщения в течение дня, и в процессе написания появлялось понимание некоторых вещей, которые не были понятны, не формализованы лексически. Так вот мысль о том, что надо попробовать именно на геоматрице испытать графовые БД, закрепилась к вечеру довольно четко, что именно на геоматрице надо начать обучаться, а не на книгах и поиске. И позже, когда вы написали ответ на мое сообщения я получил подтверждение и окончательно эту мысль сформировал. Согласен. В геоматрице это будет очень наглядно и может принести лучший результат, а дальше полученные знания и опыт можно будет приложить к поиску, учесть и доработать. |
хорошо |
Хорошо, сделаю. У него есть какая-то страничка редактирования типа статического блока где-то в движке сайта, или просто сюда скинуть? |
Нету, пока только html, код и хардкор) upd А если будет много текста подумаем как разместить |
|
Товарищи! Мы запустили поисковик по текстам толстых книг ВП СССР Поиск реализуется внутри содержания отдельного параграфа, включая сноски, если они есть. Таким образом текстовый запрос в строке поиска служит цели найти наиболее подходящие под этот запрос параграфы. Рядом с кнопкой «поиск» есть кнопка опций, где можно выбрать режим и подключить «концептуальный словарь синонимов». Режимы поиска позволяют выбрать точное совпадение фразы в результатах (по соответствию фразе), появление хотя бы одного из слов запроса в параграфе (по совпадению слов), или найдя подходящий параграф, можно выбрать его номер и взяв соседние (отняв или добавив единицу), показать несколько параграфов подряд. Это удобно, если нужна более развёрнутая информация, но нет необходимости обращаться к целой книге. Если цель поиска — найти книгу по искомому запросу, то для этой цели в выдаче к каждой цитате присоединяется название толстой книги, откуда она была получена. Поисковый запрос, к которому вы часто обращаетесь, можно сохранить при помощи кнопки «короткая ссылка» — в ней также сохраняется режим конкретного поиска. Режим «словаря концептуальных терминов» позволяет искать все синонимы (иногда антонимы) понятий, перечисленных в поисковой строке, так, при поиске «пфу» со включенным «концептуальным словарём» будут получены все связанные термины, например «полная функция управления» или «цели», однако если вы поищите «пфу» без словаря, результатом будет лишь единственный параграф, где понятие полной функции управления было обозначено аббревиатурой. Пример одного из сценариев работы с поисковиком. Представьте, что вам нужно найти в толстых книгах пару терминов, между которыми вы предполагаете существование какой-либо связи. Если вы воспользуетесь обычным поиском операционной системы или редактора файлов по тексту книги, вы можете найти книгу, содержащую искомые понятия, но это не означает, что в книге эти понятия будут связаны в рамках одной страницы текста или даже одной главы. Понятия просто могут присутствовать в совершенно раздельных частях текста, поскольку тексты толстых книг достаточно обширны и включают много понятий. Такие запросы практически бесполезны при использовании стандартных средств поиска по тексту книги в файле, поскольку в большинстве случаев стандартный поиск слеп к расстоянию между поисковыми словами. В нашем поисковике запрос ограничивается параграфами книг, поэтому поиск связи между понятиями намного эффективнее. Вот примеры связок, которые будет сложно найти быстро без нашего поисковика: «предиктор + пфу» «достоевский + магия» «пушкин + масоны» Вопросы, предложения, замечания и найденные ошибки приветствуются. Можно написать в комментариях на ФКТ, на гитхабе или воспользоваться страницей обратной связи. Удачного поиска, друзья! |
|
Если что-то нужно править, добавлять, удалять или уточнять, смело это делайте. |
Я уже неоднократно пользовался этим способом сегодня, что даже уже появилась мысль, сделать кнопку-ссылку типа: «посмотреть параграфы рядом 3, 5,10» С толстыми книгами можно так делать, вплоть до того, что сделать фильтр по книге и сортировку по возрастанию параграфов. но с этой частью фильтр и сортировку, я не хочу пока заниматься и не уверен, что это надо. Думаю в сторону объединения мелких параграфов, примерно по такому алгоритму (это надо сделать на уровне парсера, до попадения в БД и мантикору):
Звучит вроде просто, надо попробовать. Еще подумал, надо ли нам где либо указать список книг которые присутствуют в поиске? Вроде бы полезно, думаю. |
Да, отлично. Можно вставить ссылку в нижнее поле «комментария» где сейчас пусто, и она будет вести попросту на такую же страничку поиска, только выдача будет из списка параграфов из заданного диапазона, сортированных по возрастанию.
Кажется избыточным, думаю нет острой необходимости. Уже есть небольшая ОС в новой теме от Ф. Владимира:
Речь, по видимому, о заголовке. Кстати по его ссылке также виден крупный шрифт, тег пролез. |
Вроде логично, но скорее всего скорость обработки весьма просядет. Во время парсинга как передаётся параграф? Быть может есть какая-то метка о размере текста в байтах или её можно откуда-то получить? Ещё момент — как в этом случае будут обрабатываться заголовки? Может случится что заголовок следующей главы будет приклеен к параграфу предыдущей, и тд. |
|
Выделил в отдельный issue обработку длинных параграфов |
Обновил главную страницу |
Создал обсуждение поиск по толстым книгам ВП СССР где пользователи могут оставлять непосредственно свои вопросы и пожелания. Думаю ссылку на главной можно отправить прямо в эту дискуссию. |
результат поиска содержит только поисковый запрос, что кончено странно, но нормально, с точки зрения поискового алгоритма #5941
Обновил ещё раз текст на главной, убрал «попсу» в шапке, добавил ссылку на обсуждение , внизу, где перечисление фкт, гитхаб, обратная связь |
Это заголовок или название таблицы, возможно строка списка. |
|
Похоже Это строка списка, я ранее их по номерам смотрел специально. Несколько параграфов назад есть параграф, заканчивается двоеточием. И после идут несколько таких коротких параграфов, но они заканчиваются точкой. (с точкой с запятой было бы проще распарсить) в общем смотрел на них и понятно, что список, но как составить алгоритм, не знаю пока. Как то соотношение длин надо учитывать, видимо. |
|
Алгоритм, чтобы спарсить такие записи, как список. |
|
Ага. Странно что нет открывающего символа. А из xml список не достать? Или тут вообще оформление отсутствует, такое типографское решение автора. |
|
Да, надо источник docx посмотреть. |
В оригинале там нумерованный список. Проверял файл, который лежит непосредственно в репозитории. |
Добавил ссылки на параграфы рядом Upd: но похоже, что мне не нравится, хочется слева: назад 3,5,10, а справа, где сейчас параграфы рядом, чтобы было вперёд 3,5,10. И можно читать книгу) |
Есть много мыслей, что можно улучшить в оформлении. В целом на правильном пути. Есть подозрение. что для демонстрации книг нам просто нужно подобрать другой шаблон, не такой как у комментариев. Сейчас быстро пробежался по шаблонам бутстрапа, что-то ничего не попалось для лонг рида. В принципе не проблема прокачать и текущий шаблон, сделать его более книго-читаемым. Потестировал ещё результаты. Можно сделать одну единственную кнопку «контекст», которая будет вмещать установленное число параграфов в обе стороны, на первый взгляд достаточно по три штуки вперёд и назад. Этой кнопкой может быть прямо номер комментария. В странице выдачи контекста можно убрать заголовки, нумерацию и вообще всё остальное оформление блоков, текст разделять лишь пустой строкой, как в книге. Восприниматься будет чище и легче. Понятно, что сейчас страница с контекстом это просто поисковая выдача по списку номеров параграфов, но мы можем сделать для показа контекста отдельный шаблон, без разделения текста на блоки? Что в принципе более эффективно (или вообще возможно) — найти и установить другой шаблон для общей книжной выдачи, или доработать текущий? |
Как-то так можно оформить поисковую выдачу по книгам.Номера параграфов — ссылки на страницу контекста. Названия книг в подписи под цитатами. Картинка |
|
Подключил на локальном 7733 книг и запустил фронетнед: По союзу и выдало 9 694 216 записей
Потом зачем-то поискал крымский мост
Работаем. |
Отлично.
Я думаю в мире довольно много мостов, носящих такое название, в топонимах это распространённый подход. По выдаче если оценивать, то уже пришёл момент изучать score и другие методы оценки полезности элементов внутри мантикоры, которые формируют очерёдность показа записей. |
Это да, согласен, просто стало интересно и почитал пару страниц выдачи)
Возможно, но пока не готов) Придет время, я периодически документацию перечитываю, каждый раз что-то новое, посмотрю еще раз этот раздел про score, возможно уже будет другое понимание, ранее этот раздел просто пролетел куда-то в подсознание и пока оттуда не нашел выхода) |
Это не было заданием )) Просто размышление, самому интересно. Так то в уме уже много костылей, просто если всё есть в стандартном функционале, логично использовать его. |
Вижу функциональный фронтенд уже работает на поддомене, можно осуществлять поиск по книгам. Пока не собирал локальную базу 7733, поэтому сложно сравнить результаты выдачи с локальными, но кажется что в некоторых случаях находится больше результатов, чем в стандартных локальных запросах даже на базе с дубликатами. Видимо подключены словоформы? |
|
Да, запустил недавно, слово формы не подключены. Обычный словарь. 7733 книг. Есть производительностью, когда результатов больше нескольких тысяч, позже попробую сделать ограничение. Я его раньше специально убирал для комментариев, но там объём базы маленький и это работало хорошо. Или же надо увеличивать оперативную память на сервере. Например запрос: Сталин. |
Да. Где-то минуту шустрил по базе и выдал 223420 результатов. |
Название книгиЗаголовок главы и/или раздела(чтобы можно было ориентироваться в бумажной книге)Далее единым блоком в виде трёх параграфов:
Далее добавим ссылки, когда поймём куда они должны вести.
Предыдущее обсуждение в репозитории поисковика.
The text was updated successfully, but these errors were encountered: