円柱状データベースがデータサイエンスに適している理由は何ですか？

カラムナーデータストアをデータサイエンスや分析に適したものにする利点は何ですか？

列指向のデータベース（= columnar data-store）は、ディスクの列ごとにテーブルのデータを格納し、行指向のデータベースは、行ごとにテーブルのデータを格納します。

行指向データベースと比較して、列指向データベースを使用することには2つの主な利点があります。最初の利点は、いくつかの機能で操作を実行する場合に読み取る必要があるデータの量に関連しています。簡単なクエリを考えてみましょう。

SELECT correlation(feature2, feature5)
FROM records

従来のエグゼキュータは、テーブル全体（つまり、すべての機能）を読み取ります。

代わりに、列ベースのアプローチを使用して、関心のある列を読み取るだけです。

2番目の利点は、大規模なデータベースでも非常に重要ですが、1つの特定の列のデータがすべての列にわたって均一であるため、列ベースのストレージで圧縮率が向上することです。

列指向のアプローチの主な欠点は、特定の行全体の操作（ルックアップ、更新、削除）が非効率的であることです。ただし、分析用データベース（「ウェアハウジング」）でこのような状況が発生することはほとんどありません。つまり、ほとんどの操作は読み取り専用で、同じテーブルの多くの属性を読み取ることはほとんどありません。

一部のRDMSは、列指向のストレージエンジンオプションを提供します。たとえば、PostgreSQLにはテーブルを列ベースで保存するオプションがネイティブにありませんが、Greenplumはクローズドソースのテーブルを作成しました（DBMS2、2009）。興味深いことに、Greenplumは、スケーラブルなデータベース内分析のためのオープンソースライブラリであるMADlib（Hellerstein et al。、2012）の背後にもありますが、これは偶然ではありません。より最近では、高速分析データベースに取り組んでいる新興企業であるCitusDBが、PostgreSQL用のオープンソースの柱状ストア拡張機能であるCSTOREをリリースしました（Miller、2014）。Googleの大規模機械学習用システムSibylも列指向のデータ形式を使用しています（Chandra et al。、2010）。この傾向は、大規模な分析のための列指向ストレージへの関心の高まりを反映しています。ストーンブレイカー等。（2005）は、列指向のDBMSの利点についてさらに議論します。

2つの具体的なユースケース：大規模機械学習のほとんどのデータセットはどのように保存されますか？

（答えのほとんどは、BeatDB：大規模な信号データセットから顕著性を明らかにするためのエンドツーエンドのアプローチから来ています。フランクデルノンクール、SM、論文、MIT科EECS）

何をするかによります。

列ストアには2つの重要な利点があります。

• 列全体をスキップできます
• ランレングス圧縮は列でより効果的に機能します（特定のデータ型、特に明確な値がほとんどない場合）

ただし、欠点もあります。

• 多くのアルゴリズムはすべての列を必要とし、一度に記録するだけ（k-meansなど）、またはペアワイズ距離行列を計算する必要さえあります。
• 圧縮手法は、スパースデータ型とファクターでのみ機能しますが、二重値連続データではあまり機能しません
• 列ストアへの追加は高価なので、データのストリーミング/変更には理想的ではありません

カラムナーストレージは、OLAP別名「愚かな分析」（Michael Stonebraker）で非常に人気があり、もちろん、列全体を破棄することに興味がある場合の前処理にも使用されます（ただし、構造化データが最初に必要です-JSONをカラムナーに保存しないでください）フォーマット）。なぜなら、先週販売したリンゴの数を数えるなど、円柱状のレイアウトは本当に素晴らしいからです。

科学/データサイエンスの多くのユースケースでは、配列データベースを使用する方法があります（もちろん、非構造化入力データ）。たとえば、SciDBとRasDaMan。

多くの場合（ディープラーニングなど）、行列と配列は列ではなく必要なデータ型です。もちろん、MapReduceなども前処理に役立ちます。列データでさえあるかもしれません（ただし、配列データベースは通常、列のような圧縮もサポートしています）。

コラムナーデータベースは使用していませんが、Parquetと呼ばれるオープンソースのコラムナーファイル形式を使用しましたが、メリットはおそらく同じだと思います-大規模なデータの小さなサブセットのみを照会する必要がある場合のデータ処理の高速化列の数。140ノードのHadoopクラスターで約1時間半かかった673列の約50テラバイトのAvroファイル（行指向のファイル形式）でクエリを実行しました。Parquetでは、5列しか必要ないため、同じクエリに約22分かかりました。

列の数が少ない場合、または列の大部分を使用している場合、基本的にすべてのデータをスキャンする必要があるため、列指向データベースと行指向データベースの違いはあまりないと思います。列指向データベースは行を個別に格納するのに対し、列データベースは列を個別に格納すると考えています。ディスクからより少ないデータを読み取ることができるときはいつでも、クエリは高速になります。

このリンクは詳細の詳細を説明しています。

注：これは私の質問です。ここでの素晴らしい答えに感謝し、コンセプトを理解するのに役立ちました。

それで、私が理解した方法で概念を説明します：

通常、データベース内のデータは、次の形式でメモリに保存されます。

このデータを考えてみましょう：

           X1         X2
1   0.7091409 -1.4061361
2  -1.1334614 -0.1973846
3   2.3343391 -0.4385071

リレーショナル行ベースのストアでは、次のように格納されます。

1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071 

行の形で。

円柱ストアでは、次のように格納されます。

1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071

列の形で。

それで、これはどういう意味ですか？

つまり、行ベースの列ストアでは最後のいくつかの値または最初のいくつかの値が削除されるだけなので、挿入（および更新）と削除は高速です。ただし、各ブロックストアの値を削除する必要があるため、列ストアではそうではありません。

ただし、列の集計と操作が必要な場合、列ストアは列ベースで保存されるため、行ベースの対応よりもエッジがあり、その結果、個々の列へのアクセスは非常に簡単です。