問題タブ [columnstore]

SQL Server 2012 で利用できる「ColumnStore Index」というオプションがあります。Cassandra
、HBase などのカラムナ データベースと比較できますか?
SQL Server 2012 を使用する利点は次のとおりです。

• 更新可能です
• リレーショナルです

より高速なクエリ パフォーマンスが必要な場合に、SQL Server 2012 と他の列指向データベースのどちらを選択するかについて、他にどのような要因を考慮することができますか。

こんにちは、SQL の達人です... 今月は、解決できないように見える長い問題があります。私はこの非常に広い（レポート）テーブルを約持っています。100以上のフィールド。現在、約 200 万件のレコードがあり、データが来る速度を考えると、今後 1 ～ 2 か月でこの数はおそらく 2 倍になるでしょう。現時点では許容範囲です。しかし、次の数か月でもう確信が持てなくなります。基本的に、このタイプのテーブルに最適なインデックス作成プランを知りたいだけです。これは実際のテーブルではありませんが、非常に近いものです。使用されるさまざまなデータ型を説明したいだけです。

現在、このテーブルは現在、次の方法でクエリされています。

各パラメーター/フィールドの可能な値は次のとおりです。

私は基本的な実行計画の読み取りを知っており、私が見ることができるものから...たくさんのスキャンが行われています. しかし、私が言ったように、私はすでに壁にぶつかったようです. 小さなテーブルの目的に基づいてインデックスを作成する方法を知っていますが、これは広いテーブルですか?? 私はただ自分自身を笑うことができます:D

アイデアはありますか？Columnstore INDEX について少し読んだことがあります..これは私が考えることができる最も実行可能なソリューションです..しかし、この時点でこのアプローチについて利用できる情報はほとんどありません。

どうやってこのテーブルを思いついたのか疑問に思っているなら. その内容は異なるテーブルから来ています（フラット化）。処理は毎晩行われます。結果は CSV ファイルにエクスポートされ、別のレポート アプリケーションのデータ ソースとして機能します。

前もって感謝します！

[この MSDN の記事] を読んでいました。( http://msdn.microsoft.com/en-us/library/gg492088.aspx )

クラスター化インデックスと非クラスター化インデックスの主な違いの 1 つは、クラスター化インデックスが更新可能であることです。結構ですが、クラスター化されていないインデックスのどのプロパティが、それ (およびテーブル) を読み取り専用にするのでしょうか? テーブルへの変更がインデックスに反映されないのはなぜですか?

SQL Server 2014 で導入されたクラスター化列ストア インデックスについて(ここ、ここ、ここ) を読みました。

• 列ストア インデックスは更新可能
• テーブル スキーマを変更できます (ドロップ カラム ストア インデックスなし)
• 実表の構造は列状にすることができます
• 圧縮効果によって節約されるスペース (列ストア インデックスを使用すると、テーブルに使用される初期スペースの 40 ～ 50% を節約できます)

さらに、以下をサポートします。

• 行モードとバッチ モードの処理
• BULK INSERT ステートメント
• その他のデータ型

私が理解しているように、次のようないくつかの制限があります。

1. サポートされていないデータ型
2. 他のインデックスは作成できません

しかし、次のように言われています。

クラスター化された列ストア インデックスでは、すべてのフィルターの可能性が既にカバーされています。クエリ プロセッサは、セグメントの削除を使用して、クエリ句で必要なセグメントのみを考慮することができます。セグメント消去を適用できない列では、データが圧縮されて必要な I/O 操作が少なくなるため、すべてのスキャンが B ツリー インデックス スキャンより高​​速になります。

私は次のことに興味があります。

• 上記のステートメントは、多くの重複値が存在する場合、B ツリー インデックスよりもクラスター化された列ストア インデックスの方が常にデータを抽出するのに適していると言っていますか?
• coveringたとえば、テーブルに多くの列がある場合、クラスター化された列ストア インデックスと非クラスター化 B ツリー インデックスの間のパフォーマンスはどうでしょうか。
• クラスター化された列ストア インデックスとクラスター化されていない列ストア インデックスを 1 つのテーブルに組み合わせることはできますか?
• そして最も重要なことは、テーブルが列化された格納されたインデックスの適切な候補であるかどうかを判断する方法を誰か教えてもらえますか?

最適な候補は、更新/削除/挿入操作が頻繁に実行されないテーブルであると言われています。たとえば、ストレージ サイズが 17 GB (約 7000 万行) を超えるテーブルがあり、新しいレコードが常に挿入および削除されているとします。一方、その列を使用した多くのクエリが実行されます。または、ストレージ サイズが約 40 GB (約 6000 万行) のテーブルがあり、毎日多くの挿入が実行されます。頻繁にクエリされるわけではありませんが、サイズを縮小したいと考えています。

答えは主に実稼働テストの実行にあることはわかっていますが、その前に、より適切な候補を選択する必要があります。

SQL 2014 での新しいクラスター化列インデックスの使用について調査しています。MS がこれらが「インメモリ」であると言うとき、それは正確にはどういう意味ですか? 最近では、「メモリ内」というモニカが頻繁に使われています。テーブル全体が常にメモリ内にあるということですか? または、ディスクにスワップアウトされますか。テーブル全体が常にメモリ内にある場合は使用したくありません。

ありがとう！

クラスター化列ストア インデックスを持つテーブルがあります。インデックスのため、このテーブルは主キーを持つことができません。実際には ID 列がありますが、インデックスを付けることができません。Entity Framework はキーを要求します。それ以外の場合は読み取り専用としてマークします。キーが何であるかをEFに伝えるにはどうすればよいですか?