Альтернативы MS SQL 2005 FullText Catalog

Question

Я не могу получить приемлемую производительность из FullText Catalogs. У нас есть ситуации, когда мы должны запускать запросы 100k + как можно быстрее. Некоторые из запросов используют FREETEXT, некоторые - нет. Вот пример запроса

IF EXISTS (выберите 1 из user_data D, где d.userid=@userid и FREETEXT (*, @activities) SET @ матч = 1

Это может занять от 3-15 секунд Мне нужно, чтобы это было намного быстрее < 1s, если это возможно.

Мне нравится «гибкость» полнотекстового запроса, поскольку он может выполнять поиск по нескольким столбцам, а синтаксис довольно интуитивно понятен. потому что мы хотим иметь возможность сопоставлять слова типа «Writer» и «Writing».

Я пробовал некоторые из предложений liste d здесь http://msdn.microsoft.com/en-us/library/ms142560(SQL.90).aspx

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

Я в тупике и готов изучить другие альтернативы полнотекстовым запросам. Есть ли что-нибудь еще, что дает подобные «Writer»/«Writing» аналогичные матчи? Возможно, даже что-то, что использует CLR?

Answer 1

Проверить эти альтернативы, хотя я сомневаюсь, что они улучшают производительность без изоляции их на отдельном оборудовании:

Which search technology to use with ASP.NET?

Lucene.Net and SQL Server

Answer 2

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

Также обязательно избегайте инструкций IF в SQL, поскольку они часто приводят к полной перекомпиляции плана выполнения для каждого выполнения запроса, что, вероятно, будет способствовать низкой производительности, которую вы видите. Я не уверен, как используется оператор IF, поскольку он, скорее всего, находится внутри большего фрагмента SQL. Попробуйте объединить запрос EXISTS с этим большим фрагментом sql, поскольку вы можете установить параметр @match из инструкции SELECT внутри EXISTS или полностью избавиться от переменной и использовать предложение EXISTS в качестве предиката в более крупном запросе.

SQL - это язык, ориентированный на набор и интерпретируемый. Поэтому часто быстрее избавляться от императивных программных конструкций и вместо этого использовать собственные сетевые операторы sql.

Answer 3

возможно https://github.com/MahyTim/LuceneNetSqlDirectory может помочь вам, это позволяет хранить LuceneNET индекс в SQLServer.