Cloud Native時代の データベース ～ ストレージエンジンと分散トランザクション ～ Infra Study 2nd Season , 6/11 こば( @tzkb）

2 最近やっていること • 色んなDBをつまみぐい、@ITで連載中

3 1. そもそもRDBMSって何？ 2. ストレージエンジンの課題 3. 分散トランザクションの課題 4. Cloud Nativeなデータベースへの歩み アジェンダ

4  Cloud Nativeなデータベースも基本から学べば怖くない。  どうデータを貯めるのか。今のトレンドは？  ストレージエンジンを学ぼう  スケールするためには分散する必要がある。  分散トランザクションを知ろう  何が変わると新データベースになるのか、考えてみよう。 本日のゴール

5 そもそもRDBMSって何？ 1

6 「リレーショナル データベース マネジメント システム」 • リレーショナルモデルに基づくデータベースの実装を指す。 • Oracle DatabaseやSQL Server、そしてPostgreSQL、MySQL などアプリ開発には必須のコンポーネントになっている。 • DB-EnginesではOracleが長年トップもMySQLが迫ってきた。

7 一般的なRDBMSのコンポーネント パーサー オプティマイザ エグゼキュータ― トランザクション マネージャ ロック マネージャ アクセスメソッド バッファ マネージャ リカバリ マネージャ ← SQL文を構文解析して、 ← 実行計画(プランツリー)をつくり、 ← プランツリーに沿ってクエリを実行する ← この辺をストレージエンジンと言ったりする。 ← データ管理の中心的役割を果たす。

8 今日はちょっと細かい話をします ← 簡単にいうと、ノードのデータを上手く管理する 仕組み。最近はプラガブルに。 ← トランザクションを管理し、データの整合性を 保護する ← ディスクアクセスやストレージ構造を管理 ← データをキャッシュしたり、障害時に復旧したり ※この辺読むと実装できるかも？ 【ストレージエンジン】 トランザクション マネージャ ロック マネージャ アクセスメソッド バッファ マネージャ リカバリ マネージャ

9 ノードA ノードB ノードC 分散データベースとは パーサー オプティマイザ エグゼキュータ― トランザクション マネージャ ロック マネージャ アクセスメソッド バッファ マネージャ リカバリ マネージャ パーサー オプティマイザ エグゼキュータ― トランザクション マネージャ ロック マネージャ アクセスメソッド バッファ マネージャ リカバリ マネージャ パーサー オプティマイザ エグゼキュータ― トランザクション マネージャ ロック マネージャ アクセスメソッド バッファ マネージャ リカバリ マネージャ • 先ほどのコンポーネントをノード毎に配置したDBクラスタ。 • 当然、協調動作が必要になる＝難しい。 • ノード毎にデータのバージョンが異なる場合もある。

10 ストレージエンジンの課題 2

11 B+Tree、そしてLSM-Tree • B+Tree：従来のRDBMSで使われてきたストレージ構造 上書き型のデータ構造で、Read Amplificationを抑制できたが、Writeや Spaceの効率が良いとは言えない。 • LSM-Tree：Immutableでシーケンシャルな書き込みを行う構造 Write/Space Amplificationを抑えるストレージ構造として、RDBMSでも採 用されつつある。例：MyRocks、Cloud Spanner、TiDB等 【B+Tree】 【LSM-Tree】 merge merge

12 記録媒体の変化がもたらす影響 • HDDはシークが遅いが、辿れれば一気に読み込み/書き込みが可能。 • SSDはシークがないが、書き込み時にRead-Modify-Writeが必要。 • NVMはより小さな単位のバイトアクセスが可能だが、対応したDBやファイル システムはまだ少ない。 【HDD】 【SSD】 • セクタ単位 • 上書きに強い • B+Treeと相性良い • 大きなブロック単位 • 書き込み回数に制限 • 上書きしないことが重要 • LSM-Treeが注目される

13 MySQLのPMEM最適化への取り組み by Yahoo!さん • 不揮発性メモリ(PMEM)向けに最適化したストレージエンジンLeoを 開発中とのこと。 • 代表的なストレージエンジンであるInnoDBと同様に、トランザクションも サポートする。 • さらにレイテンシを抑えるためにシステムコールも迂回している。 https://techblog.yahoo.co.jp/entry/2020052630002063/ 【ストレージエンジン Leoの構成】

14 ここまでのまとめ • どんな高度な分散データベースも、データはノードローカルなストレージに 貯められるケースが多い。 • 従来のRDBMSでは、HDDを前提として、B+Treeのストレージ構造を使って きた。Readが優先されてきた。 • CassandraなどのNoSQLを中心に、LSM-Treeの構造が使われることが増え てきた。これはWriteに強く、SSDとの相性も良い。 • そうした背景から、大規模にスケールアウトさせるRDBMSも、LSM-Treeを 採用しつつある。圧縮が効くため、Space効率でも有利。 • NVMが一般化すれば、求められるストレージ構造は変わってくるかも。 • こうした見方で、データベースを下(ストレージ)から見ると楽しい。

15 分散トランザクションの課題 3

16 ノード② ノード① ノード① 分散データベースの課題 • 可用性または拡張性を求めて、データベースを分散すると始まる トランザクションとの戦い。 Write A Write B Read C Read B Read A 【シングルノードの場合】 【マルチノードの場合】 Write A Write B Read C Read B Read A トランザクションを順序通りに 並べることは簡単。 ノード間の時刻は厳密には一致しない。 トランザクションを時系列で並べることが難しい。 他ノードをブロックすれば直列化できるが、スケールしない。

17 （参考）シングルリーダーなら出来ること • マルチノードであっても、ReadもWriteも単一のリーダーが行う構成ならば、 トランザクションの問題は解決可能。 • しかし、リーダーがボトルネックとなるため、拡張性が十分でない。 【PostgreSQLのReplication】 【Amazon Aurora】 Compute SQL Caching Compute SQL Caching Storage Storage Storage P R P R R

18 可用性と拡張性を同時に実現するには？ 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

19 （宣伝です）現実はさらに複雑 • 先ほどの図は単一パーティションのWrite/Readだったが、現実で は複数パーティションを1TxでWriteすることも多い。 • じゃ、2フェーズコミット？色々むずかしいよね、、、 • そんなあなたに！ • 第Ⅰ部 ストレージエンジン • 第Ⅱ部 分散システム ※7/6に発売、電子版はオライリーのサイトから

20 Cloud Nativeなデータベースへの歩み 4

21 DBを支える基礎技術の変遷 • LSM-Tree、合意プロトコル(Paxos)、分散トランザクションを組み合わせて、 Google Cloud Spannerは高い可用性と拡張性を持つRDBMSを実現した。 • そして、Cloud Spanner以降、類似実装のOSSクローンが生まれ、 マネージドサービスとしても展開されている。 • その特徴は、 • ACIDトランザクションをサポートし、 • 地理分散を含めた高い可用性を備え、 • スケールアウトが可能な、分散SQLデータベース

22  Cloud Nativeなデータベースも基本から学べば怖くない。  どうデータを貯めるのか。今のトレンドは？  B+TreeからLSM-Treeへ。HDD⇒SSDの変化も影響。  スケールするためには分散する必要がある。  Raftによる冗長化と、最適化された2PCの組み合わせ  何が変わると新データベースになるのか、考えてみよう。 本日のゴール：答え合わせ NVMなどの新技術がCloud Nativeなデータベースで どう使われるか。これからもウォッチしよう。

23 Questions? @tzkb @tzkoba