検証前に基本アーキテクチャーの理解から
分散データベース、NewSQL、可用性、柔軟性、伸縮性。。。
TiDBを表現するこれらのキーワードを並べても、ピント来ませんね。
知りたいのは、可用性ならMySQL Clusterなどあるのに、なぜTiDB?
TiDBのアーキテクチャー
※ PingCAP社のドキュメントから引用(https://docs.pingcap.com/tidb/stable/tidb-architecture)
いくつかコンポーネントから構成されているようです。
TiDBクラスタを構成するTiDBサーバ
外部からのSQLリクエスト(MySQLプロトコル)を受け付ける部品で、スケールアウト可能。
SQL解析、最適化、分散実行計画の生成をここでやっているイメージか。
PD(Placement Driver)クラスタを構成するPDサーバ
ここが司令塔のようで、メタデータを管理し、クラスタ全般(TiDBクラスタ、Storageクラスタなど)を司っている。
PDサーバは可用性を持ち、少なくとも3ノード必要、ノード数は奇数が良い(Apache Zookeeperの匂いが)
Storageクラスタを構成するStorageサーバ
２種類のサーバがあるようです。
TiKVサーバ
データ保存用で、分散キーバリューストアエンジン。
データ保存単位はRegionで、一つのTiKVノードに複数存在する。
分離レベルは、スナップショット分離をサポートし、これがTiDBがSQLレベルで分散トランザクションをサポート可能な要因となる。
TiKVに格納されたデータは、複数レプリカにより自動メンテされる(デフォルトはレプリカ三つ)。
ネイティブの高可用性を持ち、自動フェールオーバーも可能か。
TiFlashサーバ
特殊ストレージで、データを列指向(カラムナー)で保存し、主に分析処理を加速するために使用される。
終わりに
一旦、アーキテクチャと用語は抑えておきました。
各コンポーネントの機能と特徴もなんとなく理解できました。
次回は検証に入りたいと思います、お楽しみに。