# Before the SQL Placement Rules Feature

+ A cluster deployed across geo-location cannot control access to data from the local
+ Cannot isolate resources according to business
+ It is difficult to configure resources and replicas according to business level

![`smart`](PlacementRulesInSQLBefore_aa_004_20220515.png)

-------------------------------------------------------------
Before TiDB v6.0, there were the following issues with TiDB cluster in terms of data placement management capability:

- A cluster deployed across geo-location cannot control access to data from the local. As can be seen from the figure, a user in `Singapore` needs to cross geo-location to read and write data from the "T3" table in `Seattle`, because we cannot specify its physical location when creating the table.

- It is not possible to isolate resources according to business. In the figure, the three users in `Seattle` need to access three tables "T4", "T5" and "T6", and unfortunately, most of the Leader roles of these three tables are distributed on the node TiKV-5. If data can be placed according to business attributes, so that the three users can read and write "T4", "T5" and "T6" tables from different servers, it will avoid the occurrence of hot spots.

- It is difficult to configure resources and replicas according to business levels. In the figure, two users from `Tokyo` both need to access the "T7" table, which is a very important table, and we hope its replica number is 5. At the same time, the "T8" table is a historical table, and we hope that the "T8" table can be stored on the three nodes of TiKV-7, TiKV-9 and TiKV-10 with general performance, without occupying the high-performance TiKV-8 node, that is, the data placement requirement of cold and hot separation.