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.2k
#CloudNativeDB NewSQLへの誘い
tzkoba
4
3.2k
2020年DBプラットフォーム (超個人的)5大ニュース
tzkoba
0
1.1k
PostgreSQLプラットフォームの徹底比較(コンテナからクラウドまで)
tzkoba
6
10k
Kubernetesでストレージ?そもそも何に使えるの?
tzkoba
0
1.2k
データ損失を回避しよう 各DBの機能比較
tzkoba
3
1.9k
昨今のデータデバイス(アーカイブ編)
tzkoba
3
1.6k
理解して拡げる分散システムの基礎知識
tzkoba
21
11k
NewSQL その成り立ちとモチベーション
tzkoba
13
6.2k
Other Decks in Technology
See All in Technology
IAMポリシーのAllow/Denyについて、改めて理解する
smt7174
2
180
OPENLOGI Company Profile
hr01
0
60k
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
330
OpenID BizDay#17 KYC WG活動報告(法人) / 20250219-BizDay17-KYC-legalidentity
oidfj
0
450
一度 Expo の採用を断念したけど、 再度 Expo の導入を検討している話
ichiki1023
1
250
遷移の高速化 ヤフートップの試行錯誤
narirou
5
840
The Future of SEO: The Impact of AI on Search
badams
0
260
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
200
JEDAI Meetup! Databricks AI/BI概要
databricksjapan
0
300
ExaDB-XSで利用されているExadata Exascaleについて
oracle4engineer
PRO
3
150
OPENLOGI Company Profile for engineer
hr01
1
20k
AIエージェント入門
minorun365
PRO
7
2.7k
Featured
See All Featured
The Invisible Side of Design
smashingmag
299
50k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
570
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
500
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Fireside Chat
paigeccino
34
3.2k
Building Adaptive Systems
keathley
40
2.4k
Optimizing for Happiness
mojombo
376
70k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
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