Мова чи технологія для серверу обробки документів

Доброго настрою всім учасникам!
Відразу омовлюся що я не хочу робити «holly war» на тему яка мова/технологія краща, я в курсі що для кожної задачі є свій інструмент.
Свої інструменти (Ruby, RoR) я успішно використовував для всіх поставлених перед мною задач (в основному сайти журналів, всякі бази для невеликих компаній), але виникла задача яка явно Ruby не під силу.
Грубо кажучи, це розробка системи пошуку в документах, тільки не по запиту а по фрагментах. Наприклад є абзац, написаний по-пам’яті (десь бачив), а мені треба знайти з якого це документу (база містить 2 тис документів, кожен від 20 до 300 сторінок А4, інтенсивно додаються нові документи).
Я використовував методи, які використовуються для пошуку плагіату і все це діло написане на Ruby вже працює... поки не доводиться шукати у всій базі.
Вирішив переписати пошук іншою мовою, розділити інтерфейс (сайт) і власне сервіс пошуку. От тільки не знаю яку технологію вибрати. Серед інших знайомих мов тільки C#, не підходить бо сервер на лінукс (я в курсі про моно, все-одно не те).
Щодо мови/технології, хотілося б що б вона мала зрозумілий синтаксис і працювала швидше ніж рубі.
Наперед дякую всім хто відгукнеться.

P.S. Оскільки більшість коментаторів рекомендують використовувати full-text-search системи, то можливо хтось знає, яка з систем (lucene, іsphinx, elasticsearch, etc) може дати максимальну «нечіткість» пошуку? Наприклад я шукаю речення з 10 слів, це речення в індексі є, але насправді слів 9, причому 1 слово не входить в мій запит і порядок слів відрізняється?

Теми: C#, Go, Java, Ruby, Scala

Ctrl + Enter

anonymous 19.06.2015 09:56

Дам два совета.

1) Не переписывате все, вам разве не жалко тех денег и времени которые были инвестированы в этот код? Вы вполне можете продолжать использовать руби.
2) Используйте PostgreSQL, там есть полнотестовый поиск и нечеткое сравнение строк.

www.postgresql.org/...static/fuzzystrmatch.html
www.postgresql.org/....4/static/textsearch.html

Відповісти

Підтримати

Volodymyr Spodaryk Software Engineer 18.06.2015 12:51

MongoDB + <anylanguagehere>
Перша має вбудований full text search
А щодо мови я б пропонував Python

Alex Lynn 18.06.2015 18:19

full text search

имеют много баз данных. В чём преимущество монги?

Volodymyr Spodaryk

reality_hacker 19.06.2015 08:52

web scale

Alex Lynn

anonymous 19.06.2015 09:52

А зачем вебскейл на 100-200 пользователей и 2000 документов?

reality_hacker

reality_hacker 19.06.2015 12:12

Такой взрослый мальчик а такого бояна не знаешь: www.youtube.com/watch?v=b2F-DItXtZs

anonymous

anonymous 19.06.2015 12:22

Я не смотрю смешные видео на работе.

Алексанр Слободянюк 17.06.2015 13:10

en.wikipedia.org/wiki/Full_text_search
по ссылке есть раздел со списком софта, в том числе и с открытым кодом...

Наприклад є абзац, написаний по-пам’яті

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

возможно, лучше сделать некий интерфейс который поможет пользователю составлять правильный запрос поиска используя подсказки из индексов... например, en.wikipedia.org/wiki/Faceted_search , но из описания задачи непонятно можно ли создать структуры для индексов...

Alex Lynn 18.06.2015 18:18

Текущая реализация очень «нечеткая», поэтому в результатах много ошибок, но не настолько чтобы не найти искомое. При более-менее правильном запросе документ вполне находится. Если Вас есть опыт работы с FTS системами, в какой можно получить хороший нечеткий поиск?

Алексанр Слободянюк

Алексанр Слободянюк 18.06.2015 19:07

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

ориентировочно суть в том что большенство решений построены на индексации, ключевых фразах и совпадениях, а следовательно подойдет любое решение тк если в запросе будет хотяб несколько совпадений искомый документ теоретически найдется)

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

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

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

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

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

в общем ничего полезного) удачи

Нестор Иванович 17.06.2015 11:31

lucene.apache.org/core и ничего не нужно выдумывать

DNA Exp 17.06.2015 00:33

хе хе
2 тыс * 300 = 600 тыс всеголишь.
У меня в базе несколько миллионов доков.
Поиск по абзацу (словарю) несколько миллисекунд.
Но конечно не Линукс. Как решите, отпишитесь о результатах :)

Alex Lynn 17.06.2015 00:35

А что тогда, Windows + C# + MS SQL? Мне рекомендовали именно эту связку, но я пошёл по другом пути. У нас несколько разные документы, для Вас это веб страница, для меня это doc файл на 150-200 страниц.

DNA Exp

DNA Exp 17.06.2015 00:39

По какому пути ? Если скорость то конечно noSQL, конечно голый Си, конечно InMemory.
Про MS SQL не может быть и речи.

Alex Lynn 18.06.2015 18:21

Изначально ориентир был на результат, скорость потом) Именно поэтому написано на Ruby. Так хоть на какой ОС работает Ваше решение?

DNA Exp 19.06.2015 12:22

ОС вторична, но win

DNA Exp 17.06.2015 00:45

Короче говоря у вас задача очень на мою похожа. Правда я свое решение тюнил на обьемы значительно больше чем у вас указаны. Даже есть тотже поиск по словарям похожих документов. Единственое у меня движок для приватного использования и экспериментов, не для продажи лицензий и тп. Реализация этого же стандартными средствами (Solr, Lucene, Elastic ...) на больших обьемах данных может вылится в немалое количество нервных клеток. Это правда.

Alex Lynn 18.06.2015 18:24

Проблема для меня стандартных систем в невозможности обеспечения того уровня нечёткости поиска который мне нужен. Ну и да, ещё неизвесно как система будет вести себя в будущем, если документов станет несколько миллионов. Хотя своя реализация тоже не лишена этих вопросов.
В чём соль «тюнинга» не поделитесь? Или это у самого себя под NDA?

DNA Exp 19.06.2015 12:21

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

Олексій Агеев Programmer 16.06.2015 15:51

Разбирайтесь с FullTextSearch для своей СУБД. Зачем эти крутые велосипеды, время только убьете.

На хабре есть инфа по MySQL.
habrahabr.ru/post/40218
Вот доки по постгресу
www.postgresql.org/....3/static/textsearch.html
В MSSQL тоже должно быть.
А так как вся эта кухня пришла кажется с Ораклоидов — то там есть в любом случае.

Из своего опыта:
Пробовал на PostreSQL, правда для небольших текстов (2-8 слов). У меня был вопрос скорее не в поиске в большом тексте, а в вариативности однокоренных слов, учет ошибки раскладки, учет пропущенных букв и синонимы

Но как работает для больших текстов не пробовал. Пишут — работает (поиск по «похожести» делает достаточно быстро).

Основная идея
— в базе создается таблица — справочник уникальных слов по всем документам. Каждому слову в соответствие ставить число (код) — для однокоренных слов — число одинаковое. Тоесть можно несколько груп с одинаковым смыслом обозначить одним числом. Движок FTS использует эту таблицу для формирования вектора.
— В таблицу с документами добавляется поле типа вектор пар.(тип предоставляет движок FTS). В нем после анализа документа записывается вектор с парами «код — число». Код — это код из таблицы-справочника группы слов. Число — что-то типа вероятности или частоты упоминания слова в документе. По такому полю есть возможность строить индекс и делать что-то типа like запроса. Или точнее движок FullTextSearch предоставляет функцию высчитывающую разность между поисковой строкой и вот этим хитрым полем. Результат функции — число, по которому можно фильтрануться и отсортироваться.

Вот тут лучше читануть примеры
www.postgresql.org/...#TEXTSEARCH-TABLES-SEARCH
и искать под свою СУБД

Да, и поиск слова в справочнике может выполняется не по точному совпадению

Alex Lynn 17.06.2015 00:34

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

Олексій Агеев

oleksandr dubyna CEO в RemSoft.Dev, ClawsKeyboard.com 16.06.2015 13:04

на сколько помню последняя версия шарпа должна работать и без моно на линухах

Антон Касьянов Cat herder 16.06.2015 13:55

ASP.NET 5 еще не зарелизился.
А с простым Моно надо поаккуратнее. Вполне можно можно получить проблемы с фрагментацией Large Objects Heap и сборщиком мусора, ведущие к OOE. Причем на настоящем .NET всё будет работать отлично.

oleksandr dubyna

oleksandr dubyna CEO в RemSoft.Dev, ClawsKeyboard.com 16.06.2015 15:45

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

Антон Касьянов

Антон Касьянов Cat herder 16.06.2015 18:04

Т.е. Вы предлагаете сказать клиенту — «Чувак, тут технология крутая и такая новая, что еще даже не зарелизилась. А давай ты проспонсируешь разработку под нее, включая (пере)обучение девелоперов, поиск багов в ядре и грандиозный факап в конце когда выяснится что одна из core фич продукта нереализуема на этой самой технологии.» Нее, спасибо. Такой подход хорош для пет-проектов и стартапов класса «тяп-ляп и в продакшен». А в смурном мире девелопмента ради зарабатывания денег^W^W удовлетворения нужд бизнес-пользователей такое могут и не оценить по достоинству.

Victor Krasnoshchok Embedded Software Engineer в Ring Ukraine 17.06.2015 14:26

На самом деле, многое из того, что реализовывается для большого энтерпрайза, поддерживается оочень долго (так как потенциальным кастомерам переезд может быть очень долгим, дорогим или же просто нежелаетльным в силу «устоявшихся традиций» или повышенных требований к новым продуктам — смотрим в сторону банковского софта и клиент-банков, которые до сих пор работают только через модемный пул :-D ) и новые продукты в линейке очень часто имеют либо совместимость со старыми продуктами линейки (например, та же жаба) либо ее «эмуляцию». Так что, я полностью согласен с предыдущим оратором — если дороги свои нервы и репутация перед заказчиком, то на продакшне стоит юзать проверенные временем решения, при чем — в стабильных версиях (но, без излишнего фанатизма). По этой же причине, например, на всяких серверах юзают хоть и относительно старые, но наиболее стабильные релизы ОСей (да, я про Дебиан или CentOS), в которых может и не быть самых модных и новых фич. А кому хочется экспериментов — те юзают nightly builds. Так что такой подход, с cutting edge, действительно больше на хобби похож, чем на продакшн.

Alex Lynn 16.06.2015 21:55

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

Eugene Varava PHP/Python Developer 16.06.2015 12:53

Apache Solr? Под руби есть библиотеки, конечно же.

Alex Lynn 17.06.2015 00:32

Да, хорошая и простая в настройке штука, под руби запускается с полпинка. Но не решает часть задачи. Я не упомянул, но мне нужно также находить и место в документе, а apache возвращает только список документов.

Eugene Varava

Олексій Пєніє 15.06.2015 22:08

Вопрос лишь что ты собираешься искать. Если это слова — просто индексируй документы по словам в базе — и будет тебе счастье. Главная задача любого поиска — собрать правильный индекс.

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

Если поиск полнотекстовый, но документ легко бьётся на лексемы — делай индекс, сначала ищи по индексу вхождение всех лексем, а потом уже среди выбранных документов (как правило это 0 или 1шт) делай полнотекстовый поиск.

Если ты знаешь язык документа — не стесняйся для индекса переводить слова в их основную падежную форму по словарю. И то же самое со строкой поиска. Цель — снизить размер индекса. Ибо скорее всего он у тебя должен помещаться в оперативу. На самом деле словарь — вещь небольшая.

Как вариант, можешь индексировать только словарные лексемы. Так даже проще. Но тогда ты теряешь возможность искать по неологизмам и жаргонным словечкам, которые редко попадают в словари. Например, базовый словарь это примерно 5-10 тыс.слов, а с жаргонами выйдут все 300 000. Разница по времени поиска существенна.

Igor Frankon 15.06.2015 18:40

Есть подозрение, что данная задача таки под силу Ruby. Я, правда, немного не понял одного: на сколько абзац, с помощью которого мы ищем, близок к оригиналу? И почему у Вас это не работает, если искать по всей базе?

Alex Lynn 15.06.2015 20:41

Абзац може бути різної близькості, може взагалі не бути подібних в базі. Все працює, просто довго. Взагалі, алгоритми пошуку можуть бути реалізовані будь-якою мовою, просто на рубі мені зручніше.

Igor Frankon

Андрей Блажей IT DREAMER 15.06.2015 21:20

пользовался как-то таким гемом для сравнения текста
rubygems.org/...evenshtein/versions/0.2.2

Alex Lynn 15.06.2015 21:56

Так, алгоритм левенштейна добре підходить для слів або коротких текстових рядків, за умови що вони більш-менш однакової довжини. В мене вже є своя реалізація, я хочу її переписати іншою мовою.

Андрей Блажей

Дмитро Дем'яненко BA/UX 16.06.2015 13:45

Все працює, просто довго.

Анализ производительности, поиск узких мест дадут понимание того, что тебе собственно нужно. И собственно, богатство выбора — www.techempower.com/...9&hw=i7&test=json производительность фреймверков.

Мова чи технологія для серверу обробки документів

Схожі топіки

35 коментарів

Підписатись на коментарі

Новини