問題タブ [columnstore]

大きなテーブルの巨大なデータベースがありますが、複数のテーブルからのデータ取得 (クエリは約 10 個の内部結合で構成されています) では、データベースからデータを取得するのに時間がかかりすぎます (場合によっては 10 ～ 20 秒または数分)。クエリには、ほとんどのテーブルのほぼすべての列と、残りのほぼ半分の列が必要です。

私の質問は、私の場合、SQL Server 2012 列ストア アーキテクチャを使用することがどれほど役立つかということです。現在、私はSQL Server 2008を使用しています。このタイプのクエリを最適化する必要があるため、時間の最適化に関する他の提案は大歓迎です

このクエリは、Intel (i5 3.00GHz) 8GB RAM で約 50 秒かかり、結果は 5676 行になります。

Sequence 176232 行 38 列、Sequence$Document 132776 行 8 列、ClassMapping 6 行 10 列、ObjectClass 6 行 11 列、Sequence_Flow 4847730 行 22 列、OrgPeople 4656 行 11 列、TemplateProposals 90889 行 64 列、Sequence_Flow_Target 521621 行 9 列、人 4655 行 67 列。

すべての属性のデータ型は (数値、文字列、日付) にあります

これら 2 つの概念は、MonetDB に関連するさまざまなホワイト ペーパーで偶然見つけました。範囲クエリの選択を高速化するという、同様の目標を目指して達成しているようです。これら 2 つの概念は、MonetDB に同時に実装されていますか?

OS X の PostgreSQL 9.3.5 に cstore_fdw 拡張機能をインストールしましたが、プロセスにエラーはなかったように見えます (/usr/local/pgsql/bin/はパスが正しくありませんが、 でシンボリック リンクされているため、ファイルは本来あるべき場所にコピーされpg_configました$PATH)。

ただし、Postgres を起動しようとすると、拡張機能をロードできません。

何が間違っているのか誰にもわかりませんか？

私は 1 つのプロジェクトに Cassandra を使用することに決めました。多くのドキュメントを調べた後でも、連想データをモデル化する適切な方法が思い浮かびません。

システムは、データを型およびそれらの型のインスタンスとして格納することになっています。同時に、インスタンスを関連付ける方法を定義するカスタム関連付けを通じて、型を関連付けることができます。

より具体的な例として、次のデータを検討してください。

• 関連: a1、a2、a3
• タイプ: t1、t2、t3
• インスタンス: t1-i1、t1-i2、t2-i3、t3-i4、t3-i5、t3-i6

次に、ユーザーはタイプを関連付ける方法を定義できます。

• t1 - a1 - t2
• t2 - a2 - t3
• t3 - a3 - t3

上記は、インスタンスがどのように関連付けられるかを後で定義します。

• t1-i1 - t2-i3 ( t1 - a1 - t2に基づく)
• t2-i3 - t3-i5 ( t2 - a2 - t3に基づく)
• t3-i5 - t3-i6 ( t3 - a3 - t3に基づく)
• t3-i6 - t3-i6 ( t3 - a3 - t3に基づく)

上記に関するいくつかの注意事項：

1. 2 つの型の間には n 個の関連があり得る
2. 同じタイプ/インスタンス間に関連性がある場合があります(上記の例) 。
3. タイプ間の関連付けは、インスタンスの関連付け 方法を定義します

クエリは次のようになります。

1. システムは、個々の関連付け、タイプ、およびタイプのインスタンスを CRUD できる必要があります。
2. タイプの関係。(例: GET /t-assoc/t1-> [ t1 - a1 - t2 ])
3. 関連付けのタイプの関係。(例: GET /t-assoc/t2/a1-> [ t1 - a1 - t2 ])
4. 上記と同じですが、完全な関係があります
5. たとえば関係 (例: GET /i-assoc/t1/t1-i1-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >])
6. 関連のインスタンスの関係 (例: GET /i-assoc/t1/t1-i1/a1-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >])
7. 型への関連付けのインスタンスの関係 (例: GET /i-assoc/t1/t1-i1/a1/t3-> [])
8. 上記と同じ、完全な関係を持つ
9. 3.と同様に、リレーションを返す代わりに、実際の関連する型を返す必要があります (例: GET /types/t1/a1-> [ t2 ])。
10. 7.と同様に、インスタンスを返します (例: GET /instance/t1/t1-i1/a1/t2-> [< t2 , t2-i3 ]>)

上記の構造を実装するためにいくつかの反復がありましたが、上記のすべての操作を単一のクエリで実行できる構造で表現することに失敗しました。CQL バージョンは次のとおりです。

リバース フィールドは、両方向から関係を発見できるハックでした。これは、 t1 - a1 - t2を次のように挿入することを意味します。

1. t1-a1-t2-真
2. t2-a1-t1-false

この実装は、9 番と 10 番のクエリを優先しません。9 の場合、2 番目のクエリがクエリである 2 つのクエリを実行する必要がありINます。これらは最も一般的なクエリになるため、これは最適ではありません。

1 つのクエリで上記を実行できる別の設計に関する提案はありますか?

編集:グラフ構造として、これはグラフ データベースに適しています。ただし、Cassandraでこの問題を解決しようとしています。

SQL Server 2014 データベース システムで TPC-H (SF 10) を使用しています。クエリのパフォーマンスを向上させるために、2 つの最大のテーブル (Lineitem と Orders) を日付列で分割 (同じディスク) することにしました。これは、これらのクエリの多くが日付範囲を使用するためです。最初は週単位のパーティション方式を使用することにし、その後月単位の方式を使用しました。各テーブルで、クラスター化された列ストア インデックスを使用しました。最初の TPC-H クエリを実行しました。

上記のクエリに対して次の結果が得られました。

• 毎週のパーティショニング
• アクセスされたパーティション 348 (1..348) (合計 361 パーティション)
• (最後のパーティションにあるため、862194 行は読み取られませんでした)
• 論理読み取り: 1381
• ロブ論理読み取り: 109005
• ロブ物理読み取り: 1371
• ロブ先読み: 200554
• 実行時間: 2807 ミリ秒
• コンパイルCPU: 43
• コンパイル時間: 43

• コンパイルメモリ: 1408

• 毎月のパーティショニング

• アクセスされたパーティション 80 (1..80) (合計 8​​4 パーティション)
• (最後のパーティションにあるため、881.087 行は読み取られませんでした)
• 論理読み取り: 2902
• ロブ論理読み取り: 617554
• ロブ物理読み取り: 388
• ロブ先読み: 260486
• 実行時間: 2680 ミリ秒
• コンパイルCPU: 12
• コンパイル時間: 12
• コンパイルメモリ: 872

それらの最大の違いは、使用されたバッチの数です。毎週のパーティショニングでは約 333.201 のバッチがインデックス スキャンの実行に使用され、毎月のパーティショニングではわずか 191.275 のバッチが使用されました。

私はこの結果について少し混乱しています。最初の実行 (毎週のパーティション) は、読み取り操作が少ない 2 番目の実行よりも高速になると予想していました。月ごとに分割されたテーブルの LOB 論理読み取りは大幅に増加しますが、実行時間、コンパイル CPU、時間、およびメモリは減少します。したがって、月ごとのパーティショニングの方が効率的だと思います。他のクエリの結果はほとんど同じに見えます:( .ここで何が起こっているのかを理解するのを手伝ってくれますか?

そのため、maxdop 1 を使用してもう一度テストを行いました。結果は次のとおりです。

毎週のパーティショニング

• 論理読み取り: 1381
• ロブ論理読み取り: 108619
• ロブ物理読み取り: 1362
• ロブ先読み読み取り: 200664

毎月のパーティショニング

• 論理読み取り: 739
• ロブ論理読み取り: 94901
• ロブ物理読み取り: 402
• ロブ先読み: 262598

これは実行計画です。両方の実行でまったく同じように見えます。詳細は次のとおりです。

http://i.stack.imgur.com/293oN.png

読み取り操作の数の違いは以前ほど大きくなく、毎週のパーティショニングではより多くの物理読み取りがあります。さらに、毎週のパーティショニングでは、より多くの論理読み取りがあります。それは私が期待したものとは正反対です:/。

実行計画、(毎月のパーティション分割) 最初に CI を作成し、その後クラスター化された列ストア インデックスを作成しました (drop existing = on および maxdop 1 を使用)

http://i.stack.imgur.com/Euo8m.png

私は SQL Server 2014 の評価版を持っていました。有効期限が切れたため、標準バージョンの SQL Server 2014 を購入しました。残念ながら、評価期間中に少なくとも 1 つの列ストア インデックスを作成しました。たぶん複数。データベースがサスペクト モードになっており、列ストア インデックスを削除する必要があると通知されます。ただし、疑わしいモードであるため、ドロップできません。

sys.indexes を実行できますが、問題のデータベースのインデックスが表示されません。DBCC CHECKDB を実行できません。SQL Server の次のレベルアップにお金を払いたくありません。

SQL Azure で Clustered Clustered Index を使用して Top with tables を使用することについて質問があります。

両方のテーブルにクラスター化された列ストア インデックスがあり、テーブル HeaderTable には 300K 行、テーブル ValuesTable には 6.5M 行があります。

ご覧のとおり、2 番目のクエリの一番上の操作は非常に低速です。たぶん、誰かがこの問題についていくつかのヒントを持っていますか?

こんにちは、設計に関する質問があります。

同じデータベース管理システムの列ストアと行ストアの両方に XML データベースを効率的に隠すシステムを設計するにはどうすればよいでしょうか?

ありがとう。