Cloud Native時代のデータベース

2021/6/11 #InfraStudy 2nd Season

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. 5
   そもそもRDBMSって何？
   1
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

23. 23
    Questions?
    @tzkb
    @tzkoba
    

    View Slide