# テーブルの行とキーバリューマッピング

+ KEYのパターンは**`tablePrefix{TableID}_recordPrefixSep{RowID}`**です
+ テーブルデータをキーバリューにマッピングします
+ TiKVは広範囲のソートされたキーバリューマップをホストします

```10
1, "TiDB", "SQL Layer", 10: ~!@t10_r1@!~ --> ["TiDB", "SQL Layer", 10]
2, "TiKV", "KV Engine", 20: ~!@t10_r2@!~ --> ["TiKV", "KV Engine", 20]
3, "PD", "Manager", 30: ~!@t10_r3@!~ --> ["PD", "Manager", 30]
```
-------------------------------------------------------------
TiKVによって提供される分散ストレージ容量に基づいて、TiDBは優れたトランザクション処理能力と優れたデータ分析能力を組み合わせた計算エンジンを構築します。この記事では、まずデータマッピングアルゴリズムからTiKV内の(Key, Value)キーバリュー形式へのライブラリテーブルのデータのマッピング方法を紹介し、次にTiDBのメタデータ管理方法を説明し、最後にTiDB SQLレイヤーの主要なアーキテクチャを紹介します。

リレーショナルデータベースでは、テーブルには多数のカラムがある場合があります。行のデータの各カラムを(Key, Value) キー・バリューのペアにマップするために、キーの構築方法を検討する必要があります。まず、OLTPシナリオでは、単一または複数の行を追加、削除、変更、確認するなどの多数の操作があります。これらの操作は、データベースが迅速に1行のデータを読み取る能力を持っている必要があります。そのため、迅速な位置決めを容易にするために、対応するキーには一意のID (明示的または暗黙のもの) を持たせると最適です。2つ目に、多くのOLAP型のクエリは、完全なテーブルスキャンを必要とします。テーブル内のすべての行のキーを1つの範囲にエンコードできれば、範囲クエリで全テーブルスキャンのタスクを効率的に完了できます。

  - 同じテーブルのデータを一緒に配置し、検索しやすくするために、TiDBは各テーブルにTableIDとして表IDを割り当てます。表IDは、クラスタ全体でユニークな整数です。
  - TiDBは、テーブル内の各データの行にrowIDとして表される行IDを割り当てます。行IDも整数であり、テーブル内で一意です。行IDについて、TiDBは小さな最適化を行っています。テーブルにint primary keyがある場合、TiDBは行データのrowIDとしてprimary keyの値を使用します。

以下のルールに従って、データの各行は(Key, Value)キー・バリュー・ペアにエンコードされます。
  キー: `tablePrefix{TableID}_recordPrefixSep{RowID}`は、データベース内のテーブルの一意のIDです。
  値:   `[col1, col2, col3, col4]`です。
  
注意: このスライドは、テーブル行のマッピングパターンを示しています。索引はやや異なる方法で格納されます。