そもそも、Oracle、SQL Server、MySQL、DB2、Postgreなどの時代の人気のあるリレーショナルDBMSは、ラジオがトランジスタ、長いもみあげ、フレアパンツであった1970年代にまで遡るアーキテクチャに基づいています。 DBMSの世界では、階層型およびネットワークデータ管理システムが普及しています。 データベースの主なタスクは、1960年代に紙ベースの会計からビジネスアクティビティに始まった大規模な移行をサポートすることでした。 紙文書からの膨大な量の情報が会計システムのデータベースに転送されました。会計システムは、すべての着信情報を確実に保存し、必要に応じてそれらをすばやく見つけることができました。 このような要件により、リレーショナルDBMSのアーキテクチャ上の機能が決定されました。これは、データの行ごとの保存、レコードのインデックス作成、操作のログ記録など、現在までほとんど変わっていません。
データの行ごとの保存は、通常、テーブルの行全体を単一のレコードとして物理的に保存するものとして理解され、フィールドは次々に順番に移動し、一般に最初のレコードは最後のレコードフィールドに続きます。 このようなもの：
[A1、B1、C1]、[A2、B2、C2]、[A3、B3、C3] ...
ここで、A、B、Cはフィールド（列）、1,2、3はレコードの番号（行）です。
このようなストレージは、通常はハードディスクに保存されるデータベースに新しい行を追加する頻繁な操作に非常に便利です。この場合、ドライブヘッドの1回のパスで新しいレコード全体を追加できます。 NMZDによって課せられた大幅な速度制限により、HDDヘッドの最小パス数で必要なレコードをディスク上で見つけることができる特別なインデックスのメンテナンスが必要になりました。 通常、検索するフィールドに応じて、いくつかのインデックスが形成されます。これにより、ディスク上のデータベースの量が数倍増加することがあります。 フォールトトレランスのために、従来のDBMSはログ内の操作を自動的に複製するため、さらに多くのディスク領域が必要になります。 その結果、たとえば、平均的なOracleデータベースは、その中の有用なデータの量の5倍のディスク容量を占有します。 天井が中程度のDB2データベースの場合、この比率はさらに大きくなります（7：1）。
しかし、1990年代には、会計システムに蓄積された情報の管理分析に使用される分析情報システムとデータウェアハウスが急増し、これら2種類のシステムの負荷の性質が根本的に異なることが明らかになりました。
トランザクションアプリケーションが、1つまたは複数のレコードの追加または変更（挿入/更新）の非常に頻繁な小さな操作によって特徴付けられる場合、分析システムの場合はまったく逆です-最大の負荷は、数十万および数百万のレコードの比較的まれではあるが重い選択（選択）によって作成されます。グループ化と合計値の計算（いわゆる集計）。 書き込み操作の数は少なく、多くの場合、全体の1％未満です。 また、多くの場合、記録は大きなブロックで行われます（バルクロード）。 分析サンプルには1つの重要な特徴があることに注意してください-原則として、それらには少数のフィールドしか含まれていません。 ユーザーの分析SQLクエリで平均で7〜8を超えることはほとんどありません。 これは、人間の心が通常5〜7セクション以上の情報を知覚できないためです。
ただし、たとえば、合計50個のテーブルから3つのフィールドのみを選択した場合はどうなりますか？ 従来のDBMSにはデータが行単位で保存されるため（覚えているように、会計システムに新しいレコードを頻繁に追加するために必要です）、すべてのフィールドを持つすべての行が絶対に読み取られます。 つまり、ディスクから3フィールドまたは50フィールドだけが必要かどうかは関係ありません。いずれにしても、それらはすべて完全かつ完全に読み取られ、ディスクI / Oコントローラーを通過して、要求に必要なものだけを既に選択するプロセッサーに転送されます。 残念ながら、通常、ディスクI / Oチャネルは分析システムのパフォーマンスの主な制限要因です。 結果として、このクエリの実行中の従来のDBMSの有効性は、余分なデータの必然的な読み取りのために10〜15倍低下する可能性があります。 さらに、ムーアの法則がディスクドライブのI / O速度に与える影響は、プロセッサやメモリサイズの速度よりもはるかに弱いです。 したがって、どうやら状況はさらに悪化するだけです。
この問題を解決するには、列化されたDBMSが必要です。 列データベースシステムの主な考え方は、従来のDBMSのように行ではなく列にデータを保存することです。 つまり、SQLクライアントの観点からは、データは通常の形式で表形式で表示されますが、物理的にこれらの表は列のコレクションであり、各列は本質的に1つのフィールドの表です。 この場合、物理的にディスク上で、1つのフィールドの値は次のように順番に保存されます-ほぼこのように：
[A1、A2、A3]、[B1、B2、B3]、[C1、C2、C3]など。
このようなデータ編成により、テーブルの50フィールドから3フィールドのみを選択すると、ディスクから物理的に読み取られるのは3列のみになるという事実につながります。 つまり、I / Oチャネルの負荷は、従来のDBMSで同じリクエストを実行する場合よりも約50/3 = 17倍少なくなります。
また、データをバッチで保存する場合、テーブルの1つの列ではデータが通常同じであるため、データを強力に圧縮する素晴らしい機会があります。これは行については言えません。 圧縮アルゴリズムは異なる場合があります。 そのうちの1つ、いわゆるRun-Length Encoding（RLE）の例を次に示します。
1年で1億件のレコードが作成されたテーブルがある場合、「日付」列には実際には366日以下の値が格納されます（うるう年を含む）。 したがって、このフィールドのソートされた1億の値を<date、number>の形式の値の366ペアで置き換え、この形式でディスクに保存できます。 同時に、約10万分の1のスペースしか占有しないため、クエリの実行速度が向上します。
開発者の観点から見ると、列データベースシステムは一般にACIDに準拠しており、SQL-99標準を大部分サポートしています。
まとめ
カラム化されたDBMSは、分析システムおよび読み取りのような操作の大部分のシステムにおける従来のDBMSの非効率的な操作の問題を解決するように設計されています。 安価で低電力の機器を使用して、クエリの実行速度を5、10、時には100倍も向上させることができます。また、圧縮により、データは従来のDBMSの場合よりも最大5〜10倍少ないディスクスペースを使用できます。
列化されたDBMSにも欠点があります-書き込みに時間がかかり、トランザクションシステムには適していません。また、原則として、「若さ」のために、従来のDBMSの開発に慣れている開発者には多くの制限があります。
列ベースのDBMSは通常、ビジネスインテリジェンス（ROLAP）クラスの分析システムおよびデータウェアハウスで使用されます。 さらに、データボリュームは非常に大きくなる可能性があります。300〜500 TBの例や、1 PBを超えるデータの場合もあります。
さらに読むためのリンク：
[1] M. Stonebreckerの記事「One Size Fits All：時間が来て消えたアイデア」の翻訳-citforum.ru/database/articles/one_size_fits_all
[2] ZyngaがリアルタイムゲームプラットフォームにVerticaを使用する方法のストーリー。 このリンクで彼女を知ることができます-tdwi.org/blogs/wayne-eckerson/2010/02/zynga.aspx
[3]私が知っている商用DBMSの唯一のオープンソースバージョンは、InfoBright Community Edition www.infobright.orgです。
Oleg Tsibulnyakからのヒント：
[4] LucidDB-最初はオープンソースの列データベース。 分析タスクのMySQLの代替として位置付けられているwww.luciddb.org
PS。 列DBMSに関する興味深い資料がまだある場合は、リンクを提供して、テキストに挿入します。