Merge pull request pingcap#3 from iosmanthus/iosmanthus/keyspace_rfc

rfc: add TiFlash keyspace sections

docs/design/2022-12-06-Keyspace.md

@@ -148,3 +148,39 @@ So the [`RangeScanner`](https://github.com/iosmanthus/tikv/components/tidb_query
 
 ### TiFlash
 
+TiFlash is a columnar storage engine that serves as a coprocessor for TiKV. By accelerating TiDB queries, TiFlash improves performance. When TiDB is enabled with a keyspace, TiFlash requests also carry the keyspace prefix. TiFlash's data structures and storage paths are segregated by keyspace ID.
+
+#### Storage
+
+Without keyspace, TiFlash stores each table's columnar/schema data in a separate directory identified by the table ID. However, in a keyspace scenario, multiple keyspaces may share the same table ID, so the table ID alone cannot uniquely identify a table.
+
+TiFlash's storage path structure will be as follows:
+```
+.
+├── data
+│   ├── ks_1_t_92
+│   │   ├── data
+├── metadata
+│   ├── ks_1_db_1
+│   │   └── ks_1_t_92.sql
+│   ├── ks_1_db_2
+│   └── system
+```
+
+Each table directory will be identified by both the keyspace ID and table ID.
+
+#### Cache
+
+When decoding row data into columnar format, TiFlash ignores the keyspace prefix. Table-related cache structures will be refactored into a map of `<KeyspaceID, TableID> -> <ValueType>` instead of `<TableID> -> <ValueType>`.
+
+#### Schema sync
+
+When syncing schema from TiDB to TiFlash, TiFlash adds the keyspace prefix to requests to TiKV for specific table schemas.
+
+#### Request handling
+
+TiFlash requests carry the keyspace prefix. TiFlash parses `<KeyspaceID, TableID>` from the encoded key range and uses it to route requests to the relevant table storage.
+
+### Placement Rules
+
+Placement rules are isolated by keyspace. TiDB must name placement rules with the keyspace prefix, such as `keyspace-<keyspace_id>-xxxx`. Additionally, the key range of some rules must be encoded.