# SQL配置ルール機能の導入前

+ ジオロケーションにわたってデプロイされたクラスタは、ローカルのデータへのアクセスを制御することはできません
+ リソースをビジネスに応じて分離することはできません
+ ビジネスレベルに応じてリソースとレプリカを設定するのは難しいです

![`smart`](PlacementRulesInSQLBefore_aa_004_20220515.png)

-------------------------------------------------------------
TiDB v6.0以前に、データ配置管理能力に関して、TiDBクラスタには以下の問題がありました：

- クロスジオロケーションによってデプロイされたクラスタは、ローカルからのデータへのアクセスを制御することはできません。図からわかるように、`Singapore`のユーザーは、テーブルを作成する際にその物理的な位置を指定できないため、`Seattle`の「T3」テーブルからの読み書きを行うためにジオロケーションを越える必要があります。

- ビジネスに応じてリソースを分離することはできません。図に示すように、`Seattle`の3つのユーザーは、「T4」「T5」「T6」の3つのテーブルにアクセスする必要がありますが、残念ながら、これらの3つのテーブルの大部分のLeaderの役割はTiKV-5ノードに分散されています。データをビジネス属性に応じて配置することで、3つのユーザーが異なるサーバーから「T4」「T5」「T6」テーブルを読み書きできるようになると、ホットスポットの発生を回避できます。

- ビジネスレベルに応じてリソースとレプリカを設定するのは難しいです。図では、`Tokyo`からの2つのユーザーがともに「T7」テーブルにアクセスする必要があり、これは非常に重要なテーブルであるため、レプリカ数を5にしたいと考えています。同時に、「T8」テーブルは歴史的なテーブルであり、「T8」テーブルをTiKV-7、TiKV-9、TiKV-10の3つのノードに一般的なパフォーマンスで保存し、高パフォーマンスのTiKV-8ノードを占有せず、つまりコールドとホットの分離のデータ配置要件を満たしたいと考えています。