【勉強会メモ】第9回 関西DB勉強会
- 日時:2018/10/13(土) 13:00 〜 18:00
- 場所:Insight Technology 大阪支店
※途中から参加しました。
Amazon Aurora Deep Dive
AWSジャパン 藤原 吉規さん
リージョンとAZ(アベイラビリティゾーン)について
- 東京リージョンは4つのAZ(データセンターを4つの区域に分けて分散化)
特徴
- データベースをクラウドで利用
- ハイエンドデータベースのような性能と可用性
- OSSデータベースのようなシンプルとコスト効率
- MySQL 5.6,5.7/PostgreSQL 9.6,10
価格
- MIN:db.t2.small/$0.063
- MAX:db.r4.16xlarge/64cpu/488/$11.20
https://aws.amazon.com/jp/rds/aurora/pricing/
特徴
スケールアウト、分散、マルチテナントデザイン
ログストラクチャードストレージ
- もともとのMySQLやPGに変更を加えている
- マルチテナント
- 3つのAZに分散(データセンターまたがってデータ保持)
- AZに2つずつ計6つのデータをコピーを保持
マスターとレプリカが同じストレージを参照
Lambda
- S3
- IAM
CloudWatch
完全に管理されたサービス - 運用管理作業の自動化
AWS管理でアプリケーションの最適化に集中
- 自動化された管理タスク
なぜAuroraに移行?
- オープンソースエンジンを使っている
- より高いパフォーマンス
- 優れた可用性と耐久性
- コスト最大60%減
- 簡単な以降
- より高いパフォーマンス
- コマーシャルDBエンジンからの移行
- 1/10のコスト
Auroraのパフォーマンス
- MySQL
- スループット5倍
- PostgreSQL
- sysbenchで30GBの書き込み測定
- 2.x倍の処理速度
- 5倍のクライアント数
- 応答時間の削減⇒2倍超
書き込み中クラッシュからの復旧
- PostgreSQL⇒30BiB Redo/123秒
- Aurora⇒3秒で復旧
Real-life data
- リードレプリカレイテンシ
- 通常のMySQL遅延が12分
- Auroraのレプリカ遅延は20ミリ秒
Auroraの耐久性と可用性
- 3つのAZに計6つのコピー
- 最大15の読み取りレプリカが利用・昇格可能
Aurora Driver
最大64TBのストレージ
- 自動ストレージスケーリング
- 10GB単位で自動増分
高速なデータベースクローニング
- 重複したストレージのコストを伴わずにデータベースのコピーを作成
- 元のデータとクローン後のデータが異なる書き込みのみ作成する
バックトラック
- 時間を指定して特定の時点に戻る
- バックアップからの復元ではない
セキュリティとコンプライアンス
- 暗号化
- SSL接続
- 監査ログ
移行
マイグレーション:AWS Database Migration Service(DMS)
- 移行時にアプリケーションの動作を維持
- EC2またはRDSが複製先/元である必要がある(オンプレは不可)
- Schema Conversion Tool
- RDS DBインスタンスからAurora Read Replicaを作成
- MySQLナップショットバックアップから移行
- mysqldumpから移行の約20倍高速
Auroraの新機能
- Parallel Query
- 数千個のCPUを使用
- CPU課金されない
- Serverless
- 自動スケール
- Performance insights
- クエリレベルでパフォーマンスをモニタ
- Hour,day,week,month
- 35日前まで表示
今秋リリース予定のPostgreSQL 11を徹底解説
日本PostgreSQLユーザ会 澤田 雅彦さん
www.slideshare.net
PostgresSQL 11
- 150の新機能・改善
- 約300のコントリビューター
テーブル・パーティショニング
- 全150件中約1割がテーブル・パーティショニングの改善
- Partition Pruning高速化
- 小テーブルの刈り取り/絞り込み
- 大量の小テーブルがある場合に性能向上が期待できる
- 実行中のPartition pruning
- 実行計画作成時には小テーブルを絞り込めない場合に有用
- Prepared Statement
- 実行計画作成時には小テーブルを絞り込めない場合に有用
- Hash Partition
- キーのHash値に基づいてデータを配分
- データが均等になる
- Default Partition
- その他を入れる子テーブル
- Partition-wise Join,Aggregation
- 子テーブルごとに結合、集約を行う
- デフォルトではOFF
- パーティションが多いとプランニングに時間がかかる
できないこと
- パーティション・テーブルへの外部キー制約は未サポート
パラレルクエリ
- 1つのSQLを複数のCPUで実行
- ブロック単位でパラレル
- デフォルトON
- ブロック度が3倍になると処理並列が1つ増える
サポートされた機能
- SQL
- CREATE INDEX
- UNION
- CREATE TABLE AS, SELECT INTO, CREATE MATERIALIZED VIEW
- LIMIT
- ノード
- Hash Join
- Append
- 読み込みが並列化⇒書き込みはまだ
max_parallel_xxxパラメータ
- 上限値の設定
- workers
- workers_per_gather
- maintenance_worker
- 実際の並列数はデータ量等で自動的に使われる
- 個別の並列度の指定はテーブルごとに指定できる
Parallel Append
- UNIONやパーティションテーブルへのスキャンで使われる
- スキャン結果をあわせる処理
- それぞれのworkerが各プランを並列で実行する
パラレルできないこと
- CTE
- VACUUM
- Window関数
JITコンパイル
- CPUネックになるような処理で有効
- ExplainにJITの情報が出る
PROCEDURE
- 戻り値のない関数のようなもの
- ネストしたトランザクション制御
後半の発表に関連するMySQL8.0の新機能の話
Oracle 山﨑 由章( @yyamasaki1 ) さん
MySQL8.0を使ってブロックチェーンを実装する
森崎雅之( @masayuki14 ) さん
https://speakerdeck.com/masayuki14/mysql8-dot-0woshi-tuteburotukutienwoshi-zhuang-suru
使っているもの
- 分散型ネットワーク
- 合意形成
- スマートコントラクト
データ構造の部分だけにフォーカス
- ブロック⇒Record
- チェーン⇒Table
- ハッシュ⇒MD5
- ハッシュ制約⇒戦闘に0が4つ連続
CTE共通テーブル式
- 8.0でサポート
- 再帰的にJOINが実行できる
JSON_TABLE()
- 8.0で新規追加
- JSONを表に変換できる
- 他のテーブルとJHOINできる
まとめ