Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Cloud Native時代のデータベース
Search
tzkoba
June 11, 2021
Technology
13
15k
Cloud Native時代のデータベース
2021/6/11 #InfraStudy 2nd Season
tzkoba
June 11, 2021
Tweet
Share
More Decks by tzkoba
See All by tzkoba
The State of Distibuted Database In Japan
tzkoba
1
1.3k
#CloudNativeDB NewSQLへの誘い
tzkoba
4
3.3k
2020年DBプラットフォーム (超個人的)5大ニュース
tzkoba
0
1.2k
PostgreSQLプラットフォームの徹底比較(コンテナからクラウドまで)
tzkoba
6
11k
Kubernetesでストレージ?そもそも何に使えるの?
tzkoba
0
1.2k
データ損失を回避しよう 各DBの機能比較
tzkoba
3
2k
昨今のデータデバイス(アーカイブ編)
tzkoba
3
1.6k
理解して拡げる分散システムの基礎知識
tzkoba
21
11k
NewSQL その成り立ちとモチベーション
tzkoba
13
6.3k
Other Decks in Technology
See All in Technology
ソフトウェアテストのAI活用_ver1.20
fumisuke
0
230
エンジニア採用から始まる技術広報と組織づくり/202506lt
nishiuma
8
1.4k
New Cache Hierarchy for Container Images and OCI Artifacts in Kubernetes Clusters using Containerd / KubeCon + CloudNativeCon Japan
pfn
PRO
0
120
ai bot got sick (abc 2025s version)
kojira
0
150
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.6k
Agent Development Kit によるエージェント開発入門
enakai00
19
2.8k
開発効率と信頼性を両立する Ubieのプラットフォームエンジニアリング
teru0x1
0
110
AI Engineering Summit Pre Event LT #10
okaru
2
500
Introduction to Bill One Development Engineer
sansan33
PRO
0
240
Introduction to Sansan Meishi Maker Development Engineer
sansan33
PRO
0
270
Tensix Core アーキテクチャ解説
tenstorrent_japan
0
280
大手企業のAIツール導入の壁を越えて:サイバーエージェントのCursor活用戦略
gunta
34
19k
Featured
See All Featured
Become a Pro
speakerdeck
PRO
28
5.4k
Music & Morning Musume
bryan
46
6.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.4k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Making the Leap to Tech Lead
cromwellryan
134
9.3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Optimizing for Happiness
mojombo
379
70k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
Gamification - CAS2011
davidbonilla
81
5.3k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Rails Girls Zürich Keynote
gr2m
94
13k
Transcript
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