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
アーキテクチャから学ぶ分散SQL TiDB の強み・弱み
Search
Yukio
August 17, 2025
Programming
0
4
アーキテクチャから学ぶ分散SQL TiDB の強み・弱み
Yukio
August 17, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
CSC305 Lecture 06
javiergs
PRO
0
270
釣り地図SNSにおける有料機能の実装
nokonoko1203
0
200
Catch Up: Go Style Guide Update
andpad
0
240
フロントエンド開発のためのブラウザ組み込みAI入門
masashi
7
3.4k
ALL CODE BASE ARE BELONG TO STUDY
uzulla
27
6.6k
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
590
React Nativeならぬ"Vue Native"が実現するかも?_新世代マルチプラットフォーム開発フレームワークのLynxとLynxのVue.js対応を追ってみよう_Vue Lynx
yut0naga1_fa
2
320
20251016_Rails News ~Rails 8.1の足音を聴く~
morimorihoge
3
690
開発組織の戦略的な役割と 設計スキル向上の効果
masuda220
PRO
8
1.4k
Claude Agent SDK を使ってみよう
hyshu
0
1.4k
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
620
Flutterで分数(Fraction)を表示する方法
koukimiura
0
140
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Designing for Performance
lara
610
69k
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
BBQ
matthewcrist
89
9.8k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
For a Future-Friendly Web
brad_frost
180
10k
Transcript
アーキテクチャから学ぶ 分散SQL「TiDB」 の強み・弱み Yukio
目次 ・分散SQL「TiDB」とは? ・RDB/TiDBのアーキテクチャ ・RDB/TiDBのデータの持ち方 ・クエリ実行時の挙動 ・TiDBの強み/弱み ・まとめ ・参考資料
分散SQL「TiDB」とは? ACIDトランザクションをサポートしつつ、更新系を水平スケール可能な次世代の分散 データベース ・👍MySQL互換 ・👍RDBレベルのデータ整合性 (ACID) ・👍参照/更新系の両方を水平スケール可能 ・👍無停止でDBバージョンアップ可能 ・👎レイテンシはやや高まる
RDB Architecture 参考「詳説データベース」 , p9, DBMSアーキテクチャ クエリ プロセッサ 実行 エンジン
ストレージ エンジン RDB Client ディスク
TiDB Architecture https://docs.pingcap.com/ja/tidb/stable/tidb-architecture/
RDBのデータの持ち方 (通常時) id 1 … 1000 1001 … 2000 2001
… 3000 users Table Master
RDBのデータの持ち方 (データ複製時) id 1 … 1000 1001 … 2000 2001
… 3000 users Table Master Replica 1 Replica 2 複製 複製
RDBのデータの持ち方 (データ分割時) id 1 … 1000 1001 … 2000 2001
… 3000 users Table DB 1 DB 2 DB 3
id 1 … 1000 1001 … 2000 2001 … 3000
★Leader users Table TiKV Node A Follower ★Leader TiKV Node B Follower Follower Follower TiKV Node C ★Leader Follower TiKV Node D Follower TiDBのデータの持ち方 (データ分割 & 複製が基本系)
クエリ実行時の挙動 (INSERT文) id 1 … 1000 1001 … 2000 ★Leader
★Leader users Table TiKV Node A TiKV Node B ① INSERT users (id) VALUES (5); ②log replication ③commit ③commit
クエリ実行時の挙動 (INSERT文) id 1 … 1000 1001 … 2000 ★Leader
★Leader users Table TiKV Node A TiKV Node B ① INSERT users (id) VALUES (1005); ②log replication ③commit ③commit
クエリ実行時の挙動 (SELECT文) id 1 … 1000 1001 … 2000 ★Leader
★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users WHERE id = 5;
クエリ実行時の挙動 (SELECT文) id 1 … 1000 1001 … 2000 ★Leader
★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users WHERE id = 1005;
クエリ実行時の挙動 (SELECT文) id 1 … 1000 1001 … 2000 ★Leader
★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users
TiDBの強み (1) 分散システムならではの強み ・水平スケーラビリティ ・ローリングアップデートによるゼロダウンタイムでのDBバージョンアップ
TiDBの強み (2) レコードのバージョン管理を元にした機能 ・タイムトラベルクエリ SELECT ... FROM ... AS OF
$(timestamp) ・DROPしたオブジェクト(Table / Database)のFLASHBACK FLASHBACK DATABASE $(db_name)
TiDBの強み (3) 柔軟なリソース制御機能 https://infcurion-jira.atlassian.net/wiki/spaces/ABNI/pages/789415153/Wallet+Station
TiDBの強み (4) インデックス断片化の解消が不要 イミュータブルなデータ構造(LSM Tree)をインデックスとして利用することでディスク断片 化の発生を抑えている https://tikv.org/docs/4.0/tasks/configure/titan/
TiDBの弱み (1) ミリ秒レベルでのレイテンシ増 id 1 … 1000 1001 … 2000
★Leader ★Leader users Table TiKV Node A TiKV Node B SELECT * FROM users
TiDBの弱み (2) 外部キー制約利用時の性能問題 https://tech-blog.tokyo-gas.co.jp/entry/2025/02/26/123110 参照制約を指定している子テーブルにレコードを挿入すると、親テーブルの排他ロッ クを取り合うことになり、ロック待ち状態が発生 子テーブル 親テーブル
TiDBの弱み (3) オートインクリメント時のホットスポット問題 id 1 … 1000 1001 … 2000
★Leader ★Leader users Table TiKV Node A TiKV Node B INSERT users (id) VALUES (5); INSERT users (id) VALUES (6);
まとめ ・TiDBでは、RDBの各モジュールを複数のマシンに分散させることでスループットを向上させている ・分散体制を取ることでローリングアップデートを可能にし、メンテナンス時の他処理への影響を抑えてい る ・分散システム特有の課題は TiDBにおいても存在する (レイテンシ増加、ホットスポット問題 ) ・マルチプロダクト、マルチテナントプロダクトである弊社製品に一定有用な DB
参考書籍 ・TiDB実践入門 (easy) ・データ指向アプリケーションデザイン (hard) ・詳説データベース (hard)
Q 「テナントごとにDBインスタンスを作成するインスタンス分離した DBを1つのTiDBクラスタで管理する場合 データの持ち方はどうなるのか? 」 A. MySQLではDatabaseはSQL ServerでいうところのSchemaに相当します。 TiDBクラスタで複数DBを運用する際は、テナントごとに Schema(Database)を作成し、そこにテーブルデータを
作成していくことを想定しています。 したがって、論理的には Databaseごとにデータは別れますが、 物理的なデータ配置としては同じ TiKVノードに 別々のテナントのデータが同居する可能性 があります。 ★ t1.users TiKV Node A t1.users ★t2.users TiKV Node B t3.users t1.users t2.users TiKV Node C ★t3.users t2.users TiKV Node D t3.users