データ配分方法
Oracle Globally Distributed Databaseでシャード表データを分散するためにサポートされる方法(シャーディング方法とも呼ばれる)、データ分散方法の選択方法およびサブパーティションの使用方法について説明します。
システム管理のデータ分散
システム管理のデータ分散では、シャードへのデータのマッピングをユーザーが指定する必要はありません。コンシステント・ハッシュによるパーティション化を使用して、データが自動的にシャード間に分散されます。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。
システム管理のデータ分散は、ホット・スポットを回避し、シャード間で均一なパフォーマンスを実現するためのものです。Oracle Globally Distributed Databaseは、分散データベースへのシャードの追加または削除の際に、バランスの取れたチャンク分散を自動的に維持します。
コンシステント・ハッシュはスケーラブルな分散システムでよく使用されるパーティション化の方法です。従来のハッシュ・パーティション化とは異なります。従来のハッシュの場合はバケット数がHF(key) % Nとして計算されます。ここで、HFはハッシュ関数、Nはバケット数です。この方法はNが一定の場合はうまく機能しますが、Nが変化するとすべてのデータの再シャッフルが必要になります。
線形ハッシュ法などのより高度なアルゴリズムの場合、ハッシュ・バケットを追加するために表全体を再ハッシュする必要はありませんが、バケット数が2のべき乗のみ、およびバケットを分割できるオーダーのみなど、バケット数に制限があります。
Oracle Globally Distributed Databaseで使用するコンシステント・ハッシュの実装では、このような制限を回避するために、次の図のように、ハッシュ関数の値の取りうる範囲(たとえば、0から232)をN個の隣接する間隔のセットに分割し、それぞれの間隔をチャンクに割り当てます。この例では、分散データベースに1024個のチャンクが含まれ、各チャンクに222のハッシュ値の範囲が割り当てられます。したがって、コンシステント・ハッシュによるパーティション化は、本質的にはハッシュ値の範囲によるパーティション化です。
すべてのシャードの計算能力が同じと仮定すると、分散データベースの各シャードに等しい数のチャンクが割り当てられます。たとえば、16個のシャードを含む分散データベース内に1024個のチャンクが作成されると、各シャードに64個のチャンクが含まれます。
分散データベースへのシャードの追加や削除の際の再シャーディングの場合、いくつかのチャンクがシャード間を移動して、シャード間のチャンクの均一な分散が維持されます。このプロセスでチャンクの内容は変化せず、再ハッシュは行われません。
1つのチャンクが分割されるときに、ハッシュ値の範囲が2つの範囲に分割されますが、他のチャンクに対して何かを行う必要はありません。任意のチャンクをいつでも個別に分割できます。
接続リクエストのシャードへの送信にかかわる分散データベースのすべてのコンポーネントに、各シャードでホストされるチャンクのリスト、および各チャンクに関連付けられたハッシュ値の範囲を含むルーティング表が保持されます。特定のデータベース・リクエストのルーティング先を決定するために、ルーティング・アルゴリズムによって、シャーディング・キーで指定された値にハッシュ関数が適用され、計算されたハッシュ値が適切なチャンクにマップされ、次にチャンクを含むシャードにマップされます。
システム管理のデータ分散を使用する分散データベースのチャンクの数は、シャード・カタログの作成時に指定できます。指定しない場合は、デフォルト値としてシャード当たり120個のチャンクが使用されます。分散データベースをデプロイした後、チャンク数を変更する方法は分割チャンク操作の実行のみです。
コンシステント・ハッシュによってパーティション化されたシャード表を作成する前に、表のパーティションを格納するために表領域のセット(チャンク当たり1つの表領域)を作成する必要があります。表領域は、CREATE TABLESPACE SETのSQL文を処理すると自動的に作成されます。
表領域セットのすべての表領域が同じ物理属性を持ち、Oracle Managed Files (OMF)のみを格納できます。最も簡単な形式の場合、CREATE TABLESPACE SET文は、たとえば次のように表領域セットの名前という1つのパラメータのみを持ちます。
CREATE TABLESPACE SET ts1;この場合、セットの各表領域にデフォルトの属性を持つ1つのOMFファイルが含まれます。表領域の属性をカスタマイズするには、文にUSING TEMPLATE句(次の例を参照)を追加します。USING TEMPLATE句は、セットの各表領域に適用される属性を指定します。
CREATE TABLESPACE SET ts1
USING TEMPLATE
(
DATAFILE SIZE 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO
ONLINE
)
;表領域セットが作成されたら、コンシステント・ハッシュでパーティション化される表を作成して、セットに属する表領域にパーティションを格納できます。CREATE TABLE文は、たとえば次のようになります。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, location_id VARCHAR2(20)
, class VARCHAR2(3)
, signup DATE
, CONSTRAINT cust_pk PRIMARY KEY(cust_id)
)
PARTITION BY CONSISTENT HASH (cust_id)
PARTITIONS AUTO
TABLESPACE SET ts1
;この文のPARTITIONS AUTOは、パーティション数が自動的に表領域セットts1の表領域の数(チャンク数と等しい)に設定され、各パーティションが個別の表領域に格納されることを意味します。
表領域セットの各表領域が別個のチャンクに属します。つまり、1つのチャンクは所定の表領域セットの1つの表領域のみを含むことができます。ただし、同じ表ファミリに属する複数の表に同じ表領域セットを使用できます。この場合、セットの各表領域に複数のパーティション(各表から1つ)が格納されます。
または、表ファミリの各表を個別の表領域セットに格納できます。この場合、1つのチャンクに複数の表領域(各表領域セットから1つ)が含まれ、各表領域に1つのパーティションが格納されます。
次の図は、単一シャード表のユースケースの場合のパーティション、表領域およびシャード間の関係を示しています。この場合、各チャンクに1つの表領域が含まれ、各表領域に1つのパーティションが格納されます。
ノート:
データ分散方法はGDSCTL CREATE SHARDCATALOGコマンドで指定し、後から変更することはできません。
ユーザー定義のデータ分散
ユーザー定義のデータ分散では、個々のシャードへのデータのマッピングをユーザーが明示的に指定できます。これは、パフォーマンスや規制などの理由で、特定のデータを特定のシャードに格納する必要があり、管理者がシャード間のデータの移動を完全に制御する必要がある場合に使用します。
ユーザー定義のデータ分散のもう1つのメリットとして、シャードの計画停止または計画外停止の場合に、どのデータが使用できないかをユーザーが正確に把握できます。ユーザー定義のデータ分散のデメリットは、データベース管理者が、シャード間のデータおよびワークロードの分散のバランスを監視して維持する必要があることです。
シャード領域の理解
シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。ユーザー定義のデータ分散では、シャード領域が1つのシャード、または完全にレプリケートされたシャードのセットから構成されます。わかりやすいように、各シャード領域が1つのシャードから構成されると仮定します。
ユーザー定義構成へのシャード領域の追加
シャードとそのCDBをユーザー定義のデータ分散構成に追加する前に、シャード領域を作成して移入する必要があります。たとえば、次のGDSCTLコマンドを使用できます。
ADD SHARDSPACE -SHARDSPACE east
ADD SHARDSPACE -SHARDSPACE central
ADD SHARDSPACE -SHARDSPACE west
ADD CDB -CONNECT cdb1
ADD CDB -CONNECT cdb2
ADD CDB -CONNECT cdb3
ADD SHARD –CONNECT shard-1 -CDB cdb1 –SHARDSPACE west;
ADD SHARD –CONNECT shard-2 -CDB cdb2 –SHARDSPACE central;
ADD SHARD –CONNECT shard-3 -CDB cdb3 –SHARDSPACE east;ユーザー定義データ分散の表領域の作成
ユーザー定義のデータ分散には表領域セットはありません。各表領域を個別に作成し、シャード領域と明示的に関連付ける必要があります。
次の文を使用して、前述の例の各シャード領域の表領域を作成できます。
CREATE TABLESPACE tbs1 IN SHARDSPACE west;
CREATE TABLESPACE tbs2 IN SHARDSPACE central;
CREATE TABLESPACE tbs3 IN SHARDSPACE east;ユーザー定義のデータ分散でのシャード表の作成
ユーザー定義のデータ分散の場合、範囲またはリストによってシャード表をパーティション化できます。シャード表のCREATE TABLE構文は、各パーティションを個別の表領域に格納する必要があることを除き、通常の表のための構文とそれほど違いはありません。
たとえば:
CREATE SHARDED TABLE accounts
( id NUMBER
, account_number NUMBER
, customer_id NUMBER
, branch_id NUMBER
, state VARCHAR(2) NOT NULL
, status VARCHAR2(1)
)
PARTITION BY LIST (state)
( PARTITION p_west VALUES ('OR', 'WA') TABLESPACE ts1
, PARTITION p_central VALUES ('SD', 'WI') TABLESPACE ts2
, PARTITION p_east VALUES ('NY', 'VM', 'NJ') TABLESPACE ts3
)
;次の図は、前述の例に示したaccounts表について、表領域へのパーティションのマッピング、およびシャードへの表領域のマッピングを示しています。
ユーザー定義のデータ分散でのチャンク管理
システム管理のデータ分散と同様に、ユーザー定義のデータ分散で作成される表領域もチャンクに割り当てられます。ただし、シャードが分散データベースに追加されても、チャンク移行は自動的に開始されません。移行する必要があるチャンクごとにGDSCTL MOVE CHUNKコマンドを実行する必要があります。
チャンクの合計数は、シャード表で指定されたパーティション数によって定義されます。特定のシャード領域のチャンクの数は、割り当てられたパーティションの数です。シャード表に対するALTER TABLE ADD、DROP、SPLITおよびMERGE PARTITIONコマンドは、チャンクの数を増減します。
GDSCTLコマンドSPLIT CHUNKは、システム管理のデータ分散では、ハッシュ範囲の中央でチャンクを分割するために使用されますが、ユーザー定義のデータ分散ではサポートされません。ALTER TABLE SPLIT PARTITION文を使用してチャンクを分割する必要があります。
ユーザー定義のデータ分散でのレプリケーション
ユーザー定義の分散データベースでは、2つのレプリケーション・スキームがサポートされています:
-
Oracle Data Guard
-
Oracle Active Data Guard
レプリケーション方法としてRaftレプリケーションが使用されている場合、ユーザー定義のデータ分散はサポートされません。
ディレクトリベースのデータ分散
ディレクトリベースのデータ分散では、実行時にキー値とシャードを動的に関連付けることができるため、キー値からシャードへのマッピングを細かく制御できます
これをシステム管理のデータ分散と比較すると、特に個別キー値が比較的多い(数万から数十万)ものの、ハッシュベースの割当てで均一なデータ分散を実現するには十分な規模でない場合、データ分散が不均一になる可能性があります。
また、これと通常のユーザー定義のデータ分散を比較します。これは、スキーマの作成時に指定できる少数の静的キー値に適しています。
ディレクトリベースのデータ分散のユースケース
次のユースケースは、分散データベースでディレクトリベースのデータ分散方法を使用すると有利になる場合を示しています。
システム管理のデータ分散による不均一なデータ分散
ディレクトリベースのデータ分散は、個別キー値の数が不十分なため、システム管理のデータ分散でデータ分散が不均一になる場合に役立ちます
一般的なユース・ケースに、多数のビジネス顧客アカウントのデータを管理するB2Bアプリケーションがあります。ここでは数万規模のアカウントを管理します。
この例の1つにディーラ・アプリケーションがあり、多数のディーラのデータをホストおよび管理します。ディーラ数は数万規模であり、ハッシングによってデータを分散するほど大きくはありません。さらに、様々なディーラのデータの量は大きく異なる可能性があります。一部のディーラは大規模運営ですが、はるかに小規模のディーラもあり、それらすべてをシステム管理のデータ分散内でのように同じ方法で処理するのは適していません。アプリケーション固有の基準に基づいて、様々なディーラに対して異なるリソースと場所を指定する必要がある場合もあります。
特定のキー値を同じ場所またはチャンクにグループ化
ディレクトリベースのデータ分散は、特定のキー値を同じ場所にグループ化するか、アフィニティ目的でチャンクにグループ化する必要がある場合や、このグループをまとめて効率的に移動できる場合に便利です
この例の1つにSocial Networkアプリケーションがあります。ここでは、同じシャードでメッセージを頻繁に交換する顧客をグループ化すると、シャード間のトラフィックが最小限になります。データをシャード間で移動する場合、再シャーディング中にグループ化を保持する必要があります。一方、グループのメンバーが別のグループのメンバーとの通信をさらに始める場合は、アプリケーションへの影響を最小限に抑えて、そのデータを適切なグループに移動する必要があります。
カスタム・ポリシーベースのデータ分散の実装
ディレクトリベースのデータ分散を使用して、カスタム・ポリシーベースのデータ分散(ラウンドロビン、ランダム、最小データなど)を実装できます。
ディレクトリベースのデータ分散の概念とアーキテクチャ
ディレクトリベースのデータ分散を理解するための主要な概念を次に示します。
- パーティションおよびシャードへのキー値のマッピングは、ディレクトリ表に格納されます。
- ディレクトリ表は、ディレクトリによってシャードされた表が作成されると、シャード・カタログに自動的に作成され、シャードされます。
- シャード・ディレクタ(GSM)およびクライアント側の接続プールは、ルーティングの目的でディレクトリをキャッシュします。キャッシュ内のキー値は暗号化されます。
- 自動割当ルールが有効な挿入のために、シャード表に対して行が挿入または削除されると、ディレクトリが自動的に更新されます。削除しても、ディレクトリ内のマッピングは自動的には削除されません。
- シャード表には、パーティション情報を含む仮想列が含まれており、パーティション・プルーニングに使用されます。
次の図は、ディレクトリベースのデータ分散の主要なコンポーネントを示しています。ディレクトリ表はシャード・カタログでホストされ、すべてのシャードに複製されます。シャード表は、ディレクトリ表のキー/パーティション・マッピングに基づいて異なるシャードに分散されます。
キー挿入および更新操作はシャード・カタログで実行され、コミット時にシャードと同期的に複製されます。
クライアント・プールは、他のデータ分散方法の場合と同様に、各シャードからキーとチャンク/シャードのマッピングをフェッチします。また、新しいキー・マッピングまたは削除を通知するFANイベントもサブスクライブします。
ディレクトリベースの分散はユーザー定義の分散方法の拡張であるため、ユーザー定義の方法といくつかの例については、ユーザー定義のデータ分散を参照してください。
ディレクトリベースの分散データベースでのシャード表の作成
ディレクトリベースのシャード表は、CREATE SHARDED TABLE文でPARTITION BY DIRECTORYを使用して作成されます。
たとえば:
CREATE SHARDED TABLE customers
( id NUMBER NOT NULL
, name VARCHAR2(30)
, address VARCHAR2(30)
, status VARCHAR2(1)
,
CONSTRAINT cust_pk PRIMARY KEY(id)
)
PARTITION BY DIRECTORY (id)
( PARTITION p1 TABLESPACE tbs1,
PARTITION p2 TABLESPACE tbs2,
PARTITION p3 TABLESPACE tbs3…);
ノート:
-
ユーザー定義のデータ分散とは異なり、
CREATE TABLE文のパーティションにキー値は指定されません。 -
ディレクトリ表は、ルート表の作成時に自動的に作成されます。ディレクトリ表の定義は次のとおりです。
shard_user_schema.root_table$SDIR
オブジェクトの作成、ディレクトリベースの分散データベースのデプロイおよび管理の詳細は、ディレクトリベースのOracle Globally Distributed Databaseのデプロイおよび管理を参照してください。
コンポジット・データ分散
コンポジット・データ分散方法では、コンシステント・ハッシュによりパーティション化された表のデータの異なるサブセットについて、複数のシャード領域を作成できます。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。
システム管理のデータ分散では、コンシステント・ハッシュによるパーティション化を使用して、シャード間にデータをランダムに分散します。これは、範囲またはリストによるパーティション化を使用するユーザー定義の分散と比べて、よりよいロード・バランスを実現します。ただし、システム管理の分散では、データのシャードへの割当てをユーザーが制御できません。
主キーのコンシステント・ハッシュによるパーティション化の際は、多くの場合にデータのサブセットを異なる地理的場所に格納する必要性や、データのサブセットに異なるハードウェア・リソースを割り当てる必要性、または高可用性と障害回復を異なる構成にするために、分散データベース内のデータのサブセットを区別する必要性が生じます。通常は、この区別は顧客の場所やサービスのクラスなど、別の(主キーでない)列の値に基づいて行われます。
コンポジット分散は、ユーザー定義の分散とシステム管理の分散の組合せで、必要に応じて両方の利点を活用できます。コンポジット分散では、最初にデータがリストまたは範囲により複数のシャード領域にパーティション化され、次にコンシステント・ハッシュにより各シャード領域の複数のシャード間にさらにパーティション化されます。2つのレベルの分散により、各シャード領域のシャード間のバランスのとれたデータ分散を自動的に維持し、同時にシャード領域間にデータをパーティション化できます。
たとえば、高速なサーバーでホストされる3つのシャードをゴールド顧客に割り当て、低速のマシンでホストされる4つのシャードをシルバー顧客に割り当てるとします。顧客IDのコンシステント・ハッシュによるパーティション化を使用して、シャードの各セット内に顧客を分散する必要があります。
この構成を作成するには、次のコマンドを発行します。なお、この構成の場合は2つのシャード領域を作成する必要があります。
create SHARDCATALOG -sharding composite -database
cat_host:1521/cat_pdb.domain -user gsmcatuser/gsmcatuser_pwd
-region dc1
add gsm -gsm gsm1 -listener 1540 -catalog cat_host:1521/cat_pdb.domain
-region dc1 -pwd gsmcatuser_pwd
gdsctl start gsm
add shardspace -shardspace shspace1 -chunks 60
add shardspace -shardspace shspace2 -chunks 120
ADD SHARDGROUP -shardgroup gold -shardspace shspace1 -region dc1 -deploy_as
primary
ADD SHARDGROUP -shardgroup silver -shardspace shspace2 -region dc1 -deploy_as
primary
add CDB -connect cdb1_host:1521/cdb1.domain -pwd gsmrootuser_pwd
add CDB -connect cdb2_host:1521/cdb2.domain -pwd gsmrootuser_pwd
add CDB -connect cdb3_host:1521/cdb3.domain -pwd gsmrootuser_pwd
add CDB -connect cdb4_host:1521/cdb4.domain -pwd gsmrootuser_pwd
add CDB -connect cdb5_host:1521/cdb5.domain -pwd gsmrootuser_pwd
add CDB -connect cdb6_host:1521/cdb6.domain -pwd gsmrootuser_pwd
add CDB -connect cdb7_host:1521/cdb7.domain -pwd gsmrootuser_pwd
add shard -cdb cdb1 -shardgroup gold -connect
cdb1_host:1521/sh1_pdb.domain -pwd gsmuser_pwd
add shard -cdb cdb2 -shardgroup gold -connect
cdb2_host:1521/sh2_pdb.domain -pwd gsmuser_pwd
add shard -cdb cdb3 -shardgroup gold -connect
cdb3_host:1521/sh3_pdb.domain -pwd gsmuser_pwd
add shard -cdb cdb4 -shardgroup silver -connect
cdb4_host:1521/sh4_pdb.domain -pwd gsmuser_pwd
add shard -cdb cdb5 -shardgroup silver -connect
cdb5_host:1521/sh5_pdb.domain -pwd gsmuser_pwd
add shard -cdb cdb6 -shardgroup silver -connect
cdb6_host:1521/sh6_pdb.domain -pwd gsmuser_pwd
add shard -cdb cdb7 -shardgroup silver -connect
cdb7_host:1521/sh7_pdb.domain -pwd gsmuser_pwd
deployコンポジット分散では、他のデータ分散方法と同様に、表領域を使用してシャードへのパーティションのマッピングを指定します。シャード表のデータのサブセットを異なるシャード領域に割り当てるために、次の例に示すように、各シャード領域に個別の表領域のセットを作成する必要があります。
CREATE TABLESPACE SET tbs1 IN SHARDSPACE shspace1;
CREATE TABLESPACE SET tbs2 IN SHARDSPACE shspace2;ユーザー定義のデータのサブセットを異なる表領域に格納するために、Oracle Globally Distributed Databaseには、パーティションをセットにグループ化し、パーティションの各セットを表領域セットに関連付ける構文が用意されています。パーティション・セットのサポートは、論理的には、コンシステント・ハッシュによるパーティション化の上位に実装される高レベルのパーティション化に相当すると考えることができます。
次の例に示す文では、サービスのクラスに基づいて、シャード表をgoldとsilverという2つのパーティション・セットにパーティション化しています。各パーティション・セットが個別の表領域に格納されます。次に、各パーティション・セットのデータが、顧客IDのコンシステント・ハッシュによってさらにパーティション化されます。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, location_id VARCHAR2(20)
, class VARCHAR2(3)
, signup_date DATE
, CONSTRAINT cust_pk PRIMARY KEY(cust_id, class)
)
PARTITIONSET BY LIST (class)
PARTITION BY CONSISTENT HASH (cust_id)
PARTITIONS AUTO
(PARTITIONSET gold VALUES (‘gld’) TABLESPACE SET tbs1,
PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET tbs2)
;ノート:
データ分散方法はGDSCTL CREATE SHARDCATALOGコマンドで指定し、後から変更することはできません。
分散データベースでのサブパーティションの使用
Oracle Globally Distributed Databaseは表のパーティション化に基づくため、Oracle Databaseで提供されるサブパーティション方法はすべてOracle Globally Distributed Databaseでもサポートされています。
サブパーティション化は各パーティションをより小さい部分に分割します。これは、シャード内の効率的なパラレル処理、特に、シャード当たりのパーティション数が少ないときの範囲またはリストによるパーティション化の場合に役立つ可能性があります。
管理性の面では、サブパーティションを個別の表領域に割り当てて記憶域階層間で移動することで、サブパーティション化によって記憶域の階層化をサポートできます。パーティション化のスケーラビリティと可用性という利点を損なわず、パーティション・プルーニングと主キーによるパーティション単位の結合の実行を犠牲にすることなく、記憶域階層間でサブパーティションを移行できます。
次の例は、コンシステント・ハッシュと範囲によるサブパーティション化を組み合せたシステム管理のデータ分散を示しています。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, location_id VARCHAR2(20)
, class VARCHAR2(3)
, signup_date DATE
, CONSTRAINT cust_pk PRIMARY KEY(cust_id, signup_date)
)
TABLESPACE SET ts1
PARTITION BY CONSISTENT HASH (cust_id)
SUBPARTITION BY RANGE (signup_date)
SUBPARTITION TEMPLATE
( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY')),
SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY')),
SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY')),
SUBPARTITION future VALUES LESS THAN (MAXVALUE)
)
PARTITIONS AUTO
;次の図は、この文によって作成される表を示しています。
この例では、各サブパーティションが親パーティションの表領域に格納されます。日付によってサブパーティション化されているため、サブパーティションを個別の表領域に格納して、古いデータをアーカイブしたり、読取り専用の記憶域に移動できるようにするほうが合理的です。適切な構文を次に示します。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, location_id VARCHAR2(20)
, class VARCHAR2(3)
, signup_date DATE NOT NULL
, CONSTRAINT cust_pk PRIMARY KEY(cust_id, signup_date)
)
PARTITION BY CONSISTENT HASH (cust_id)
SUBPARTITION BY RANGE(signup_date)
SUBPARTITION TEMPLATE
( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY'))
TABLESPACE SET ts1,
SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY'))
TABLESPACE SET ts2,
SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY'))
TABLESPACE SET ts3,
SUBPARTITION future VALUES LESS THAN (MAXVALUE)
TABLESPACE SET ts4
)
PARTITIONS AUTO
;シャーディングされていないデータベースの場合は、サブパーティション・テンプレートで表領域を指定すると、すべてのパーティションのサブパーティションNが同じ表領域に格納されることに注意してください。これは、異なるパーティションに属するサブパーティションを個別の表領域に格納して、再シャーディングの際に移動できるようにする場合のパーティション化とは異なります。
サブパーティション化はコンポジット・データ分散方法でも使用できます。この場合、表のデータがパーティション・セット、パーティションおよびサブパーティションの3つのレベルに編成されます。次に、3つのレベルにデータを編成する例を示します。
パーティションセット間でサブパーティションの数と境界を均一にするため、パーティションセット単位でのサブパーティション・テンプレートの指定はサポートされていません。パーティションセット単位でサブパーティションの表領域を指定する必要がある場合は、SUBPARTITIONS STORE IN句を使用できます。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, location_id VARCHAR2(20)
, class VARCHAR2(3) NOT NULL
, signup_date DATE NOT NULL
, CONSTRAINT cust_pk PRIMARY KEY(cust_id, class, signup_date)
)
PARTITIONSET BY LIST (class)
PARTITION BY CONSISTENT HASH (cust_id)
SUBPARTITION BY RANGE (signup_date)
SUBPARTITION TEMPLATE /* applies to both SHARDSPACEs */
( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY'))
, SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY'))
, SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY'))
, SUBPARTITION future VALUES LESS THAN (MAXVALUE)
)
PARTITIONS AUTO
(
PARTITIONSET gold VALUES (‘gld’) TABLESPACE SET tbs1
subpartitions store in(tbs1)
, PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET tbs2
subpartitions store in(tbs2)
)
;