0

アプリケーションのデータベースを Windows Azure SQL データベースに移行中です。アプリケーション内にはいくつかの軽量な検索機能があり、現在は T-SQL とフルテキスト インデックス作成を使用して検索を処理しています。ただし、フルテキスト インデックス作成は現在 Azure では利用できません。

すばらしい Lucene.Net などの非 SQL ソリューションを検討していますが、私たちがやろうとしていることにはやり過ぎかもしれないと思います。私たちが検索しているデータセットは巨大ではなく、平均して 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 フィールドを検索する場所。Author と Subject は複数の単語である可能性があり、ItemContent フィールドは複数の段落である可能性があるため、テーブル スキャンを回避する方法がわかりません。フルテキスト インデックスは非常にうまく機能しました。

SELECT ItemID FROM dbo.Items WHERE Author LIKE '%' + @SearchTerm + '%' OR Subject LIKE '%' + @SearchTerm + '%' OR ItemContent LIKE '%' + @SearchTerm + '%'

全文索引を使用せずにこのタイプの検索を最適化する方法について提案がある人はいますか?

4

1 に答える 1

0

別の方法は、完全なデータ ウェアハウス ソリューションではないにしても、おそらく、これらの列を 1 つのレコード (またはより少ないレコード) に変更する非正規化テーブルを作成することです。 CombinedSearchableInfo は "Herman Melville Moby Dick" である可能性があります。この場合、計算作業が少なくなります (そのような場合には、別のクエリ最適化手法を使用できます)。オフラインプロセスで検索テーブルを維持するだけで済みます...

ただし、Lucene はスペルミスや関連性などの助けになる可能性があり、書籍や著者などのドメイン空間では、スペルミスは適切であり、可能性が高いことを覚えておいてください...

(さらに、Azure ルートを使用する場合は、テーブル ストレージと BLOB ストレージを使用して多くのことを行うことができます...実際には、BLOB ストレージの一部として全文インデックス作成を使用して SQL サーバーを実行できますが、そうする必要はありません。何かを改造する... Azure SQLのパフォーマンス上の利点をすべて失うことになりますが、ちょっと...それはオプションです)

于 2012-07-18T02:21:38.397 に答える