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

Transcript

1. アーキテクチャから学ぶ 分散SQL「TiDB」 の強み・弱み Yukio
2. 目次 ・分散SQL「TiDB」とは？ ・RDB/TiDBのアーキテクチャ ・RDB/TiDBのデータの持ち方 ・クエリ実行時の挙動 ・TiDBの強み/弱み ・まとめ ・参考資料
3. 分散SQL「TiDB」とは？ ACIDトランザクションをサポートしつつ、更新系を水平スケール可能な次世代の分散 データベース ・👍MySQL互換 ・👍RDBレベルのデータ整合性 (ACID) ・👍参照/更新系の両方を水平スケール可能 ・👍無停止でDBバージョンアップ可能 ・👎レイテンシはやや高まる
4. RDB Architecture 参考「詳説データベース」 , p9, DBMSアーキテクチャ クエリ プロセッサ 実行 エンジン ストレージ エンジン RDB Client ディスク
5. TiDB Architecture https://docs.pingcap.com/ja/tidb/stable/tidb-architecture/
6. RDBのデータの持ち方 (通常時) id 1 … 1000 1001 … 2000 2001 … 3000 users Table Master
7. RDBのデータの持ち方 (データ複製時) id 1 … 1000 1001 … 2000 2001 … 3000 users Table Master Replica 1 Replica 2 複製 複製
8. RDBのデータの持ち方 (データ分割時) id 1 … 1000 1001 … 2000 2001 … 3000 users Table DB 1 DB 2 DB 3
9. 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のデータの持ち方 (データ分割 & 複製が基本系)
10. クエリ実行時の挙動 (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
11. クエリ実行時の挙動 (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
12. クエリ実行時の挙動 (SELECT文) id 1 … 1000 1001 … 2000 ★Leader ★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users WHERE id = 5;
13. クエリ実行時の挙動 (SELECT文) id 1 … 1000 1001 … 2000 ★Leader ★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users WHERE id = 1005;
14. クエリ実行時の挙動 (SELECT文) id 1 … 1000 1001 … 2000 ★Leader ★Leader users Table TiKV Node A TiKV Node B ① SELECT * FROM users
15. TiDBの強み (1) 分散システムならではの強み ・水平スケーラビリティ ・ローリングアップデートによるゼロダウンタイムでのDBバージョンアップ
16. TiDBの強み (2) レコードのバージョン管理を元にした機能 ・タイムトラベルクエリ SELECT ... FROM ... AS OF $(timestamp) ・DROPしたオブジェクト(Table / Database)のFLASHBACK FLASHBACK DATABASE $(db_name)
17. TiDBの強み (3) 柔軟なリソース制御機能 https://infcurion-jira.atlassian.net/wiki/spaces/ABNI/pages/789415153/Wallet+Station
18. TiDBの強み (4) インデックス断片化の解消が不要 イミュータブルなデータ構造(LSM Tree)をインデックスとして利用することでディスク断片 化の発生を抑えている https://tikv.org/docs/4.0/tasks/configure/titan/
19. TiDBの弱み (1) ミリ秒レベルでのレイテンシ増 id 1 … 1000 1001 … 2000 ★Leader ★Leader users Table TiKV Node A TiKV Node B SELECT * FROM users
20. TiDBの弱み (2) 外部キー制約利用時の性能問題 https://tech-blog.tokyo-gas.co.jp/entry/2025/02/26/123110 参照制約を指定している子テーブルにレコードを挿入すると、親テーブルの排他ロッ クを取り合うことになり、ロック待ち状態が発生 子テーブル 親テーブル
21. 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);
22. まとめ ・TiDBでは、RDBの各モジュールを複数のマシンに分散させることでスループットを向上させている ・分散体制を取ることでローリングアップデートを可能にし、メンテナンス時の他処理への影響を抑えてい る ・分散システム特有の課題は TiDBにおいても存在する (レイテンシ増加、ホットスポット問題 ) ・マルチプロダクト、マルチテナントプロダクトである弊社製品に一定有用な DB
23. 参考書籍 ・TiDB実践入門 (easy) ・データ指向アプリケーションデザイン (hard) ・詳説データベース (hard)
24. 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