ColumnStoreストレージアーキテクチャー

ストレージアーキテクチャー

MariaDB ColumnStoreにてテーブルが作られる際、カラムごとに少なくとも1つのファイルが作成されます。例えば、3カラムのテーブルが作成される場合には、最低3個のファイルがSANやディスクに作成されます。

• 各カラムはエクステントと呼ばれる800万行のファイルとして保存されます。1byteのデータ型のエクステントは8MBとなり、2byteなら16MB、4byteなら32MB、8byteなら64MB、また可変データ型の場合も、64MBとなります。Extentがいっぱいになると、新しいエクステントが自動生成されます。
• エクステントは一連のブロックとして物理的に保存されます。
• ブロックは8KBです。全てのデータベースブロックは、論理ブロック識別子(LBID)により一意に識別されます。
• 8文字以上のStringカラムはメインのカラムファイルにインデックスを保存し、実際の値は別の辞書ファイルに格納されます。
• Segmentファイルはカラムのデータを保持するディスク上の物理ファイルです。セグメントファイルがエクステントの最大数に達すると、新しいセグメントファイルが自動的に作られます。セグメントファイル内の最大エクステント数は、ColumnStore.xmlファイル内のExtentsPerSegmentFileに記載されており、Db Rootsの倍数を設定する必要があります。デフォルト値は4です。
• 集合的に、1つ以上のエクステントに相当する全てのカラムセグメントファイルはパーティションとなります。これはカラムストアにおける水平パーティショニングです。
• パーティションはフォルダなどのような階層構造に保存されます。
• MariaDB ColumnStoreメタストアは、パーティションに使用される情報と同様に、DBスキーマへのファイル構造・ファイル一をマップします。パーティションごとの最大ファイル数は、ColumnStore.xmlファイルのFilesPerColumnPartitionに記載しており、デフォルト値は2です。
• デフォルトではデータは圧縮されています。

エクステントマップ

MariaDB ColumnStoreは、論理範囲パーティショニングを実現し、インデックスや手作業によるパーティショニング、マテリアライズドビュー、サマリーテーブル、その他の構造やオブジェクトを不要にするエクステントマップとして知られる、スマートな構造を採用しています。これらの行指向の(通常の)データベースでクエリパフォーマンスを得るためのチューニングは不要です。

エクステントは物理セグメントファイル内に存在する領域の論理ブロックで、8～64MBのサイズとなります。各エクステントは、同じ行数となり、小さなデータタイプではエクステントのサイズも小さくなります。

エクステントマップは全エクステントと関連するブロック(LBID)を、エクステント内のデータの最小値と最大値とともに保持しています。

エクステントマップのマスターデータはメインのパフォーマンスモジュールに存在します。システム起動時にメモリ内に読み込まれ、他のすべてのユーザーモジュールおよびパフォーマンスモジュールにコピーされます。これはディザスターリカバリーおよびフェイルオーバーの目的のためです。全てのノードは高速なアクセスのためにエクステントマップをメモリ内に保持します。エクステントが更新されると、更新情報がすべてのノードへ伝達されます。

エクステントマップの動作の仕組み

エクステントマップは論理範囲によるパーティショニングとクエリ処理に必要なブロックのみへのアクセスを実現します。これはMariaDB ColumnStoreにおいて、いわゆる"エクステント除外"機構により実現されます。"エクステント除外"により、クエリの結合やフィルタに必要のないエクステントを除外し、I/O処理を減らすことが可能となります。

エクステント除外機構はMariaDB ColumnStoreにより、結合やフィルタに必要なカラムのみをスキャンすることにより実現されます。 その後、各エクステントで保持している最大値と最小値の情報を参照し、さらなる除外を行います。フィルタ処理においてカラムをスキャンする際にエクステントを除外するには、フィルタの値と、各エクステントの最大値と最小値を比較することにより実現されます。もしフィルターの値がエクステントの最大値と最小値の範囲外であれば、そのエクステントは除外されることになります。

この自動のエクステント除外機構は、系列データ、整列されたデータ、パターン化されたデータや、時間で頻繁に参照されるような時系列データに非常に適しています。また、グループ化されているような値を保持するカラムにも適しています。

例:

リアルタイム解凍と圧縮

カラム型ストレージは、似たデータがそれぞれのカラムファイルに格納されているため、優れた圧縮性能を実現します。ほとんどのデータは優れた圧縮率を示し、65%から95%のストレージ容量の節約を実現します。ただし、実際の圧縮率は、格納されているデータのランダム性やユニークな値の数に依存します。

MariaDB ColumnStoreの圧縮ストラテジーは、優れた圧縮性能を維持しつつも、読み込みのパフォーマンスを重視しています。圧縮率を向上させるよう調整することで、ディスクからの読み込み時のパフォーマンスを最適化することにもつながります。これにより、I/O限界のあるシステムでもパフォーマンスを改善することが可能となります。

圧縮モード

デフォルトでは圧縮が有効になっています。しかしながら、テーブルごとに、またはカラムごとに制御することも可能です : infinidb_compression_type参照 圧縮が有効な場合、MariaDB ColumnStoreではsnappy圧縮を使用します。

バージョンバッファー

MariaDB ColumnStoreは、修正されるディスクブロックを保持するバージョンバッファーを備えています。これにより、MVCC(multi-version concurrency control)サービスのようなトランザクションのロールバック操作や、データベースのクエリー一貫性のビューを提供可能なデータベースの"スナップショット読み込み"機能を提供します。MariaDB ColumnStoreの全てのステートメントは、データベースのある時点でのバージョン(or スナップショット)で実行される。その番号やシステム変更番号(SCN, System Change Number)と呼ばれます。バージョンバッファーと呼ばれていますが、メモリとディスクの双方で実現されています。

バージョンバッファーファイルの動作の仕組み

バージョンバッファーはメモリ内にハッシュテーブルを展開し、実行中のトランザクション情報へのアクセスを提供します。起動直後の初期サイズは4MBのメモリですが、

The Version Buffer utilizes in-memory hash tables to supply memory access to in-flight transaction information. The initial size upon startup is 4MB with the memory region growing from that amount to handle blocks that are being modified by a transaction. Each entry in the hash table is a 40-byte reference to an 8K block that is being modified.

The number of rows being updated is not the limiting factor for the Version Buffer, rather the number of disk blocks that are being updated. The size can be increased but caution should be used since updating more disk blocks can allow the update/delete statements to run for long periods of time and if a problem is encountered a rollback would also take a long period of time.

The Version Buffer files default to a 1GB-sized file on each DBRoot, which is configurable via the VersionBufferFileSize parameter. The Version Buffer files are spread across each DBRoot in the system.

NOTE: While MariaDB ColumnStore on HDFS has not been tested in the current release, it inherits this behavior from InfiniDB when configured to run as a Hadoop query engine over HDFS. In this configuration the MVCC function (and hence usage of the Version Buffer files) is disabled. HDFS is a write-only file system and hence block-level versioning in the MVCC model is not operationally practical. MariaDB ColumnStore supports statement level tracking and rollback capability for DML operations when running over HDFS. Queries over HDFS operate in more of an “eventual consistency” mode where queries will converge to the proper result at a point in time when updates are completed, but queries issued concurrently with updates will use whatever block happens to be current at the time the block-level execution occurs.

Transaction Log

MariaDB ColumnStore supports logging committed transactions to MariaDB Server's binary log.