web-dev-qa-db-ja.com

プロパティの非常に長いリストをすばやくクエリする方法

SQLServerにアイテムのプロパティを格納するための構造があります。

ItemId PropertyId Value
1      1          a
1      2          b
2      1          a
2      2          5

現在、130000以上のアイテムと10000のプロパティがあり、その数は増え続けています。現在の行数は1500万を少し超えています。このデータのピボットテーブルを作成した場合、13億を少し超えるセルがあり、そのうち1,500万のセルはnullではありません。

ユーザーは、次のようにこのデータにカスタム式を作成できます。

X: P1 = 'a' (rule X selects items which have property 1 with value 'a')
Y: P2 <> 'b'
Z: P3 like '%c%'
T: P4 > 5 (rule T selects items which have property 4 with a value greater than 5)

そして、次のような式を使用してフィルターを形成します。

(X AND T) (items that match both X and Y)
(X AND Y) OR (Z AND T)
(X OR Y) AND (Z OR NOT T)
(X OR Y AND T) OR Z

単一のWeb要求の応答として、いくつかのフィルター（通常は4または5）の結果を照会する必要があります。どうすればこれを速く行うことができますか？このフィルター結果を取得するための保存方法または超効率的なアルゴリズムはありますか？

これがSQLServerで可能であれば素晴らしいのですが、データのこの部分をSQLなしのデータベースに保存するようなソリューションも受け入れています。

algorithmsperformancesql-serverdatabase-design
4
serhatozgel

エンジンがインデックスを選択し、テーブル全体のスキャンを回避するために、SQLサーバーとの反復セッションに基づいて、テーブル上に慎重に作成されたインデックスが必要になります。

A、b、c、dはユーザー提供の値だと思います。もしそうなら、X、Y、Tはインデックスを簡単に作成できると思いますが、一般的なテキスト検索は非常にスペースを必要とし、全文検索が必要になるリスクがあるため、Zの「like」句はキラーになります。 SQL Serverが全文検索を行わずに、全文検索を直接サポートしているかどうかはわかりません。

つまり、SQL Serverプランナーがどのように機能するかを学習して、SQLを評価し、全表スキャンを回避するためにインデックスを作成する方法を決定する必要があります。

3
user1249

あなたが言ったことから、私は、迅速なフルロードとメモリ内検索がおそらく最初に最良のオプションだと思います。 15mlnのアイテムはそれほど長くはかからないはずです。その場合、データを十分に迅速にロードすることがボトルネックになる可能性があります。 SQLサーバーが十分に高速であるかどうか、データをメモリ内に保持できるかどうか、またはNoSQLソリューションを使用できるかどうかを確認します。

使用するフィルターの種類について詳しく知っている場合は、そこから最適化できます。したがって、クエリをログに記録します。

0
Jaap

インデックス作成を計画する前に、データ変更の要件を考慮してください。そして、インデックス作成が必要になります。

十分な数がある場合は、すべてをニースのメモリに保存します（十分な数があります）。

SQL Serverのバージョンによっては（Enterpriseは実稼働環境でほとんどの機能を提供します）、テーブルとインデックスのパーティション分割を利用できる場合があります。

インデックス付きのビューを作成することはできますが、データ変更トランザクションが多いと、これが理想的ではない場合があります（そうでない場合は、すべてにインデックスを付けます）。

他の関連データテーブルがない1つのテーブルのみを扱っていますか？

0
JeffO