У нас есть база данных SQL Server с миллионными записями, которые проиндексированы от Lucene.net
до Nhibernate.Search
.Когда мы строили индекс для наших классов, мы старались быть обширными, поскольку стоимость индексации / поиска была действительно небольшой.Цель состояла в том, чтобы предложить пользователям полнотекстовый поиск на веб-странице с нумерацией страниц.
Поскольку SQL Server жалуется, когда ему отправляется слишком много параметров (2100 параметров по умолчанию) и поскольку мы не хотели изменятьэтот параметр каждый раз, когда мы достигаем предела (что может случиться легко, некоторые термины в нашем документе очень распространены, но должны быть доступны для поиска) мы решили обрабатывать все, от сортировки до подкачки страниц в Lucene .Это сработало как шарм.
Однако в последнее время функция "ползучести" вызывает у нас некоторую проблему, поскольку новые запросы должны получать доступ не только к полям, которые не проиндексированы, но и к полям, к которым нельзя обращаться или которые могут 't быть доступным: вычисляемые поля, списки рекомендаций и т. д. ...
Поскольку мы поместили все наши подкачки и сортировку в Lucene.Net и поскольку SQL Server требователен к своим параметрам, какможем ли мы получить свой торт и съесть его тоже?
Сначала я собираюсь выполнить вычисление SQL-запроса, сводя элементы к их идентификатору документа, а затем передавая Lucene гигантский запрос OR со всеми возможными идентификаторами, чтобыпусть он правильно выберет то, что возможно, но я беспокоюсь о размере запроса
псевдокод
listIds = Nhibernate.Criteria.ReduceToIds.List(of MyObject)
queryIds = String.join(" ID:", l)
return NHibernate.Search(queryIds)
Очевидно, что фильтры Lucene могут работать, позволяя толькоопределенные документы ID должны быть частью запроса, поэтому это должно быть возможно, но я действительно не вижу способа сделать это в Nhibernate.search
У вас естьЕсть идеи, как мне решить проблему?Можно ли отфильтровать запрос, задав SQL список идентификаторов?Это излишне?Есть ли другое решение?