DBMS-90度回転
過去数十年にわたるデータ量と処理速度の要件は、何度も拡大しています。 データベース管理システム（DBMS）は、新しい現実に対応しようとしており、重大な進化的および革命的な変化を受けています。 これらの進化的要因の1つは、いわゆる 垂直（列ベース）ストレージシステム。
例として、古典的なEMPLOYEEテーブルを見てみましょう。
テーブル従業員/従業員
従来の（行ベースの）DBMSでは、このデータは行ごとに配置されます。
同時に、たとえば、すべての従業員の名前を選択するには、まずすべての行を読んでから、不要な行を捨てる必要があります。
垂直（列ベース）DBMSでは、同じデータがいくつかのブロックで表されます：
（非常に簡略化された形式で表示）
実際、この新しいデータビューは、従来のデータビューに対して90度回転しています。 これにはいくつかの利点があります。
2009年、Michael Stonebreaker（誇張せずにリレーショナルDBMSのアインシュタインと呼ぶことができる）は、古典的なDBMSの時代の差し迫った衰退を予測しました。 根拠がないように、彼は新しい「垂直」DBMS Verticaの開発を発表しました。
もちろん、「従来の」DBMSのベンダー（OracleやIBMなど）は、時代が終わったとは考えていません。 したがって、彼らは「ハイブリッド」ストレージシステムを現代のパラダイムとして提供しています。 実際、これは従来のストレージシステムのアドオンであり、データは行全体ではなく列ではなく、複数の列のブロックグループに格納されます。 ハイブリッドモデルは、データ圧縮において「垂直」ストレージほど効果的ではありませんが、適切な妥協案です。
ハイブリッドDBMSは、必ずしも公式としてハイブリッドとは必ずしも言えません。 たとえば、Oracleは自社の技術をAdvanced Compression（11g）と呼び、「ハイブリッド」と呼ぶと圧縮ユニットをブロックします。 Facebookがニーズに合わせて開発した非リレーショナルDBMS Cassandraでは、このようなブロックは列ファミリーと呼ばれます。
オブジェクトデータベースの場合と同様に、ベンダーは「ファッションはまもなく通過し、リレーショナルデータベースは永遠に残る」という実証済みの原則に基づいて行動します。
小さなFAQ。 ほとんどすべての最新のDBMSが以下をサポートしているのに、なぜ垂直DBMSが必要なのですか？
それを理解しましょう。 理論的には、インデックスとマテリアライズドビューからの通常の「水平」DBMSで、非常に読み取り指向のストアを作成できます。 DBMSがデータとインデックスさえも効果的に圧縮すると仮定しましょう。 その結果、出力でその場しのぎの垂直ストレージのようなものを取得できるようになります。 もちろん、それは冗長になり（データの記録が複雑になることを意味します...）、データストレージは常に最適ではありませんが、本質的には「垂直」またはハイブリッド表現に対応します。
実際には、垂直DBMSは、これらすべてをデータストレージレベルで既により最適に実装します。 Stonebreakerが彼の新しいC-Storeエンジンについて書いているように、使用されている技術には新しいものは何もありません。
関連リンク：
PS。 念のため、「垂直」DBMSと「水平」DBMSの分離は、現在普及しているSQL / NoSQLの二分法とは関係がないことを明確にします。
例として、古典的なEMPLOYEEテーブルを見てみましょう。
テーブル従業員/従業員
| ID | NAME | JOB_TITLE |
|---|---|---|
| 1 | ヴァシャ | ローダー |
| 2 | イリーナ | 秘書 |
| 3 | ペティア | キャッシャー |
| 4 | アントン | マネージャー |
| 1 | ヴァシャ | ローダー |
| 2 | イリーナ | 秘書 |
| 3 | ペティア | キャッシャー |
| 4 | アントン | マネージャー |
垂直（列ベース）DBMSでは、同じデータがいくつかのブロックで表されます：
| IDブロック | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| NAMEブロック | ヴァシャ | イリーナ | ペティア | アントン |
| JOB_TITLEブロック | ローダー | 秘書 | キャッシャー | マネージャー |
（非常に簡略化された形式で表示）
実際、この新しいデータビューは、従来のデータビューに対して90度回転しています。 これにはいくつかの利点があります。
- 「列」データブロックはサイズが小さく、データサイズが小さいほど、管理しやすくなります。
- ブロックは、異なるディスクやサーバーに分散することもできます（垂直分割）。
- 垂直（「円柱状」）データは圧縮がはるかに簡単であり、メモリスペースを節約し、ディスクシステムの負荷を軽減します。
2009年、Michael Stonebreaker（誇張せずにリレーショナルDBMSのアインシュタインと呼ぶことができる）は、古典的なDBMSの時代の差し迫った衰退を予測しました。 根拠がないように、彼は新しい「垂直」DBMS Verticaの開発を発表しました。
もちろん、「従来の」DBMSのベンダー（OracleやIBMなど）は、時代が終わったとは考えていません。 したがって、彼らは「ハイブリッド」ストレージシステムを現代のパラダイムとして提供しています。 実際、これは従来のストレージシステムのアドオンであり、データは行全体ではなく列ではなく、複数の列のブロックグループに格納されます。 ハイブリッドモデルは、データ圧縮において「垂直」ストレージほど効果的ではありませんが、適切な妥協案です。
ハイブリッドDBMSは、必ずしも公式としてハイブリッドとは必ずしも言えません。 たとえば、Oracleは自社の技術をAdvanced Compression（11g）と呼び、「ハイブリッド」と呼ぶと圧縮ユニットをブロックします。 Facebookがニーズに合わせて開発した非リレーショナルDBMS Cassandraでは、このようなブロックは列ファミリーと呼ばれます。
オブジェクトデータベースの場合と同様に、ベンダーは「ファッションはまもなく通過し、リレーショナルデータベースは永遠に残る」という実証済みの原則に基づいて行動します。
更新
小さなFAQ。 ほとんどすべての最新のDBMSが以下をサポートしているのに、なぜ垂直DBMSが必要なのですか？
- データ圧縮
- クラスターインデックス、マテリアライズドビューなど
それを理解しましょう。 理論的には、インデックスとマテリアライズドビューからの通常の「水平」DBMSで、非常に読み取り指向のストアを作成できます。 DBMSがデータとインデックスさえも効果的に圧縮すると仮定しましょう。 その結果、出力でその場しのぎの垂直ストレージのようなものを取得できるようになります。 もちろん、それは冗長になり（データの記録が複雑になることを意味します...）、データストレージは常に最適ではありませんが、本質的には「垂直」またはハイブリッド表現に対応します。
実際には、垂直DBMSは、これらすべてをデータストレージレベルで既により最適に実装します。 Stonebreakerが彼の新しいC-Storeエンジンについて書いているように、使用されている技術には新しいものは何もありません。
最後に、マテリアライズドビュー、スナップショットアイソレーション、
トランザクション管理と高可用性も
広く研究されています。 C-Storeの貢献は
これらの技術の革新的な組み合わせは
同時に、パフォーマンスの向上、K-安全性、
効率的な検索、および高性能トランザクション。
関連リンク：
- http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext
- http://www.daniel-lemire.com/blog/archives/2009/09/16/relational-databases-are-they-obselete/
- http://www.dbms2.com/2009/09/03/oracle-11g-exadata-hybrid-columnar-compression/
- http://www.daniel-lemire.com/blog/archives/2009/09/04/changing-your-perspective-horizontal-vertical-and-hybrid-data-models/
- http://storagemojo.com/2009/09/14/rdbms-going-like-mainframes/
- http://wiki.apache.org/cassandra/DataModel
PS。 念のため、「垂直」DBMSと「水平」DBMSの分離は、現在普及しているSQL / NoSQLの二分法とは関係がないことを明確にします。
All Articles