Japan MariaDB User Group(JPMUG)とは
様々な活動を通してMariaDB社のソリューションを広めるためのグループです。また、定期的に開催される開発者会議にもコミッターとして参加することを目指しています。まだ始まったばかりです。広く参加者を求めています。
Japan MariaDB User Group - Facebookページ
パフォーマンス改善の切り札
企業のOLTPシステムはツール群などの充実もあり、基本部分のチューニングに関しては落ち着きはじめ、すでに何本もの本番システムを稼働させている状況ではないでしょうか？。
しかし、日時ジョブや月次ジョブ、あるいは棚卸しのように一定期間で大量にデータを検索・集計するための処理コストが新たな課題になりつつあります。 前者はハードウェア増強などで大胆に変えることも可能ですが、後者は抜本的な改善が求められます。
だからこそ今、Columnar Database に注目が集まっています。 Columnar Database は棚卸しのような処理の切り札となり得るアーキテクチャです。 そのメリットは何と言っても検索スピードなのですが、対してOLTPでは使い物になりません。 ですから、Columnarには日時でデータを整理して流し込むイメージで使います。 そこで、想像してください。棚卸しはColumnarからやるのです。
本稿でClumnStoreとはどのようなエンジンなのかを学び、実際にインストールおよび検証を行う助けになれば幸いです。
MariaDB ColumnStoreって何？
MariaDB ColumnStoreはチューニングレスで高い検索パフォーマンスを実現するDWH特化型データベースです。
MariaDB ColumnStoreは大規模並列分散データ環境での処理が可能な次世代カラム型ストレージエンジンです。
MariaDB ColumnStore
ペタバイトのデータを処理できるように設計されており、リニアにスケールアウトし、分析クエリーのリアルタイム処理に特に優れた性能を発揮します。
MariaDB ColumnStoreはGPLのもとで提供されます。
https://mariadb.com/kb/ja/mariadb-columnstore/
分析/集計処理に最適なカラムストアエンジン
行指向DBが苦手とする、カラムデータ分析/集計に特化したカラムストアを採用したエンジン。
-
MySQL/MariaDBとの互換性
MySQL/MariaDBで利用可能なナレッジをそのままColumnStoreでも使うことができます。
ただし、一部制限事項等があります -
専用ハードウェア不要
分析用に高価な専用ハードウェアを用意する必要はありません。 一般的なスペックのサーバで利用可能です。
-
リニアにスケールアウト
ColumnStoreはスケールアップ、及びスケールアウトの両方に対応しています。 最初は１台でスタートし、データ量に合わせて台数を増やしていくといった柔軟な運用が可能です。
歴史
CoumnStoreの前身は、米Calpont社がMySQLからフォークし開発した InfiniDB がベースとなっています。
2014年3月に InfiniDB 4.0.2.1-1がリリースされ、その後 2014年9月には 4.6.2-1 をリリースしています。
MySQL互換のカラムナーデータベースとして注目を浴びた InfiniDB ですが、2016年 米Calpont社の倒産を契機にリリーススケジュール及びサポートが暗礁に乗り上げます。
その後、MariaDB社がソースを含むライセンスを取得し、2016年6月にColumnStore 1.0.1 をリリース。 順調に修正を重ね 2017年8月に MariaDB10.1 をベースにした ColumnStore 1.0.11 GAをリリースしています。
また年内リリース予定の次期バージョンである MariaDB 10.2 をベースとした ColumnStore 1.1.0 の開発も順調に進み、9月に 1.1.0 beta のリリースがされました。
アーキテクチャについて
大規模並列処理(Massively Parallel Processing)
スケールアップ/スケールアウトを実現する３つのモジュールにより構成されています。
-
●ユーザーモジュール
- MariaDB Serverインスタンスと並行スケーリングを扱うためのプロセス。 また、MySQL互換のクエリを分散実行可能なクエリに変換する。 このモジュールのおかげで従来のクエリのままで分散実行が可能になる。
-
●パフォーマンスモジュール
- パフォーマンスモジュールはデータの保存、検索、管理を受け持ち、クエリー操作に対するブロックへのリクエストを処理し、クエリーに応えるプロセス。
-
●ストレージ
- オンプレミスで動作するときは、ローカルストレージや、SANなどの共通ストレージを使用可能
- Amazon EC2環境では、ephemeralまたはElastic Block Store (EBS)を使用可能
- シェアードナッシング環境でデータの冗長化が必要な場合、GlusterFSや Apache Hadoop Distributed File System (HDFS)を使用可能
ColumnStoreのアーキテクチャ概要
https://mariadb.com/kb/ja/columnstore-columnstore/
対称型マルチプロセッシング(Symmetrical Multi Processing)
またColumnStoreは複数ノードによるスケールアウトだけでなく、１サーバのマルチコアを活用する並列処理によるスケールアウト構成をとることもできる。 まずは1ノード(SingleServer)でスモールスタート後、データサイズに合わせてノードを増やすことでスケールアウトする等、柔軟な構成が可能です。
システムデータベース
従来のMySQLが持つシステムデータベースに加えて下記のデータベースが追加されています。
-
calpontsys
ColumnStoreテーブルのメタデータを管理。カラムとエクステントマップを紐付けるために必要な ColID 情報等が格納されています。
-
infinidb_querystats
クエリパフォーマンス情報を管理。 クエリ情報を蓄積するためには、別途情報取得用の設定変更を実施する必要があります。
-
infinidb_vtable
クエリ実行の一部である一時テーブルの作成に使用されます。ColumnStoreクエリを実行するすべてのユーザーは、このデータベース上で、一時テーブルオプションを作成する必要があります。
ColumnStoreシステムデータベース
https://mariadb.com/kb/ja/columnstore-system-databases/
ExtentMap
大量のデータから目的のカラムデータを高速に参照する仕組み。 カラムデータを約800万行毎に区切って最小値/最大値を管理する。 該当するデータがないブロックを、実データを参照することなく判定できるため大幅にDisk I/O を削減することができます。
下図はカラム名 Col-D の最小/最大値を ３つのエクステントマップ(Ext-1~3)にそれぞれ格納していることを表したものです。
- 物理的なセグメントファイル内に存在する論理ブロックを管理
- エクステント及び対応するブロックを管理
- データの抽出と配置は、エクステントマップにより高速で処理される
- リアルタイム解凍と圧縮
- バージョンバッファーファイル（UNDO)
例えば下記のクエリを実行した場合。
where句に指定された範囲は 110~180。 この範囲に該当するデータは ２番目のエクステントマップ(Ext-2)にしかないことがわかるので、１番目(Ext-1)と３番目(Ext-3)のエクステントマップに対する参照をスキップできる。 ２番目のエクステントマップ情報から、実データが格納されているブロック対してのみDisk I/Oが発生するため、大幅にDisk I/Oを削減できる。
SELECT COL–D FROM TABLE WHERE COL-D BETWEEN 110 AND 180 ;
ColumnStoreストレージアーキテクチャー
https://mariadb.com/kb/ja/columnstore-storage-architecture/
スケールアウト性能について
| AWS Instance | DATA | ||
|---|---|---|---|
| Type | m4.2xlarge | SNMP log | 約1億行 |
| VCPU | 8 | Size | 23GB |
| Memory | 32GB | ||
| SSD |
800GB IOPS 2400 / 3000 |
||
下記グラフは ColumnStore がリニアにスケールアウトしていることを示すものです。 InnoDB/ColumnStore１ノードあたりの性能差は約１０倍近くあることがわかります。 また、ColumnStoreのノードを追加することでリニアに性能が向上していることもわかります。
トランザクション性能について
| Engine | Transactions | XA |
|---|---|---|
| Columnstore | YES | NO |
| MyISAM | NO | NO |
| InnoDB | YES | YES |
show engines で見るとトランザクション YES、分散トランザクションは NO になっています。 ならばと既存のトランザクションを伴うアプリの検証用にエンジンを InnoDBからColumnstore に置き換えるといったことはするべきではありません。 ColumnStoreのトランザクション性能は決して高くないのです。
# sysbench --test=oltp --db-driver=mysql --mysql-socket=/usr/local/mariadb/columnstore/mysql/lib/mysql/mysql.sock --num-threads=1[1] --max-requests=500 --max-time=0 --oltp-test-mode=complex --mysql-user=sbtest --mysql-password=sbtest --oltp-test-mode=nontrx --oltp-nontrx-mode=insert run
注
[1]:columnstoreに合わせて並列度1(num-threads=1)で比較
