Я бы посоветовал решение 1, поскольку чем меньше будете изобретать велосипед
или пилить функционал, который можно взять изкаропки, тем лучше. Либо одолжите у
ребят из соседней команды.
S>Если всё-таки нужен свой велосипед, то меня смущает вот этот момент: S>
S>Поиск начального набора данных они ведут через ПП в БД
S>Т.е. сначала идёт полнотекстовый поиск в СУБД, а затем найденные документы выгребаются с СУБД и фильтруются ещё раз, но уже своей реализацией полнотекстового поиска, так?
S>В чём смысл такой магии?
Нет-нет, не совсем так.
Задача такова — пользователь выбрал некий набор данных по некоторым критериям. А дальше, ему должны (или не должны) приходить новые данные, попадающие под критерии отбора.
Причем пользователь может отслеживать несколько наборов данных, пользователей может быть несколько и т.д. Новые данные могут попадать под критерии разный пользователей и т.д.
Потому решили прогонять новые данные через цепочки фильтров "на лету".
Коллеги, есть задачка, подскажите пожалуйста, может кто уже делал такое.
1. Есть БД (MS SQLServer 2012) в которую кладутся текстовые данные. Объемы текстов небольшие, данных не очень много, порядка 400.000 документов в год.
2. Надо сделать поиск документов в БД. Один из критериев поиска — полнотекстовый поиск (ПП) по тексту. При этом, другие условия (ограничения по датам и т.д.) есть всегда.
Здесь все стандартно.
3. Новые данные надо также проверять на соответствие критериям ПП из п. 2 и если они соответствуют, то обрабатывать дополнительно (не важно как).
Вот в п. 3 и загвоздка.
Не хотелось бы загонять новые документы в БД с автоматическим дополнением индекса, а потом по ним искать, чтобы проверить соответствует документ критериям ПП или нет.
Решений вижу 3.
Решение 1 — в лоб
Загонять документы в БД с полнотекстовым индексом. Для П.2 делать обычный поиск. Для п. 3 делать поиск по ID (он известен) и ПП.
Решение 2
Не использовать полнотекстовый поиск на уровне БД. Сделать свой легковесный движок ПП, без индексов, опираясь на сторонние словари морфологии.
Запрос ПП будет разбираться и будут генерироваться все возможные варианты поисковых строк, которые потом будут искаться в документе до первого вхождения.
Для п. 2 ПП происходит простым перебором — данные отбираются по другим критериям, потом делаем ПП.
Для п. 3. данной ситуации все ясно — проверяем на критерии ПП.
Решение 3
Гибрид 1 и 2. Для п. 2 использовать нормальный ПП на БД. Для п. 3 свой движок.
Должен заметить, что Решение 2 вроде как рабочее — в соседнем проекте ребята сделали именно так, и это работает.
Здравствуйте, Syleiman, Вы писали:
S>Решение 1 — в лоб
Для MS SQL — однозначно 1. Делали нечто похожее ещё на ms sql 2008, работало без сбоев и особых проблем. Единственно, надо будет распространять вместе с софтом набор ifilters (парсеры для разных форматов документов — word, pdf, .zip etc). Как правило достаточно стандартного Office Filter Pack.
С поиском будет пара нюансов. Во-первых, заполнение результатов поиска надо делать асинхронно, по мере ввода пользователя — отменять предыдущий запрос.
Мы делали своё решение очень давно. Сейчас я бы смотрел в сторону Rx (если речь идёт про c# конечно). Вот тут есть пример с "горячим" поиском по twitter.
Во-вторых, очень желательно сделать интерфейс похожим на поисковики: основное поле ввода — текстовое, всякие условия по дате и т.п. — дополнительные контролы, помогающие ограничить поиск. От этого зависит, насколько часто поиск будет использоваться вообще. Как показывает практика, режим "заполни все поля — нажми "Поиск" — жди результата" сильно раздражает пользователя.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Syleiman, Вы писали:
S>>Решение 1 — в лоб S>Для MS SQL — однозначно 1. Делали нечто похожее ещё на ms sql 2008, работало без сбоев и особых проблем. Единственно, надо будет распространять вместе с софтом набор ifilters (парсеры для разных форматов документов — word, pdf, .zip etc). Как правило достаточно стандартного Office Filter Pack.
Я больше к третьему варианту склоняюсь, говоря честное.
Побеседовал с ребятами из соседнего проекта у них как раз гибридное решение. Поиск начального набора данных они ведут через ПП в БД, а дальнейшую фильтрацию через свой легковесный движок, это позволяет лишний раз не нагружать БД такой тяжеловесной операцией как ПП.
При этом есть одна хитрость. Морфологию они реализовали у себя, и не используют морфологические модули СУБД. Сделано это через сторонние библиотеки. Т.о. они парсят через регулярки запрос пользователя, через библиотеки морфологии получают все словоформы и потом этот набор либо скармливают своему движку, либо БД. Это позволяет получить идентичные результаты.
Здравствуйте, Syleiman, Вы писали:
S>Я больше к третьему варианту склоняюсь, говоря честное. S>Побеседовал с ребятами из соседнего проекта у них как раз гибридное решение. Поиск начального набора данных они ведут через ПП в БД, а дальнейшую фильтрацию через свой легковесный движок, это позволяет лишний раз не нагружать БД такой тяжеловесной операцией как ПП.
Так у вас уже есть рабочее решение (в соседнем проекте). Если так — не проще использовать его, чем наступать на грабли самому?
Если всё-таки нужен свой велосипед, то меня смущает вот этот момент:
Поиск начального набора данных они ведут через ПП в БД
Т.е. сначала идёт полнотекстовый поиск в СУБД, а затем найденные документы выгребаются с СУБД и фильтруются ещё раз, но уже своей реализацией полнотекстового поиска, так?
P.S. S> 3. Новые данные надо также проверять на соответствие критериям ПП из п. 2 и если они соответствуют, то обрабатывать дополнительно (не важно как). S>Не хотелось бы загонять новые документы в БД с автоматическим дополнением индекса, а потом по ним искать, чтобы проверить соответствует документ критериям ПП или нет.
Если требуется строгое соответствие результатов полнотекстового поиска в локальном варианте и в СУБД, то в общем случае эта задача не решается.
У пользователей могут стоять разный набор фильтров/стеммеров (склонятелей), сам FREETEXTABLE нечёткий и в теории может выдавать разные результаты в зависимости от набора документов в индексе.
Если требуется просто проверка на вхождение определённых подстрок, то достаточно будет вытащить локально все строки с помощью ifilter и прогнать проверку по ним.
Единственно, учитывайте что к документам обожают закидывать огромные pdf с сотнями страниц распознанного текста под графическим слоем (когда нужен и полнотекстовый поиск, и сохранить вид отсканированного документа). Они легко могут весить до сотни МБ. В общем, обрабатывать такие вещи надо аккуратно
И да — вам действительно нужна проверка полнотекстовым поиском перед добавлением в базу? На мой взгляд, если нет чёткого бизнес-требования, с такими вещами лучше не заигрывать. Уж очень легко под маленький тикет переизобрести весь движок с морфологическим склонением и прочими прелестями
Здравствуйте, Syleiman, Вы писали:
S>Новые данные могут попадать под критерии разный пользователей и т.д. S>Потому решили прогонять новые данные через цепочки фильтров "на лету".
Да, тогда это не совсем для СУБД задача.
P>Не изобретай велосипеда, поставь sphinx рядом с БД. В нем из коробки есть все что тебе нужно
Не уверен, что sphinx поможет быстро проверить одиночный текст (в виде строки) на соответствие критериям полнотекстового поиска, но может я и не прав.
Велосипед не кажется таким уж сложным.
Для работы с морфологией я использую Lucene.
Язык запросов я придумал, он простой, покрывает потребности пользователей (по крайней мере так сказал аналитик), легко разбирается. Лексер я для него уже написал.
