# KV とストレージ

__*Multi Raft Group*__
__*TiKV Region*__
__*RocksDB*__

![`smart`](./student-guide/diagram/TiKVRegionAndStorage_aa_001_20221005.png)

+ `KV`
+ `Region`
+ `Raft Group`
+ `RocksDB`

-------------------------------------------------------------
- データストレージシステムとして最初に決定するべきことは、データのストレージモデルすなわち、データがどの形式で保存されるかです。TiKVを選択することは、キー/値モデルを提供し、順序付けられた走査方法を提供します。

- TiKVデータストレージの2つの重要なポイント：
  - これは巨大なマップです（C++のstd::mapに対する類推）、つまり、キー-バリューペア（キー-バリューペア）が格納されています。
  - このMap内のキー＆バリューのペアは、キーのバイナリ順序に従って並べられています。つまり、キーの位置にシークし、次のメソッドを連続的に呼び出すことで、このキー以上のキー・バリューを昇順に取得できます。

- ストレージの水平拡張を実装するために、データは複数のマシンに分散されます。TiKVは、キーの範囲に従って、全体のキー・バリュー空間を多くのセグメントに分割します。各セグメントは、連続した複数のキーのシリーズであり、各セグメントはリージョンと呼ばれ、それぞれのリージョンに格納されたデータがある程度のサイズを超えないようにします。現在、TiKVのデフォルトは96MBです。各リージョンは[startKey、endKey）として記述され、左側が閉じられ、右側が開いた区間となります。データをリージョンに分割した後、TiKVは2つの重要なことを行います。リージョンの単位でクラスタ内の全ノードにデータを分散し、各ノードでサービスされるリージョン数がほぼ同じになるようにします。また、リージョンごとにRaftレプリケーションとメンバー管理を行います。

- あらゆる永続的なストレージエンジンにおいて、最終的にはデータはディスク上に保存されます。そしてTiKVも例外ではありません。しかしTiKVはデータを直接ディスクに書き込むことはせず、RocksDBにデータを保存し、RocksDBが具体的なデータの保存に責任を持っています。この選択をする理由は、単一インスタンスのストレージエンジンを開発することは多大な労力がかかり、特に高パフォーマンスな単一インスタンスのエンジンを実現するには、慎重な最適化が必要であるためです。Facebookによってオープンソース化された、非常に優れた単一インスタンスのKVストレージエンジンであるRocksDBは、TiKVが単一インスタンスのエンジンに対するさまざまな要件を満たすことができます。ここではRocksDBを、スタンドアロンの永続的なキー&値のマップとして考えることができます。

- 次に、TiKVの実装はより困難な課題に直面しています：単一のインスタンスの障害が発生した場合にデータが失われないように、またはエラーがないようにする方法は何ですか？

- 簡単に言えば、複数のマシンにデータを複製する方法を見つける必要があります。これにより、1台のマシンがサービスを終了しても、他のマシンのレプリカがサービスを提供し続けることができます。複雑な場合、このデータレプリケーションソリューションは信頼性が高く、効率的であり、レプリカの失敗を処理できる必要があります。TiKVはRaftアルゴリズムを選択しました。Raftは一貫性プロトコルです。この記事ではRaftの簡単な紹介のみを行います。詳細については論文を参照してください。Raftには、Leadersの選出、メンバー変更（レプリカの追加、レプリカの削除、Leadersの転送など）、ログのレプリケーションなど、いくつかの重要な機能があります。

- TiKVはデータレプリケーションにRaftを使用しています。 すべてのデータ変更はRaftログに配置されます。 Raftのログレプリケーション機能を介して、データは安全かつ信頼性の高い方法でレプリケーショングループの各ノードに同期されます。 ただし、実際の書き込みでは、Raftのプロトコルに従って、最も多くのノードに同期的にレプリケートするだけで、データが正常に書き込まれたと推定できます。