Поиск SQL без полнотекстовой индексации

Мы находимся в процессе переноса базы данных нашего приложения в базу данных Windows Azure SQL. В приложении есть несколько облегченных функций поиска, и в настоящее время мы используем T-SQL и полнотекстовую индексацию для обработки поиска. Однако в настоящее время полнотекстовое индексирование в Azure недоступно.

Я изучаю решения, отличные от SQL, такие как Lucene.Net, которые выглядят великолепно, но я думаю, что это может быть излишним для того, что мы пытаемся сделать. Наборы данных, которые мы ищем, невелики - в среднем менее 100 000 записей - и их всего несколько. Примерная таблица может выглядеть примерно так ...

CREATE TABLE dbo.Items(
    [ItemID] [int] IDENTITY(1,1) NOT NULL,
    [Author] [varchar](255) NULL,
    [Subject] [varchar](255) NULL,
    [ItemContent] [nvarchar](max) NULL, 
CONSTRAINT [PK_Items] PRIMARY KEY CLUSTERED ([ItemID] ASC)
)

... где мы хотим искать в полях Author, Subject и ItemContent. Автор и тема могут состоять из нескольких слов, а поле ItemContent может состоять из нескольких абзацев, поэтому я не понимаю, как избежать сканирования таблицы. Полнотекстовый индекс работал очень хорошо, и я не собираюсь этого делать:

ВЫБРАТЬ ИДЕНТИФИКАЦИЮ ИЗ dbo.Items, ГДЕ Автор КАК '%' + @SearchTerm + '%' ИЛИ ​​Тема КАК '%' + @SearchTerm + '%' ИЛИ ​​ItemContent КАК '%' + @SearchTerm + '%'

У кого-нибудь есть предложения по оптимизации этого типа поиска без использования полнотекстового индекса?


full-text-search azure-sql-database tsql
person Brian Campbell    schedule 18.07.2012    source источник
comment
какой поиск вы хотите выполнить ... Если вы хотите найти что-то вроде herman melville moby dick, lucene поймает это, но ваш поисковый запрос не будет ... вы уверены, что не хотите люценовый раствор?   -  person Rikon    schedule 18.07.2012
comment
Мне действительно нравится Lucene, поскольку это действительно поисковое решение, и оно определенно находится в стадии разработки. Тем не менее, до сих пор наши запросы полнотекстового индекса хорошо работали для этой конкретной задачи - запросы, как правило, представляют собой быстрые запросы с фильтром, а не более сложные строки поиска. Так что, если бы я мог добиться хорошей производительности от решения T-SQL, я бы склонился в этом направлении.   -  person Brian Campbell    schedule 18.07.2012

Ответы (1)


arrow_upward
0
arrow_downward

Альтернативой является создание, если не полного решения для хранилища данных, возможно, некоторых денормализованных таблиц, которые преобразовывают эти столбцы в одну запись (или меньшее количество записей) ... Таким образом, у вас будет таблица db с просто ItemId | CombinedSearchableInfo, где вы CombinedSearchableInfo может быть «Herman Melville Moby Dick», и в этом случае вы выполняете меньше вычислительной работы (и вы можете использовать другие методы оптимизации запросов для чего-то подобного). Вам просто нужно будет поддерживать свою таблицу поиска в автономном режиме ...

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

(Кроме того, если вы идете по лазурному маршруту, теперь вы можете многое сделать с хранилищем таблиц и хранилищем BLOB-объектов ... Фактически вы можете запустить свой sql-сервер с полнотекстовой индексацией как часть вашего хранилища BLOB-объектов, и вам не придется модифицировать что угодно ... Вы потеряете все преимущества производительности лазурного sql, но эй ... это вариант)

person Rikon    schedule 18.07.2012
comment
Спасибо за предложение. Я ищу похожую альтернативу. Что вы думаете об индексированном представлении вместо таблицы, где CombinedSearchableInfo - это объединенный контент из столбцов, которые я хочу найти? Насколько я понимаю, если я проиндексирую представление и запрошу его с помощью (NOEXPAND), оно по сути будет работать как таблица. Конечно, это все равно будет сканирование - я надеюсь, что если сканирование будет смотреть только на один столбец, оно будет работать лучше. - person Brian Campbell; 18.07.2012