TL;DR
下記の観点で，AWS Auroraの性能検証を行いました．
- AWS Auroraと，EC2上に構成したMariaDBで性能比較しました
- RDBベンチマークTPC-Hによる計算時間の計測
- BI(Business Intelligence)向けの処理で，比較的大きな複数のテーブルからなるDBに対してクエリを発行するものです．
- 意思決定（Decision Making）などで使用される傾向がある処理です
- どちらかというと，Webサービスで使用される際の性能ではなく，バッチ処理での性能評価をしています
- RDBベンチマークTPC-Hによる計算時間の計測
-
データ量と処理時間の関係
- 対象データ量ごとにAWS Auroraでの性能評価を行います
-
この記事は，下記の記事の続編です．この記事から読み始めることもできます
実験設定
TPC-Hは，使用するテーブルサイズを指定する(SF: Scale Factor)ことができるので，
SF=1, 4, 8でベンチマークするテーブルを用意しました．
Aurora
以下の表のパラメータでAuroraを設定します．
| 設定名 | パラメータ |
|---|---|
| エディション | MySQL 5.6 との互換性 |
| DBエンジン | Aurora(MySQL)-5.6.10a |
| インスタンスタイプ | db.r5.large 2vCPU, 16GiB RAM |
| マルチAZ | なし |
MariaDB
- t2.smallを作成
- MariaDBインストール，自動起動の設定
sudo yum -y update
sudo yum -y install mariadb mariadb-server
sudo systemctl start mariadb
sudo systemctl enable mariadb
- 初期設定（ルートパスワードなどの設定）
sudo mysql_secure_installation
その他は，auroraと同じように，テーブルの作成，データの登録，インデックスの作成を行います．
実験手順
- Query1からQuery22まで，順番に実行し，
- クエリの実行ごとに
RESET QUERY CACHE;を実行し，キャッシュクリアしてパフォーマンスを正しい計測を行います
- クエリの実行ごとに
for i in `seq 1 22`; do
(time mysql -u [ユーザ名] -h [DBMSエンドポイント] -D [データベース名] -p[パスワード] < ${i}.sql) >> log.txt 2>&1;
mysql -u [ユーザ名] -h [DBMSエンドポイント] -p[パスワード] -e 'RESET QUERY CACHE;'
done
計測結果
TPC-Hで使用するテーブルおよびクエリの詳細は，ドキュメント(tpc-h_v2.18.0.pdf)を参照してください．
AuroraとEC2の比較
計算結果
- AWS auroraと，EC2(t2.small)で，SF=1 (1GiB)のデータを対象にしたベンチマーク結果を示します
考察：フルマネージドRDBサービスauroraの利点
- インスタンスタイプに応じた性能が得られているように見えます
- auroraはec2に比べて計算時間上の利点が示されています
- インスタンスタイプの差以上に，EC2よりも良い性能を示すクエリもあります（Query9, 10, 13, 14, 18)
- 大きなテーブル（lineitem）の結合処理を含むクエリ(Query 9, 10, 14, 18)
- likeを含むクエリ(Query 13, 14)
- これらの，重たい処理を含む場合に，auroraの利点が得られるようです
Auroraの結果の比較
計算結果
- AWS auroraで， SF=1, 4, 8 を対象にした計算結果を示します
考察: RDBのスケーラビリティ問題
- データ量に応じて，計算時間を要します
- 結合処理を含む場合(Query1以外)は，データの量に対して, $O(n^2)$ の計算時間を要します
- MySQLの結合処理はNested-loop joinであることから，苦手な処理です
- 大きなテーブル(lineitem)の結合を含むクエリで，極端に計算時間が大きくなるものもあります(Query3, 8, 9, 10, 12, 14, 16, 18, 20, 21)
- メモリ不足で計算時間が増大したようにも見えます
- 結合処理を含む場合(Query1以外)は，データの量に対して, $O(n^2)$ の計算時間を要します
まとめ
- Auroraは，フルマネージドなRDBとして，一定程度のBI(Bussiness Intelligence)処理に効果が得られることが示されました
- EC2上に自分でDBを作るよりも，性能が出そうです
- とは言え，テーブルサイズが大きくなると，（EC2はもちろんauroraでも）計算時間が激増してしまいます
- そもそもRDBで実施するクエリではないとも言えるので，巨大データの結合を含むような処理は，別の方法を考えたほうが良いかもしれません