#CloudNativeDB NewSQLへの誘い

2021/7/16にCloud Native Database Meetup#1の発表資料です。

Transcript

1. NewSQLへの誘い Cloud Native Database Meetup #1 , 2021/7/16 こば( @tzkb）
2. 6 最近やっていること • 色んなDBをつまみぐい、@ITで連載中
3. 7 1. そもそもNewSQLとは？ 2. ストレージエンジンの観点から 3. 分散トランザクションの観点から 4. 更に詳しく知りたい方へ アジェンダ
4. 8 そもそもNewSQLとは？ 1
5. 9 NewSQLへの流れ • 2000年代初め、DBはプロプライエタリのみでOSSは無かった。 単一ノードで稼働、垂直スケールのみ。 • 2000年代後半、NoSQLが勃興。高い可用性と拡張性を併せ持つ。 リレーショナルではなく、ACID txも保証されないものが多かった。 • 2011年のAslett ReportでNewSQLの用語が登場、NoSQLの ような拡張性と柔軟性を持ち、SQLとACID txをサポート。
6. 10 Spannerの登場 • Spanner: Google’s Globally Distributed Database(2012) を発表。 • SQL準拠、ACIDトランザクションをサポート。 • 地理分散（例：東京ー大阪ーソウル）が可能な、分散SQLデータベース。 • 従来のRDBが弱いとされた、Writeもスケールアウトが可能。
7. 11 NewSQL市場の転換と拡大 • 2011年頃のNewSQLは、Spannerとは異なるアーキテクチャ。 • VoltDBやNuoDBなど、NoSQLが解決できなかった課題（マルチマスタ・ スケールアウト型のRDB）の解決を目指していた。 • そして、Google Cloud Spanner以降、類似実装のOSSが誕生する。 • その特徴は、 • 強い整合性を持ち、 • ACIDトランザクションをサポートする、 • 地球規模に展開可能な、分散SQLデータベース
8. 12 ストレージエンジンの観点から 2
9. 13 一般的なRDBMSのコンポーネント パーサー オプティマイザ エグゼキュータ― トランザクション マネージャ ロック マネージャ アクセスメソッド バッファ マネージャ リカバリ マネージャ ← SQL文を構文解析して、 ← 実行計画(プランツリー)をつくり、 ← プランツリーに沿ってクエリを実行する ← この辺をストレージエンジンと言ったりする。 ← データ管理の中心的役割を果たす。
10. 14 ストレージエンジンも時代とともに変わる • B+Tree：RDBMSで長年使われてきたストレージ構造 上書き型のデータ構造で、Read Amplificationを抑制できたが、Writeや Spaceの効率が良いとは言えない。 • LSM-Tree：Immutableでシーケンシャルな書き込みを行う構造 Write/Space Amplificationを抑えるストレージ構造として、RDBMSでも採 用されつつある。例：MyRocks、Cloud Spanner、TiDB等 【B+Tree】 【LSM-Tree】 merge merge
11. 15 ストレージエンジンの特性を理解する • ストレージエンジンを比較する際に、Read/Write/Spaceの観点が重要。 • 3つ全てを達成することは難しいため、どこかを諦める必要が生じる。 【特徴】 • TiDB（TiKV）、CockroachDBでは を利用している。 • YugaByteDBは独自開発のDocDBを用いる。 • なお、CockroachDBは独自ストレージエンジン（Pebble）への転換を進めて おり、このレイヤでの競争が激化している。 Read Efficiency Wrire Efficiency Space Efficiency B+Tree Best LSM Tree(Leveled) Best LSM Tree(Tiered) Best
12. 16 NoSQLでの変化はNewSQLにも • どんな高度な分散データベースも、データはノードローカルなストレージに 貯められるケースが多い。 • 従来のRDBMSではReadが優先され、B+Treeのストレージ構造を使ってきた。 • CassandraなどのNoSQLを中心に、LSM-Treeの構造が使われることが 増えてきた。これはWriteに強く、今主流のSSDとの相性も良い。 • そうした背景から、大規模にスケールアウトさせるNewSQLも、LSM-Treeを 採用しつつある。圧縮が効くため、Space効率でも有利。 • CockroachDBやTiDBでもLSM-Treeの実装（RocksDBやPebble）を 使っている。
13. 17 分散トランザクションの観点から 3
14. 18 ノード② ノード① ノード① 分散データベースの課題 • 可用性または拡張性を求めて、データベースを分散すると始まる トランザクションとの戦い。 Write A Write B Read C Read B Read A 【シングルノードの場合】 【マルチノードの場合】 Write A Write B Read C Read B Read A トランザクションを順序通りに 並べることは簡単。 ノード間の時刻は厳密には一致しない。 トランザクションを時系列で並べることが難しい。 他ノードをブロックすれば直列化できるが、スケールしない。
15. 19 （参考）シングルリーダーなら簡単 • マルチノードであっても、ReadもWriteも単一のリーダーが行う構成ならば、 トランザクションの問題は解決可能。 • しかし、リーダーがボトルネックとなるため、拡張性が十分でない。 【PostgreSQLのReplication】 【Amazon Aurora】 Compute SQL Caching Compute SQL Caching Storage Storage Storage P R P R R
16. 20 Raftと単一パーティションの更新 Write Read • データをパーティション化してマルチリーダーに、それぞれの レプリカをRaft(合意プロトコル)を用いて同期する。 【Write Path 】 ①WriteはLeaderに送られ、Leaderのlogに 更新内容が記録される。 ②全てのFollowerにlogを複製。 ③Followerの過半数から複製済の応答が返る。 ④Leaderは更新をコミット。 【Read Path 】 ①Readも原則はLeaderへ送られる。 ②LeaderはFollowerへハートビートを送信し、 過半数からの応答を待つ。 ③自身がLeaderあることが確認できたので、 Read結果を返す。 Follower3 Follower2 Leader1 Leader3 Follower2 Follower1 Follower3 Leader2 Follower1
17. 22 更に詳しく知りたい方へ 4
18. 23 （宣伝です）NewSQLを学ぶなら！ • 先ほどの図は単一パーティションのWrite/Readだったが、現実で は複数パーティションを1TxでWriteすることも多い。 • じゃ、2フェーズコミット？色々むずかしいよね、、、 • そんなあなたに！ • 第Ⅰ部 ストレージエンジン • 第Ⅱ部 分散システム ※電子版はオライリーのサイトから
19. 26 Questions? @tzkb @tzkoba