アーキテクチャから学ぶ分散SQL TiDB の強み・弱み

アーキテクチャから学ぶ分散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;

★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users WHERE id = 1005;

★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) 柔軟なリソース制御機能

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

アーキテクチャから学ぶ分散SQL TiDB の強み・弱み

アーキテクチャから学ぶ分散SQL TiDB の強み・弱み

Yukio

Other Decks in Programming

Featured

Transcript