Closed14
TiDB ワークショップ １日目
あおしょんTiDB アーキテクチャ
- TiFlashはオプションなので無くても動く
- MySQLのコードは使ってないけどMySQLのプロトコルを使っている
- MySQLの脆弱性は関係ない
- TiDB Serverはフロント
- TiKV Serverがストレージを担当している。ストレージを明確にサーバを分けている。こいつが心臓部分である。
あおしょんTiDB サーバー
- MySQLプロトコルの解釈
- コネクションの管理
- SQLを受け付けてKVストアのAPIに変換が重要な仕事
あおしょんTiKV サーバー
- ただの（？）KVストア
- 複数のノードそれぞれで一貫して実行できるトランザクションを担保
- 範囲検索や集計演算を独自で実装している。ストレージに近いところで出来る工夫がされている
- DBのほとんどの機能が実装されている
あおしょんPlacement Driver (PD )
- どのデータがどこのサーバに保存されているか管理している
- PDサーバ自体もメタデータ保存用のDBを持っている
- 実態はetcdほぼそのまま。etcdのAPIでアクセスできる
- 特定の行にアクセス集中した時にデータを適切に分割するスケジューリングしている
- TiDBダッシュボードはOSS版で見ること出来る
あおしょんTiFlash サーバー
- 列指向ストレージエンジン
- 列指向を同じクラスター上に持つことができる
- 行指向と列指向を入れる目的
- ETLをなくす
- データの鮮度
- 複雑なクエリに対してそれぞれ適切な方からデータを引く。インデックス効く効かないとかで場合分け
- デメリットはお金がかかる（２倍以上？？）
あおしょんTiDB サーバーの主な機能
- メモリの使い方がMySQLと異なる。そもそもキャッシュを使ってない。他のコンポーネントとネットワーク通信しないとだから。メタデータのキャッシュしか持ってない。当然レイテンシーに直結する。
- インサート性能を重視して作っている。
- バッファプールみたいなキャッシュのチューニングない
あおしょん関係（リレーショナル）データと KV変換
- TiDBのリージョンはデータの塊のことを指している
- LeaderノードとFollowerノードがある。データ処理が単一ノードに集中しないようにリージョンごとにLeaderノードを割り振る。
- リージョンは96MBごと
あおしょんオンライン DDL 関連モジュール
- TiDB ServerのworkersがTiKV Serverの想いJob Queue, 軽いIndex Queueを処理してる。
あおしょんGC メカニズムおよび関連モジュール
- TiDBのGCはTiKB Serverのディスクに対してやってる
- TiDB ServerはGCの指示をしている
- GCをやるためのLeaderを選出している
あおしょんTIDB サーバーキャッシュ
- ユーザー利用ではなく内部のキャッシュ
- でかいクエリ流すとoom起こしやすい
あおしょんキャッシュテーブル
- TiKV ServerのテーブルをTiDB Serverでキャッシュする
- ユーザーが明示的に実行する
あおしょんRocksDB
- Facebookが出しているKVDB
- イミュータブルなBtree
- Twtterのような大量の書き込みに耐えうるためWrite最優先
- DELETEもフラグが立つだけ
- 逆にReadの性能は落ちる
あおしょんRocksDB: 書き込み
- まずDiskに書き込みがあったことを残すためにWALファイルをDiskに書き込む
- メモリー上野MemTableに書き込み、immutable Mem Tableに溜まってくるとFush
- Transaction進むとWALファイルは消される
あおしょんTSOアサインメント：TSOコンセプト
- Googleみたいに原子時計じゃない
- 頭48をepoc
- 残り16をシリアル
このスクラップは2023/10/20にクローズされました