Closed14

TiDB ワークショップ 1日目

あおしょんあおしょん

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をなくす
    • データの鮮度
  • 複雑なクエリに対してそれぞれ適切な方からデータを引く。インデックス効く効かないとかで場合分け
  • デメリットはお金がかかる(2倍以上??)
あおしょんあおしょん

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にクローズされました