問題タブ [columnstore]

現在 Azure で実行しており、数億行のテーブルがあります。このテーブルは静的で、毎週更新されます。ColumnStore インデックスを調べましたが、残念ながらまだ Azure ではないので、以下に質問します。

• ColumnStore インデックスは Azure で利用できますか?
• そうでない場合、ColumnStore インデックスが提供するのと同じパフォーマンス上の利点を得るために、他にどのようなテクノロジを使用できるでしょうか?
• Azure Table Storage を使用して同じクエリ パフォーマンスを得ることができますか?

私は Azure と Columnar データベースの両方の初心者なので、これらの質問をする場合はご容赦ください.. :)

次の表があるとしましょう。

そしてクエリ：

Tが列ストアインデックスによってインデックス付けされた場合、このグループ化クエリは通常、非クラスター化列ストアインデックススキャンによって駆動されます。

列ストアインデックスが行を列ごとの形式で格納し、各列が個別に並べ替えられている場合、行ごとに一度に複数の列を提供するにはどうすればよいでしょうか。個々の列は異なるソート順でソートされているため、これは不可能のようです。個々の列をマージして、両方の列（この例ではString1、String2）を含む完全な行に戻す方法は考えられません。

これは内部でどのように機能しますか？

列ストア インデックスの利点の 1 つは、1 つの列のデータが "ディスク上で隣り合って" 格納されることです。これは、圧縮率が向上し、読み取り時間が短縮されることを意味します。

でも; B ツリー (通常の非クラスター化インデックス) を使用する場合、そのツリーの葉はデータそのものではありませんか? では、列 A にインデックスを作成すると、列 A のすべてのフィールドがテーブルと並行してディスク上で並べ替えられて表示されませんか? これは、データを圧縮して高速に読み取ることができることを意味します。

要するに、列ストア インデックスが単一列の B ツリーよりもパフォーマンスが高いのはいつですか?

前もって感謝します！

〜2億行と〜15列のテーブルがあります。テーブルに列ストア インデックスを作成する予定です。列ストア インデックスで使用する列の順序に基づいて、パフォーマンスに変化はありますか? はいの場合、その背後にあるロジックは何ですか?

SQL Server 2012 の列ストア インデックス機能をテストして楽しんでいました。このようなインデックスを使用してテーブルを更新/挿入することはできないため、いくつかのオプションを読みました: 別のテーブルを保持し、一括挿入ごとに新しいパーティションを使用するか、インデックスを無効にします。 、更新/挿入を実行してから、インデックスを再構築します。

私のテストでは、後者のオプションを選択し、次のストアド プロシージャで終了しました。

これらの行を手動で実行すると、すべて正常に動作します。しかし、この手順を実行すると、列ストア インデックスを持つテーブルでは更新/挿入を実行できないというエラーが表示されます。

どうしてこれなの？

アップデート：

以前に受け入れた回答のアドバイスに従いましたが、それでも同じ結果が得られます。

sproc呼び出しの周りに「begin tran」と「commit tran」を配置しようとしました。

次のような動的SQLを使用します。

動作しますが、実際には、動的SQLなしでやりたいと思っています。この場合はありえないのでしょうか？

データ ウェアハウジングと列指向データベースについて質問があります。私のプロジェクトでは、会社はビジュアル スタジオの SQL サーバーでウェアハウス ソリューションを使用していますが、大量のデータに対して複雑な質問をクエリするときにパフォーマンスに問題があります。データベースを列ベースのデータベースに置き換えたいと考えています。行指向のデータベースをより列ベースに "変換" したり、Vertica や Sybase IQ などのオープン ソース データベースを使用したりできることは知っていますが、それがウェアハウスにどのように収まるか疑問に思っています。ウェアハウスにスター ジョイン スキーマを用意する必要がありますか、それとも、代わりにカラム型アプローチを使用できますか? これはちょっとばかげた質問だと思いますが、さまざまなデータベースとソリューションの調査を開始する前に、すべてを理解しようとしています。

前もって感謝します！

巨大なテーブルに列ストア インデックスを作成する場合、列ストア インデックスを格納するためにディスク上の別の物理ストレージを使用しますか、それともベース テーブルのストレージ構造を行ストレージから列ストアに変更しますか。

ここで私の質問は、任意のテーブルに通常のインデックスを作成すると、列ストア インデックスと同じように、ベース テーブルに影響を与えずに別のストレージを使用して、インデックス付きの列データを B ツリーに格納することです。

私たちの SQL Server 2012 Enterprise セットアップには説明できないパフォーマンスの問題があり、皆さんにアイデアがあれば幸いです。

集計する多数の int 列を含むファクト テーブルと、地域ディメンション テーブルがあります。

これは、ファクト テーブルの構造です。

• regionId (整数)
• 収益 (10 進数 10,2)
• orderIntake (10 進数 10,2)

これがディメンション テーブルの構造です。

• worldRegion(varchar(100)9
• クラスター (varchar(100))
• 国 (varchar(100))
• regionId (整数)

ファクト テーブルとディメンション テーブルは、regionId 列に対する INNER JOIN を介して接続されます。国を制限しない限り、これのパフォーマンスは非常に優れています。

例えば

SELECT SUM(revenue) FROM factTable f INNER JOIN regionDim r ON f.regionId=r.regionId

高速です (<1 秒)。

でも

SELECT SUM(revenue) FROM factTable f INNER JOIN regionDim r ON f.regionId=r.regionId WHERE r.country IN ('France','Germany')

約 500k レコードではかなり遅い (> 8 秒)。

次のような指標があります。

• regionId 列のファクト テーブルの ColumnStore インデックス
• ディメンション テーブルのクラスター化インデックス (regionId、country、cluster、worldRegion)

インデックスまたは全体的な構造の観点から変更できることはありますか?