日本語PDF
  1. Oracle Shardingの使用
  2. Oracle Shardingのアーキテクチャおよび概念

2 Oracle Shardingのアーキテクチャおよび概念

Oracle Shardingアーキテクチャのコンポーネント

次の図は、次のトピックで説明するOracle Shardingの主要なアーキテクチャ・コンポーネントを示しています。

図2-1 Oracle Shardingのアーキテクチャ

図2-1の説明が続きます
「図2-1 Oracle Shardingのアーキテクチャ」の説明

シャード・データベースとシャード

シャード・データベースはシャードの集まりです。

シャード・データベースとは、ハードウェアまたはソフトウェアを共有しない物理Oracleデータベース(シャード)のプールで水平にパーティション化された単一の論理Oracle Databaseです。

シャード・データベース内の各シャードは、シャード・データベースのデータのサブセットをホストする独立したOracle Databaseインスタンスです。シャード間で共有記憶域は必要ありません。

シャードは、Oracleデータベースをホストできる場所であればどこでもホストできます。Oracle Shardingは、オンプレミス、任意のクラウド・プラットフォーム、Oracle Exadata Database Machine、仮想マシンなど、単一インスタンスまたはクラスタ化されたOracle Databaseで予想されるシャードのすべてのデプロイメント選択をサポートしています。

各シャードは、1つのリージョンに配置するか、別々のリージョンに配置できます。Oracle Shardingのコンテキストでのリージョンは、1つのデータ・センターまたはネットワーク上で近接している複数のデータ・センターを表します。

シャードは、Oracle Data Guardを使用した高可用性および障害時リカバリのためにレプリケートされます。高可用性のためには、プライマリ・シャードが配置されているリージョンと同じリージョンに、Data Guardスタンバイ・シャードを配置できます。障害時リカバリのためには、スタンバイ・シャードを別のリージョンに配置できます。

ノート:

Oracle ShardingのOracle GoldenGateレプリケーション・サポート高可用性は、Oracle Database 21cでは非推奨です。

シャード・カタログ

シャード・カタログは、自動的なシャードのデプロイメント、シャード・データベースの集中管理、およびマルチシャード問合せをサポートするOracle Databaseです。

シャード・カタログは次の目的を果たします。

  • 共有データベース全体の管理サーバーとして機能します。

  • データベース・スキーマのゴールド・コピーを格納します

  • マルチシャード問合せコーディネータを使用したマルチシャード問合せの管理

  • 重複表データのゴールド・コピーを格納します

シャード・カタログは特殊な目的のOracle Databaseであり、シャード・データベース構成データの永続的なストアとなり、シャード・データベースの集中管理で主要な役割を果たします。すべての構成の変更(シャードやグローバル・サービスの追加、削除など)は、シャード・カタログで開始されます。シャード・データベースのすべてのDDLは、シャード・カタログに接続することによって実行されます。

シャード・カタログには、シャード・データベースのすべての重複表のマスター・コピーも含まれています。シャード・カタログは、マテリアライズド・ビューを使用して、すべてのシャードの重複表に変更を自動的にレプリケートします。シャード・カタログは、マルチシャード問合せ、およびシャーディング・キーを指定しない問合せを処理するための問合せコーディネータとしても機能します。

複数のシャード・カタログを高可用性のためにデプロイできます。シャード・カタログの高可用性のためにOracle Data Guardを使用することをベスト・プラクティスとしてお薦めします。

実行時に、アプリケーションがキーベースの問合せを使用しないかぎり、シャードに問合せを送信するにはシャード・カタログが必要です。シャーディング・キーベースのトランザクションは引き続きシャード・データベースにルーティングされて実行され、カタログの停止の影響を受けません。

スタンバイ・シャード・カタログへの自動フェイルオーバーを完了するために必要な短期の停止時間は、メンテナンス操作の実行、スキーマの変更、重複表の更新、マルチシャード問合せの実行、トポロジの変更を引き起こすシャードの追加やチャンクの移動などのその他の操作の実行に影響します。

シャード・ディレクタ

シャード・ディレクタは、シャーディング・キーに基づいて高パフォーマンスな接続ルーティングを可能にするネットワーク・リスナーです。

Oracle Database 12cでは、グローバル・サービス・マネージャが導入され、データベース・ロール、負荷、レプリケーション・ラグおよびローカル性に基づいて接続がルーティングされます。Oracle Shardingをサポートするために、グローバル・サービス・マネージャはデータの場所に基づいた接続のルーティングをサポートします。グローバル・サービス・マネージャは、Oracle Shardingのコンテキストではシャード・ディレクタと呼ばれます。

シャード・ディレクタは、グローバル・サービス・マネージャの特殊な実装であり、シャード・データベースに接続するクライアントのリージョナル・リスナーとして機能します。シャード・ディレクタはシャード・データベースの現在のトポロジ・マップを維持します。接続リクエスト中に渡されたシャーディング・キーに基づいて、シャード・ディレクタは適切なシャードに接続をルーティングします。

一般的なシャード・データベースの場合、一連のシャード・ディレクタが各リージョンの市販のローエンドの専用サーバーにインストールされます。高可用性とスケーラビリティを実現するには、複数のシャード・ディレクタをデプロイします。特定の領域に最大5つのシャード・ディレクタをデプロイできます。

シャード・ディレクタの主な機能を次に示します。

  • シャード・データベース構成に関する実行時データおよびシャードの可用性の保守

  • 配下のリージョンと他のリージョンの間のネットワーク待機時間の測定

  • クライアントがシャード・データベースへの接続に使用するためのリージョナル・リスナーとして機能します

  • グローバル・サービスの管理

  • 接続ロード・バランシングの実行

グローバル・サービス

グローバル・サービスは、シャード・データベースのデータへのアクセスに使用されるデータベース・サービスです。

グローバル・サービスは、従来のデータベース・サービスの概念を拡張したものです。グローバル・サービスでは、従来のデータベース・サービスのすべてのプロパティがサポートされます。シャード・データベースでは、グローバル・サービス用の追加のプロパティが設定されます。たとえば、データベース・ロール、レプリケーション・ラグの許容値、クライアントとシャード間のリージョン・アフィニティなどがあります。読取り/書込みトランザクション・ワークロードの場合は、シャード・データベースのプライマリ・シャードのデータにアクセスするために、単一のグローバル・サービスが作成されます。Active Data Guardを使用する高可用性シャードの場合は、別個の読取り専用グローバル・サービスを作成できます。

パーティション、表領域およびチャンク

異なるシャードに存在する表領域にパーティションを作成することで、シャード間にパーティションを分散します。

シャード表の各パーティションが個別の表領域に格納され、表領域がSDBのデータ分散の単位になります。

シャード表ファミリで説明するように、マルチシャード結合の数を最小にするために、表ファミリのすべての表の対応するパーティションが常に同じシャードに格納されます。構文の例で表領域セットts1がすべての表に使用されているように、1つの表ファミリの表が分散された表領域の同じセットに作成されるときに、これが保証されます。

ただし、1つの表ファミリの異なる表を異なる表領域のセットに作成することも可能です。たとえば、表領域セットts1にCustomers表を作成し、表領域セットts2にOrdersを作成できます。この場合、Customersのパーティション1が格納される表領域が常に、Ordersのパーティション1が格納される表領域と同じシャードに存在することが保証される必要があります。

この機能をサポートするために、表ファミリのすべての表の対応するパーティションのセット(チャンクと呼ばれる)が作成されます。チャンクには表ファミリの各表の1つのパーティションが含まれます。これより、様々なシャード表の関連するデータが一緒に移動されることが保証されます。つまり、チャンクはシャード間のデータ移行の単位です。システム管理シャーディングおよび複合シャーディングでは、シャード・データベースの作成時に各シャード内のチャンク数が指定されます。ユーザー定義シャードでは、チャンクの合計数はパーティションの数と同じです。

次の図に、Cutomers-Orders-LineItemsスキーマの表の対応するパーティションを含むチャンクを示します。

図2-2 パーティションのセットとしてのチャンク

図2-2の説明が続きます
「図2-2 パーティションのセットとしてのチャンク」の説明

次の図のように、各シャードに複数のチャンクが含まれます。

図2-3 シャードの内容

図2-3の説明が続く
「図2-3 シャードの内容」の説明

シャード表に加えて、シャードには1つ以上の重複表も含めることができます。重複表は、シャード表に使用される表領域には格納できません。

表領域セット

Oracle Shardingは、TABLESPACE SETと呼ばれる単位として表領域を作成および管理します。

システム管理シャーディングと複合シャーディングではTABLESPACE SETを使用し、ユーザー定義シャーディングでは通常の表領域を使用します。

表領域は、シャード・データベースでのデータ分散の論理単位です。異なるシャードに存在する表領域にパーティションを自動的に作成することで、シャード間にパーティションを分散します。マルチシャード結合の数を最小にするために、関連する表の対応するパーティションは常に同じシャードに格納されます。シャード表の各パーティションが個別の表領域に格納されます。

PARTITIONS AUTO句は、パーティション数を自動的に判別することを指定します。このハッシュ・タイプによってシャード間のデータ移行でさらに柔軟性および効率性がもたらされ、これは弾力的な拡張性にとって重要です。

表領域セットごとに作成される表領域の数は、デプロイメント時にシャード領域に定義されたチャンクの数に基づいて決定されます。

ノート:

表領域セットでは、Oracle Managed Filesのみがサポートされます。

個々の表領域を表領域セット全体とは別個に削除または変更することはできません。

TABLESPACE SETをユーザー定義のシャーディング方法とともに使用することはできません。

シャーディング方法

次のトピックでは、Oracle Shardingでサポートされるシャーディング方法、方法の選択およびサブパーティションの使用方法について説明します。

システム管理のシャーディング

システム管理のシャーディングでは、シャードへのデータのマッピングをユーザーが指定する必要はありません。コンシステント・ハッシュによるパーティション化を使用して、データが自動的にシャード間に分散されます。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。

システム管理のシャーディングで使用される分散はホット・スポットを回避し、シャード間で均一なパフォーマンスを実現するためのものです。Oracle Shardingは、SDBへのシャードの追加または削除の際に、バランスの取れたチャンク分散を自動的に維持します。

コンシステント・ハッシュはスケーラブルな分散システムでよく使用されるパーティション化の方法です。従来のハッシュ・パーティション化とは異なります。従来のハッシュの場合はバケット数がHF(key) % Nとして計算されます。ここで、HFはハッシュ関数、Nはバケット数です。この方法はNが一定の場合はうまく機能しますが、Nが変化するとすべてのデータの再シャッフルが必要になります。

線形ハッシュ法などのより高度なアルゴリズムの場合、ハッシュ・バケットを追加するために表全体を再ハッシュする必要はありませんが、バケット数が2のべき乗のみ、およびバケットを分割できるオーダーのみなど、バケット数に制限があります。

Oracle Shardingで使用するコンシステント・ハッシュの実装では、このような制限を回避するために、次の図のように、ハッシュ関数の値の取りうる範囲(たとえば、0から232)をN個の隣接する間隔のセットに分割し、それぞれの間隔をチャンクに割り当てます。この例では、SDBに1024個のチャンクが含まれ、各チャンクに222のハッシュ値の範囲が割り当てられます。したがって、コンシステント・ハッシュによるパーティション化は、本質的にはハッシュ値の範囲によるパーティション化です。

図2-4 チャンクに割り当てられるハッシュ値の範囲

図2-4の説明が続きます
「図2-4 チャンクに割り当てられるハッシュ値の範囲」の説明

すべてのシャードの計算能力が同じだとすると、SDBの各シャードに等しい数のチャンクが割り当てられます。たとえば、16個のシャードを含むSDB内に1024個のチャンクが作成されると、各シャードに64個のチャンクが含まれます。

SDBへのシャードの追加や削除の際の再シャーディングの場合、いくつかのチャンクがシャード間を移動して、シャード間のチャンクの均一な分散が維持されます。このプロセスでチャンクの内容は変化せず、再ハッシュは行われません。

1つのチャンクが分割されるときに、ハッシュ値の範囲が2つの範囲に分割されますが、他のチャンクに対して何かを行う必要はありません。任意のチャンクをいつでも個別に分割できます。

接続リクエストのシャードへの送信にかかわるSDBのすべてのコンポーネントに、各シャードでホストされるチャンクのリスト、および各チャンクに関連付けられたハッシュ値の範囲を含むルーティング表が保持されます。特定のデータベース・リクエストのルーティング先を決定するために、ルーティング・アルゴリズムによって、シャーディング・キーで指定された値にハッシュ関数が適用され、計算されたハッシュ値が適切なチャンクにマップされ、次にチャンクを含むシャードにマップされます。

システム管理のシャーディングのSDB内のチャンク数は、GDSCTLコマンド、CREATE SHARDCATALOGで指定できます。指定しない場合は、デフォルト値としてシャード当たり120個のチャンクが使用されます。SDBのデプロイ後にチャンク数を変更する方法はチャンクの分割のみです。

コンシステント・ハッシュによってパーティション化されたシャード表を作成する前に、表のパーティションを格納するために表領域のセット(チャンク当たり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つのパーティションが格納されます。

図2-5 システム管理のシャーディング

図2-5の説明が続きます
「図2-5 システム管理のシャーディング」の説明

ノート:

シャーディング方法はGDSCTL CREATE SHARDCATALOGコマンドで指定し、後から変更することはできません。

ユーザー定義のシャーディング

ユーザー定義のシャーディングでは、個々のシャードへのデータのマッピングをユーザーが明示的に指定できます。これは、パフォーマンスや規制などの理由で、特定のデータを特定のシャードに格納する必要があり、管理者がシャード間のデータの移動を完全に制御する必要がある場合に使用します。

ユーザー定義のシャード・データベースでは、Oracle Data GuardとOracle Active Data Guardの2つのレプリケーション・スキーマがサポートされます。レプリケーション方法としてOracle GoldenGateが使用されている場合、ユーザー定義のシャーディングはサポートされません。

ユーザー定義のシャーディングのもう1つのメリットとして、シャードの計画停止または計画外停止の場合に、どのデータが使用できないかをユーザーが正確に知ることができます。ユーザー定義のシャーディングのデメリットは、データベース管理者が、シャード間のデータおよびワークロードの分散のバランスを監視して維持する必要があることです。

ユーザー定義のシャーディングの場合、範囲またはリストによってシャード表をパーティション化できます。シャード表の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_northwest VALUES ('OR', 'WA') TABLESPACE ts1
, PARTITION p_southwest VALUES ('AZ', 'UT', 'NM') TABLESPACE ts2
, PARTITION p_northcentral VALUES ('SD', 'WI') TABLESPACE ts3
, PARTITION p_southcentral VALUES ('OK', 'TX') TABLESPACE ts4
, PARTITION p_northeast VALUES ('NY', 'VM', 'NJ') TABLESPACE ts5
, PARTITION p_southeast VALUES ('FL', 'GA') TABLESPACE ts6
)
;

ユーザー定義のシャーディングには表領域セットはありません。各表領域を個別に作成し、シャード領域と明示的に関連付ける必要があります。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。

ユーザー定義のシャーディングでは、シャード領域が1つのシャード、または完全にレプリケートされたシャードのセットから構成されます。ユーザー定義のシャーディングでのレプリケーションの詳細は、シャード・レベルの高可用性を参照してください。わかりやすいように、各シャード領域が1つのシャードから構成されると仮定します。

次の構文を使用して、前述の例に示したaccounts表の表領域を作成します。

CREATE TABLESPACE tbs1 IN SHARDSPACE west;
CREATE TABLESPACE tbs2 IN SHARDSPACE west;

CREATE TABLESPACE tbs3 IN SHARDSPACE central;
CREATE TABLESPACE tbs4 IN SHARDSPACE central;

CREATE TABLESPACE tbs5 IN SHARDSPACE east;
CREATE TABLESPACE tbs6 IN SHARDSPACE east;

CREATE TABLESPACE文を実行する前に、シャード領域を作成し、シャードを移入する必要があります。たとえば、次のGDSCTLコマンドを使用できます。 

ADD SHARDSPACE -SHARDSPACE east
ADD SHARDSPACE -SHARDSPACE central
ADD SHARDSPACE -SHARDSPACE west
ADD SHARD –CONNECT shard-1 –SHARDSPACE west;
ADD SHARD –CONNECT shard-2 –SHARDSPACE central;
ADD SHARD –CONNECT shard-3 –SHARDSPACE east;

次の図は、前述の例に示したaccounts表について、表領域へのパーティションのマッピング、およびシャードへの表領域のマッピングを示しています。

図2-6 ユーザー定義のシャーディング

図2-6の説明が続きます
「図2-6 ユーザー定義のシャーディング」の説明

システム管理のシャーディングと同様に、ユーザー定義のシャーディングで作成される表領域もチャンクに割り当てられます。ただし、SDBにシャードを追加したときに、チャンクの移行は自動的には開始しません。移行する必要がある各チャンクに対して、ユーザーがGDSCTLコマンドMOVE CHUNKを実行する必要があります。

GDSCTLコマンドSPLIT CHUNKはシステム管理のシャーディングでは、ハッシュ範囲の中央でチャンクを分割するために使用されますが、ユーザー定義のシャーディングではサポートされません。ALTER TABLE SPLIT PARTITION文を使用してチャンクを分割する必要があります。

ノート:

シャーディング方法はGDSCTL CREATE SHARDCATALOGコマンドで指定し、後から変更することはできません。

コンポジット・シャーディング

コンポジット・シャーディング方法では、コンシステント・ハッシュによりパーティション化された表のデータの異なるサブセットについて、複数のシャード領域を作成できます。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。

システム管理のシャーディングでは、コンシステント・ハッシュによるパーティション化を使用して、シャード間にデータをランダムに分散します。これは、範囲またはリストによるパーティション化を使用するユーザー定義のシャーディングと比べて、よりよいロード・バランスを実現します。ただし、システム管理のシャーディングでは、データのシャードへの割当てをユーザーが制御できません。

主キーのコンシステント・ハッシュによるシャーディングの際には、データのサブセットを異なる地理的場所に格納する、データのサブセットに異なるハードウェア・リソースを割り当てる、または高可用性と障害回復を異なる構成にするために、SDB内のデータのサブセットを区別する必要が生じることがよくあります。通常は、この区別は顧客の場所やサービスのクラスなど、別の(主キーでない)列の値に基づいて行われます。

コンポジット・シャーディングは、ユーザー定義のシャーディングとシステム管理のシャーディングの組合せで、必要に応じて両方の利点を活用できます。コンポジット・シャーディングでは、最初にデータがリストまたは範囲により複数のシャード領域にパーティション化され、次にコンシステント・ハッシュにより各シャード領域の複数のシャード間にさらにパーティション化されます。2つのレベルのシャーディングにより、各シャード領域のシャード間のバランスのとれたデータ分散を自動的に維持し、同時にシャード領域間にデータをパーティション化できます。

たとえば、高速なサーバーでホストされる3つのシャードをゴールド顧客に割り当て、低速のマシンでホストされる4つのシャードをシルバー顧客に割り当てるとします。顧客IDのコンシステント・ハッシュによるパーティション化を使用して、シャードの各セット内に顧客を分散する必要があります。

図2-7 コンポジット・シャーディング

図2-7の説明が続く
「図2-7 コンポジット・シャーディング」の説明

そのような構成には2つのシャード領域を作成する必要があります。たとえば、次のGDSCTLコマンドを使用できます。

ADD SHARDSPACE –SHARDSPACE shspace1;
ADD SHARDSPACE –SHARDSPACE shspace2;

ADD SHARD –CONNECT shard1 –SHARDSPACE shspace1;
ADD SHARD –CONNECT shard2 –SHARDSPACE shspace1;
ADD SHARD –CONNECT shard3 –SHARDSPACE shspace1;

ADD SHARD –CONNECT shard4 –SHARDSPACE shspace2;
ADD SHARD –CONNECT shard5 –SHARDSPACE shspace2;
ADD SHARD –CONNECT shard6 –SHARDSPACE shspace2;
ADD SHARD –CONNECT shard7 –SHARDSPACE shspace2;

コンポジット・シャーディングでは、他のシャーディング方法と同様に、表領域を使用してシャードへのパーティションのマッピングを指定します。シャード表のデータのサブセットを異なるシャード領域に割り当てるために、次の例に示すように、各シャード領域に個別の表領域のセットを作成する必要があります。

CREATE TABLESPACE SET tbs1 IN SHARDSPACE shspace1;
CREATE TABLESPACE SET tbs2 IN SHARDSPACE shspace2;

ユーザー定義のデータのサブセットを異なる表領域に格納するために、Oracle Shardingには、パーティションをセットにグループ化し、パーティションの各セットを表領域のセットと関連付ける構文が用意されています。パーティション・セットのサポートは、論理的には、コンシステント・ハッシュによるパーティション化の上位に実装される高レベルのパーティション化に相当すると考えることができます。

次の例に示す文では、サービスのクラスに基づいて、シャード表を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)
;

ノート:

Oracle Database 12cリリース2では、表の単一のパーティション・セットのみをシャード領域に格納できます。

シャーディング方法はGDSCTL CREATE SHARDCATALOGコマンドで指定し、後から変更することはできません。

サブパーティション化とシャーディングの使用

Oracle Shardingは表のパーティション化に基づくため、Oracle 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
;

次の図は、この文によって作成される表を示しています。

図2-8 親パーティションの表領域に格納されるサブパーティション

図2-8の説明が続きます
「図2-8 親パーティションの表領域に格納されるサブパーティション」の説明

この例では、各サブパーティションが親パーティションの表領域に格納されます。日付によってサブパーティション化されているため、サブパーティションを個別の表領域に格納して、古いデータをアーカイブしたり、読取り専用の記憶域に移動できるようにするほうが合理的です。適切な構文を次に示します。

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)
)
;

シャード・データベースのスキーマ・オブジェクト

シャーディングの利点を活用するには、1つのシャードで実行されるデータベース・リクエストの数が最大になるように、シャード・データベースのスキーマを設計する必要があります。次のトピックでは、設計を通知するシャード・データベースを形成するスキーマ・オブジェクトを定義および説明します。

シャード表

データベース表はシャード間で分割されるため、各シャードには同じ列を持つが行のサブセットが異なる表が含まれます。この方法で分割された表はシャード表と呼ばれます。

次の図は、左側の1つのデータベースに表示される大規模な表のセット(表ファミリと呼ばれる)を右側に表示される3つのシャード間で水平にパーティション化して、各シャードに赤、黄および青の行で示されるデータのサブセットを含める方法を示しています。

図2-9 シャード間への表の水平パーティション化


図2-9の説明が続きます。
「図2-9 シャード間の表の水平パーティション化」の説明

パーティションはシャーディング・キーに基づいて表領域レベルでシャード間に分散されます。キーの例として顧客ID、アカウント番号、国IDなどがあります。シャーディング・キーでは次のデータ型がサポートされています。

  • NUMBER

  • INTEGER

  • SMALLINT

  • RAW

  • (N)VARCHAR

  • (N)VARCHAR2

  • (N)CHAR

  • DATE

  • TIMESTAMP

シャード表の各パーティションが個別の表領域に存在し、各表領域が特定のシャードと関連付けられます。シャーディング方法に応じて、関連付けは自動的に確立されるか、管理者によって定義されることができます。

シャード表のパーティションが複数のシャード内に存在する場合でも、アプリケーションにとってその表は、単一データベース内のパーティション表とまったく同じように表示され、動作します。アプリケーションによって発行されたSQL文はシャードを参照する必要はなく、シャードの数およびその構成に依存することもありません。

シャード間で行をパーティション化する方法は、表のパーティション化でよく目にするSQL構文によって指定します。たとえば、次のSQL文はシャーディング・キーcust_idに基づいて、シャード間で表を水平にパーティション化したシャード表を作成します。 

CREATE SHARDED TABLE customers 
( cust_id     NUMBER NOT NULL
, name        VARCHAR2(50)
, address     VARCHAR2(250)
, region      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
;

シャード表はコンシステント・ハッシュ(スケーラブルな分散システムで一般的に使用される特殊なタイプのハッシュ・パーティション化)によりパーティション化されます。この手法は、シャード間で表領域を自動的に分散するため、データおよびワークロードが均等に分散されます。

ノート:

シャード表でのグローバル索引はサポートされていませんが、ローカル索引はサポートされています。

シャード表ファミリ

シャード表ファミリは、同様にシャーディングされた一連の表です。しばしば、データベースの表には親子関係があり、親表の主キーを参照する子表(外部キー)には参照制約があります。

このような関係でリンクされている複数の表は、通常はツリーのような構造になり、各子が1つの親を持ちます。そのような一連の表は、表ファミリと呼ばれます。表ファミリ内の親を持たない表をルート表と呼びます。1つの表ファミリに存在できるルート表は1つのみです。

表ファミリのシャーディング方法

ここでは、Customers-Orders-LineItemsスキーマを使用して表ファミリをシャーディングします。

シャーディングの前に、スキーマ内の表は次の例のようになります。3つの表に親子関係があり、Customersがルート表になります。

シャーディング前のCustomers表(ルート)

CustNo    Name       Address        Location  Class
--------- ---------- -------------- --------- ------
123       Brown      100 Main St    us3       Gold
456       Jones      300 Pine Ave   us1       Silver
999       Smith      453 Cherry St  us2       Bronze

シャーディング前のOrders表

OrderNo   CustNo   OrderDate
--------- -------- -----------
4001      123      14-FEB-2013
4002      456      09-MAR-2013
4003      456      05-APR-2013
4004      123      27-MAY-2013
4005      999      01-SEP-2013

シャーディング前のLineItems表

LineNo  OrderNo  CustNo  StockNo    Quantity
------  -------  ------  -------    --------
40011   4001     123     05683022   1
40012   4001     123     45423609   4
40013   4001     123     68584904   1
40021   4002     456     05683022   1
40022   4002     456     45423509   3
40022   4003     456     80345330   16
40041   4004     123     45423509   1
40042   4004     123     68584904   2
40051   4005     999     80345330   12

ルートであるCustomers表の顧客番号CustNoに基づいて表をシャーディングできます。次の表の例には、顧客123に関連するデータが格納されたシャードが示されています。

顧客123のデータを含むCustomers表シャード

CustNo    Name       Address        Location   Class
--------- ---------- -------------- ---------- ------
123       Brown      100 Main St    us3        Gold

顧客123のデータを含むOrders表シャード

OrderNo   CustNo   OrderDate
--------- -------- -----------
4001      123      14-FEB-2013
4004      123      27-MAY-2013

顧客123のデータを含むLineItems表シャード

LineNo  OrderNo  CustNo  StockNo    Quantity
------  -------  ------  -------    --------
40011   4001     123     05683022   1
40012   4001     123     45423609   4
40013   4001     123     68584904   1
40041   4004     123     45423509   1
40042   4004     123     68584904   2
複数の表ファミリを使用したスキーマの設計

シャード・データベース・スキーマには複数の表ファミリを含めることができます。この場合、異なる表ファミリのデータはすべて同じチャンクに存在し、チャンクには同じハッシュ・キー範囲を共有する異なる表ファミリからのパーティションが含まれます。

ノート:

複数の表ファミリは、システム管理のシャード・データベースでのみサポートされます。コンポジットおよびユーザー定義のシャード・データベースでは、1つの表ファミリのみがサポートされます。

新しい表ファミリを作成するには、ルート・シャード表を作成し、既存の表領域ファミリで使用されない表領域セットを指定します。各表ファミリは、ルート表によって識別されます。異なる表ファミリの表は、互いに関連付けないでください。

各表ファミリには独自のシャーディング・キー定義が必要ですが、子表に同じシャーディング・キー列があるという同じ制限が各表ファミリ内で当てはまります。つまり、異なる表ファミリからのすべての表は、コンシステント・ハッシュと同じ方法で同じ数のチャンクにシャーディングされ、各チャンクにはすべての表ファミリからのデータが含まれます。

異なる表ファミリ間で問い合せるような表ファミリは最小限になるように設計し、シャーディング・コーディネータでのみ実行されるようにします。このような結合の多くはパフォーマンスに影響するためです。

次の例は、システム管理シャーディング方式(PARTITION BY CONSISTENT HASH)でPARENT句を使用して複数の表ファミリを作成する方法を示しています。 

CREATE SHARDED TABLE Customers <=== Table Family #1
( CustId NUMBER NOT NULL
, Name VARCHAR2(50)
, Address VARCHAR2(250)
, region VARCHAR2(20)
, class VARCHAR2(3)
, signup DATE
)
PARTITION BY CONSISTENT HASH (CustId)
PARTITIONS AUTO
TABLESPACE SET ts1
;

CREATE SHARDED TABLE Orders
( OrderNo NUMBER
, CustId NUMBER
, OrderDate DATE
)
PARENT Customers
PARTITION BY CONSISTENT HASH (CustId)
PARTITIONS AUTO
TABLESPACE SET ts1
;

CREATE SHARDED TABLE LineItems
( LineNo NUMBER
, OrderNo NUMBER
, CustId NUMBER
, StockNo NUMBER
, Quantity NUMBER
)
)
PARENT Customers
PARTITION BY CONSISTENT HASH (CustId)
PARTITIONS AUTO
TABLESPACE SET ts1
;

CREATE SHARDED TABLE Products <=== Table Family #2
( ProdId NUMBER NOT NULL,
  CONSTRAINT pk_products PRIMARY KEY (ProdId)
)
PARTITION BY CONSISTENT HASH (ProdId)
PARTITIONS AUTO
TABLESPACE SET ts_2
;

ノート:

表ファミリに表領域セットを使用しようとし、その表領域セットが既存の表ファミリですでに使用されている場合、ORA-3850がスローされます。

表ファミリ間の結合は効率がよくないこともあるため、そのような結合が多数ある場合、またはパフォーマンスが重視されている場合は、複数の表ファミリではなく重複表を使用する必要があります。

グローバル・サービスと複数の表ファミリの関連付け

各表ファミリは、異なるグローバル・サービスに関連付ける必要があります。異なる表ファミリからのアプリケーションにはそれぞれ独自の接続プールおよびサービスがあり、適切なシャードにルーティングするために独自のシャーディング・キーを使用します。

最初のルート表(つまり、最初の表ファミリ)を作成すると、すべての既存のグローバル・サービスがその表に自動的に関連付けられます。この例に示すように、GDSCTL MODIFY SERVICEコマンドを使用して、表ファミリの作成後に、表ファミリに関連付けられているサービスを変更できます。 

GDSCTL> MODIFY SERVICE –GDSPOOL shdpool –TABLE_FAMILY sales.customer -SERVICE sales

重複表

Oracle Shardingでは、各シャードに同じ内容の表を重複表と呼びます。

多くのアプリケーションの場合、単一のシャードで処理されるデータベース・リクエストの数は、すべてのシャードに読取り専用またはほぼ読取り専用の表を複製することによって最大化できます。この方法は、頻繁には更新されず、シャード表とともにアクセスされることが多い比較的小さい表に適しています。重複表は、シャード表よりも更新頻度が低い傾向があり、それほど大きくなるとは想定されません。

シャード・データベースには、シャード間で水平にパーティション化されたシャード表、およびすべてのシャードにレプリケートされる重複表が含まれています。重複表には参照情報が含まれています(たとえば、各シャードで共通のStock Items表)。シャード表と重複表の組合せによって、シャーディング・キーに関連付けられているすべてのトランザクションを単一のシャードで処理できます。この技法によって、線形のスケーラビリティおよび障害の分離が可能になります。

重複表が必要な例として、シャード表ファミリで説明される表ファミリを取り上げます。データベース・スキーマにはProducts表も含まれる可能性があり、この表には、この表ファミリに対して作成されたシャード内のすべての顧客が共有するデータが含まれますが、顧客番号でシャーディングすることはできません。注文処理中のマルチシャード問合せを回避するため、表全体をすべてのシャードに複製する必要があります。

シャード表(Customers、OrdersおよびLineItems)と重複表(Products)の違いを次の図に示します。

図2-10 シャード・データベースのシャード表と重複表

図2-10の説明が続きます
「図2-10 シャード・データベースのシャード表と重複表」の説明

すべてのシャードに作成される表以外のオブジェクト

重複表に加えて、他のスキーマ・オブジェクト(ユーザー、ロール、ビュー、索引、シノニム、ファンクション、プロシージャ、パッケージなど)および非スキーマ・データベース・オブジェクト(表領域、表領域セット、ディレクトリ、コンテキストなど)をすべてのシャードに作成できます。

CREATE文に追加のキーワード(SHARDEDまたはDUPLICATED)が必要となる表と異なり、他のオブジェクトは既存の構文を使用してすべてのシャードに作成します。唯一の要件は、SHARD DDLセッション・プロパティを有効にする必要があることです。

すべてのシャードでの次のオブジェクトの自動作成は、このリリースではサポートされません。これらのオブジェクトは、個別のシャードに接続することによって作成できます。

  • クラスタ

  • 制御ファイル

  • データベース・リンク

  • ディスク・グループ

  • エディション

  • フラッシュバック・アーカイブ

  • マテリアライズド・ゾーン・マップ

  • アウトライン

  • Pfile

  • プロファイル

  • リストア・ポイント

  • ロールバック・セグメント

  • サマリー

Oracle Database 18c以降では、マテリアライズド・ビューとビュー・ログがサポートされますが、次の制限事項があります。

  • シャード表に対して作成されたマテリアライズド・ビューは、カタログ・データベースでは空のままですが、シャード上の対応するマテリアライズド・ビューには個々のシャードのデータが含まれています。

  • シャード表のマテリアライズド・ビューでは、REFRESH COMPLETE ON DEMAND USING TRUSTED CONSTRAINTSオプションのみがサポートされます。

シャード・レベルの高可用性

Oracle Shardingは、シャード・レベルの高可用性と障害回復のためにOracle Databaseレプリケーション・テクノロジに統合されています。

次の各項で、Oracleのレプリケーション・テクノロジを使用してシャード・データベースの高可用性を実現する方法を説明します。

シャーディングとレプリケーションについて

Oracle Shardingは、Oracleのレプリケーションおよび障害時リカバリ・テクノロジであるOracle Data GuardおよびOracle GoldenGateと緊密に統合されています。

ノート:

Oracle ShardingのOracle GoldenGateレプリケーション・サポート高可用性は、Oracle Database 21cでは非推奨です。

レプリケーションによって高可用性、障害回復、および読取りのスケーラビリティ向上が実現します。レプリケーションの単位にはシャード、シャードの一部またはシャードのグループがあります。

シャード・データベースのレプリケーション・トポロジは、GDSCTLコマンド構文を使用して宣言的に指定します。2つのテクノロジ(Oracle Data GuardとOracle GoldenGate)のいずれかを選択して、データをレプリケートできます。Oracle Shardingは指定されたレプリケーション・トポロジを自動的にデプロイし、データ・レプリケーションを有効にします。

シャード・データベースの可用性は、1つ以上のシャードが停止したり、処理速度が低下しても影響されません。個別のシャードレベルの高可用性(Oracle Active Data GuardまたはOracle GoldenGate)を提供するために、レプリケーションが使用されます。レプリケーションはシャード・データベースが作成されると自動的に構成およびデプロイされます。オプションで、シャードレベルの高可用性のために、レプリケーションによって補完されるOracle RACを使用すると、クラスタが停止した場合にシャードレベルのデータの可用性を維持できます。Oracle Shardingは、計画外の停止が発生したときに、データベース接続をシャードからレプリカに自動的にフェイルオーバーします。

シャード・データベースでのOracle Data Guardの使用

Oracle Data Guardのレプリケーションは、高可用性およびデータ保護のために、シャード(プライマリ)の1つ以上の同期されたコピー(スタンバイ)を維持します。スタンバイはローカルまたはリモートにデプロイでき、Oracle Active Data Guardを使用する場合は、読取り専用アクセスでオープンすることもできます。

Oracle Data Guardは、シャーディング方法としてシステム管理、ユーザー定義またはコンポジットを使用するシャード・データベースのレプリケーション・テクノロジとして使用できます。

システム管理のシャード・データベースでのOracle Data Guardの使用

システム管理またはコンポジットのシャーディングの場合、レプリケーションの論理単位はシャードグループと呼ばれるシャードのグループです。システム管理のシャーディングの場合、シャード・データベースに格納されるすべてのデータがシャードグループに含まれます。データはシャードグループを構成するシャード間で、均一なハッシュによってシャードされます。シャードグループに属するシャードは通常、同じデータ・センターにあります。シャードグループ全体を、同じまたは異なるデータ・センターの1つ以上のシャードグループに完全にレプリケートできます。

次の図は、システム管理シャーディングとともにData Guardレプリケーションが使用される方法を示しています。図に示す例には、プライマリ・シャードグループのShardgroup 1、および2つのスタンバイ・シャードグループのShardgroup 2とShardgroup 3があります。Shardgroup 1はData Guardプライマリ・データベース(シャード1-3)から構成されます。Shardgroup 2は、同じデータ・センターに存在し、同期レプリケーション用に構成されたローカル・スタンバイ・データベース(シャード4-6)から構成されます。Shardgroup 3は、異なるデータ・センターに存在し、非同期レプリケーション用に構成されたリモート・スタンバイ(シャード7-9)から構成されます。この構成ではOracle Active Data Guardが有効なため、各スタンバイが読取り専用でオープンされています。

図2-11 Data Guardレプリケーションを使用するシステム管理のシャーディング

図2-11の説明が続きます
「図2-11 Data Guardレプリケーションを使用するシステム管理シャーディング」の説明

レプリケーションの論理単位としてのシャードグループという概念によって、レプリケーションの実装の詳細がユーザーには隠されています。Data Guardの場合、レプリケーションはシャード(データベース)のレベルで実行されます。前の図のシャード・データベースは、レプリケートされた3つのシャードのセット({1, 4, 7}、{2, 5, 8}および{3, 6, 9})で構成されています。レプリケートされたシャードの各セットは、ファスト・スタート・フェイルオーバー(FSFO)が有効なData Guard Broker構成として管理されます。

レプリケーションをデプロイするには、シャードグループのプロパティ(リージョン、ロールなど)を指定し、そこにシャードを追加します。Oracle ShardingによってData Guardが自動的に構成され、レプリケートされたシャードの各セットに対してFSFOオブザーバが起動されます。さらに、読取り専用ワークロード、ロール・ベースのグローバル・サービス、レプリケーション・ラグのロード・バランシング、および地域ベースのルーティングが提供されます。

次のGDSCTLコマンドを実行して、前の図に示されている構成例をデプロイします。

CREATE SHARDCATALOG –database host00:1521:shardcat –region dc1,dc2

ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:shardcat –region dc1
ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:shardcat –region dc2
START GSM -gsm gsm1
START GSM -gsm gsm2

ADD SHARDGROUP -shardgroup shardgroup1 -region dc1 -deploy_as primary 
ADD SHARDGROUP -shardgroup shardgroup2 -region dc1 -deploy_as active_standby 
ADD SHARDGROUP -shardgroup shardgroup3 -region dc2 -deploy_as active_standby 

CREATE SHARD -shardgroup shardgroup1 -destination host01 -credential oracle_cred 
CREATE SHARD -shardgroup shardgroup1 -destination host02 -credential oracle_cred 
CREATE SHARD -shardgroup shardgroup1 -destination host03 -credential oracle_cred 
...
CREATE SHARD -shardgroup shardgroup3  -destination host09 -credential oracle_cred

DEPLOY

ユーザー定義のシャード・データベースでのOracle Data Guardの使用

ユーザー定義のシャーディングの場合、レプリケーションの論理(および物理)単位はシャードです。シャードはシャードグループに統合されません。各シャードとそのレプリカがシャード領域を構成し、これが1つのData Guard Broker構成に対応します。シャードスペースごとに個別にレプリケーションを構成できます。異なるデータ・センターに存在する異なる数のスタンバイをシャード領域に含めることができます。Data Guardレプリケーションを使用するユーザー定義シャーディングの例を次の図に示します。

図2-12 Data Guardレプリケーションを使用するユーザー定義のシャーディング

図2-12の説明が続きます
「図2-12 Data Guardレプリケーションを使用するユーザー定義シャーディング」の説明

前の図に示されているData Guardレプリケーションを使用するユーザー定義シャード・データベースの例をデプロイするには、次のGDSCTLコマンドを実行します。

CREATE SHARDCATALOG -sharding user –database host00:1521:cat –region dc1,dc2,dc3

ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:cat –region dc1
ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:cat –region dc2
ADD GSM -gsm gsm3 -listener 1571 –catalog host00:1521:cat –region dc3
START GSM -gsm gsm1
START GSM -gsm gsm2
START GSM -gsm gsm3

ADD SHARDSPACE -shardspace shardspace_a 
ADD SHARDSPACE -shardspace shardspace_b
ADD SHARDSPACE -shardspace shardspace_c

CREATE SHARD -shardspace shardspace_a –region dc1 -deploy_as primary  -destination 
host01 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

CREATE SHARD -shardspace shardspace_a –region dc1 -deploy_as standby  -destination 
host04 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

CREATE SHARD -shardspace shardspace_a –region dc2 -deploy_as standby  -destination 
host06 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

CREATE SHARD -shardspace shardspace_a –region dc3 -deploy_as standby  -destination 
host08 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

CREATE SHARD -shardspace shardspace_b –region dc1 -deploy_as primary  -destination 
host08 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rs
...

CREATE SHARD -shardspace shardspace_c –region dc3 -deploy_as standby  -destination 
host10 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

DEPLOY

コンポジット・シャード・データベースでのOracle Data Guardの使用

コンポジット・シャーディングの場合、ユーザー定義のシャーディングと同様にシャード・データベースが複数のシャード領域から構成されます。ただし、各シャード領域には、レプリケートされたシャードではなくレプリケートされたシャードグループが含まれます。

図2-13 複合シャーディングとData Guardレプリケーション

図2-13の説明が続きます
「図2-13 複合シャーディングとData Guardレプリケーション」の説明

次のGDSCTLコマンドを実行して、前の図に示されている構成例をデプロイします。

CREATE SHARDCATALOG -sharding composite –database host00:1521:cat –region dc1,dc2,dc3

ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:cat –region dc1
ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:cat –region dc2
ADD GSM -gsm gsm3 -listener 1571 –catalog host00:1521:cat –region dc3
START GSM -gsm gsm1
START GSM -gsm gsm2
START GSM -gsm gsm3

ADD SHARDSPACE -shardspace shardspace_a 
ADD SHARDSPACE -shardspace shardspace_b

ADD SHARDGROUP -shardgroup shardgroup_a1 –shardspace shardspace_a -region dc1 
-deploy_as primary 
ADD SHARDGROUP -shardgroup shardgroup_a2 –shardspace shardspace_a -region dc1     
-deploy_as active_standby
ADD SHARDGROUP -shardgroup shardgroup_a3 –shardspace shardspace_a -region dc3     
-deploy_as active_standby 
ADD SHARDGROUP -shardgroup shardgroup_b1 –shardspace shardspace_b -region dc1 
-deploy_as primary 
ADD SHARDGROUP -shardgroup shardgroup_b2 –shardspace shardspace_b -region dc1     
-deploy_as active_standby 
ADD SHARDGROUP -shardgroup shardgroup_b3 –shardspace shardspace_b -region dc2     
-deploy_as active_standby 

CREATE SHARD -shardgroup shardgroup_a1 -destination host01 –credential orcl_cred  
...

CREATE SHARD -shardgroup shardgroup_b3 -destination host09 -credential orcl_cred 

DEPLOY

シャード・データベースでのOracle GoldenGateの使用

Oracle GoldenGateは、すべてのシャードが書込み可能で、各シャードをシャードグループ内の別のシャードに部分的にレプリケートできるファイングレイン・アクティブ-アクティブ・レプリケーションのために使用されます。

ノート:

Oracle Database 21cでは、マルチテナント・アーキテクチャ(CDB)のみがサポートされます。Oracle GoldenGateバージョン12.3-19.1では、単一インスタンスのOracleデータベース(リリース11gから19c)を使用したOracle Shardingのみがサポートされます。

Oracle GoldenGateでは、レプリケーションがチャンク・レベルで処理されます。たとえば、次の図のShardgroup 1では、各シャードに格納されているデータの半分が1つのシャードにレプリケートされ、残りの半分が別のシャードにレプリケートされます。いずれかのシャードが使用できなくなった場合、そのワークロードはシャードグループ内の他の2つのシャードに分割されます。フェイルオーバー先が複数存在し、障害が発生したシャードのすべてのワークロードを1つのシャードで処理する必要がないため、シャード障害の影響が軽減されます。

図2-14 GoldenGateレプリケーションを使用するシステム管理シャーディング

図2-14の説明が続きます
「図2-14 GoldenGateレプリケーションを使用するシステム管理シャーディング」の説明

Oracle GoldenGateレプリケーションでは、シャードグループにシャード表内の各行の複数のレプリカを含めることができるため、シャードグループ内に高可用性が提供され、Data Guardレプリケーションの場合のようにシャードグループのローカル・レプリカを作成する必要はありません。シャードグループ内で各行がレプリケートされる回数は、シャードグループのレプリケーション・ファクタと呼ばれ、構成可能なパラメータです。

障害時リカバリ機能を提供するため、シャードグループを1つ以上のデータ・センターにレプリケートできます。シャードグループの各レプリカは、異なる数のシャード、レプリケーション・ファクタ、データベース・バージョンおよびハードウェア・プラットフォームを持つことができます。ただし、レプリケーションはチャンク・レベルで実行されるため、すべてのシャードグループ・レプリカが同じ数のチャンクを持つ必要があります。

前の図のShardgroup 2は、Shardgroup 1と同じデータを含んでいますが、異なるデータ・センターにあります。どちらのデータ・センターのシャードも書込み可能です。どちらのシャードグループでもデフォルトのレプリケーション・ファクタ(2)が使用されます。

Shardgroup 2には2つのシャードのみが含まれており、レプリケーション・ファクタが2であるため、シャードは完全にレプリケートされており、シャード・データベースに格納されているすべてのデータが各シャードに含まれています。これは、シャード間を移動せずにこれらのシャードにルーティングされた問合せを実行できることを意味します。このシャードグループにはフェイルオーバー先が1つしかないため、シャードが停止した場合、他のシャードへの負荷が2倍になります。

Oracle Shardingは、異なるシャードの同じ行に対して実行される競合更新の数が最小限になるように設計されています。これは、ハッシュ値の範囲ごとにマスター・チャンクを指定し、対応するデータのほとんどのリクエストをこのチャンクにルーティングすることで実現されます。

状態遷移(チャンクの移動や分割、シャードの起動と停止など)のために、更新の競合を避けられない場合があります。トランザクションの待機時間を最小限にするため、ユーザーが意図的に競合を発生させる場合もあります。このような場合、Oracle GoldenGateは挿入と削除の競合を含むすべての種類の競合を処理する自動的な競合検出および解決機能を提供します。

ノート:

Oracle GoldenGateでは、ユーザー定義のシャーディング方法をサポートしていません。

Oracle GoldenGateを使用するシステム管理のシャーディングの場合、シャードには2つ以上のチャンクが必要となります。

Oracle GoldenGateは、PDBをシャードとしてサポートしません。

関連項目:

Fusion MiddlewareのOracle GoldenGateマイクロサービス・アーキテクチャの使用ガイドのOracle GoldenGateシャーディングの使用(Oracle ShardingでのOracle GoldenGateの使用の詳細)

問合せ処理と問合せコーディネータ

問合せコーディネータはシャード・カタログの一部です。問合せコーディネータは、シャード・データベースに対する問合せ処理サポートを提供します。シャード・カタログのシャード・データベース・トポロジ・メタデータにアクセスすると、問合せコーディネータが重要な役割を果たす3つの一般的なケースがあります。

  1. シャーディング・キーのない単一シャード問合せ

    シャーディング・キーがアプリケーションから渡されない場合、問合せコーディネータは、問合せに必要なデータを含むシャードを特定し、そこに問合せを送信して実行します。

  2. マルチシャード問合せ

    問合せコーディネータは、SELECT COUNT(*) FROM Customerなどのマルチシャード問合せと呼ばれる複数のシャードからのデータを必要とする問合せにも役立ちます。

  3. 集計問合せ

    問合せコーディネータは、売上データの集計など、レポートで通常使用される集計問合せを処理します。

いずれの場合も、問合せコーディネータのSQLコンパイラは関連するシャードを自動的に識別し、関係するすべてのシャード間で問合せの実行を調整します。

単一シャード問合せのシナリオでは、問合せ全体が単一の参加シャードで実行され、問合せコーディネータは処理された行をクライアントに戻します。

マルチシャード問合せの場合、SQLコンパイラは問合せを分析し、参加シャードによって送信および実行される問合せフラグメントにリライトします。問合せは、関与するシャードでほとんどの問合せ処理が行われて、コーディネータによって集計されるようにリライトされます。

問合せコーディネータは、Oracle Databaseのパラレル問合せエンジンを使用して、マルチシャード問合せをシャードにパラレルに最適化およびプッシュします。各シャードは、保持するデータのサブセットに対して問合せを実行します。次に、結果が問合せコーディネータに戻され、問合せコーディネータがクライアントに返されます。

要するに、シャードは問合せコーディネータによって実行される問合せの計算ノードとして機能します。計算がデータのあるシャードにプッシュされるため、シャードとコーディネータの間のデータの移動が減少します。この仕組みによって、問合せコーディネータの処理負荷ができるだけ多くのシャードに移動するため、リソースを効率的に使用できるようになります。

一貫性レベルの指定

マルチシャード問合せでは、様々な一貫性レベルを指定できます。たとえば、一部の問合せでシャード間のSCN同期のコストを回避する必要がある場合は、それらのシャードをグローバルに分散できます。別のユース・ケースとして、レプリケーション用のスタンバイを使用している場合は、プライマリとそのスタンバイから結果がフェッチされる可能性があるため、マルチシャード問合せで少し古いデータが許容されます。マルチシャード問合せでは、すべてのシャードで最も大きい共通SCNで問合せを発行することによって、グローバルな読込み一貫性(CR)を維持する必要があります。

高可用性およびパフォーマンス

ファスト・スタート・フェイルオーバーを有効にして最大可用性保護モード(データ損失のないフェイルオーバー)でOracle Data Guardを使用して問合せコーディネータを保護することをお薦めします。問合せコーディネータはさらなる可用性およびスケーラビリティのためにオプションでOracle RAC対応にすることができます。マルチシャード問合せワークロードのスケーラビリティおよび可用性を向上させるために、読取り専用モードのOracle Active Data Guardスタンバイ・シャード・カタログ・データベースをマルチシャード問合せコーディネータとして機能させることができます。

集計ユースケースおよびシャーディング・キーを使用しないSQL実行では、直接のキーベースのルーティングに比べてパフォーマンス・レベルが低下します。

クライアント・アプリケーション・リクエストのルーティング

クライアント・アプリケーション・リクエストをシャードに直接ルーティングするには、Oracleドライバを使用してシャードに接続し、リクエストとともにシャーディング・キーを指定します。

シャーディング・キーについて

高いパフォーマンスおよび障害分離を必要とするすべてのデータベース・リクエストは、単一の値のシャーディング・キーに関連付けられているデータにのみアクセスする必要があります。データベース接続を確立するときに、アプリケーションはシャーディング・キーを渡す必要があります。これに該当する場合、リクエストは適切なシャードに直接ルーティングされます。

複数のリクエストは、それらがすべて同じシャーディング・キーに関連しているかぎり、同じセッションで実行できます。通常、そのようなトランザクションは数十行または数百行にアクセスします。単一シャードのトランザクションの例としては、オーダー入力、顧客の請求書レコードの検索と更新、およびサブスクライバのドキュメントの検索と更新があります。

複数の値のシャーディング・キーに関連付けられているデータ、またはシャーディング・キーの値が不明なデータにアクセスする必要があるデータベース・リクエストは、複数のシャードでの問合せのパラレル実行を調整する問合せコーディネータから実行する必要があります。

Oracle接続ドライバについて

実行時に、接続プールは、プールされた接続間でデータベース・リクエストをルーティングすることでシャード・ディレクタとして機能します。Oracle Databaseは、データ・アクセス・ドライバ(OCI、JDBC、ODP.NETなど)の接続プーリングをサポートしています。これらのドライバは、接続リクエストの一部として指定されたシャーディング・キーを認識できます。同様に、JDBCクライアントのOracle Universal Connection Pool (UCP)は、接続URLで指定されたシャーディング・キーを認識できます。また、Oracle UCPを使用すると、非Oracleアプリケーション・クライアント(Apache Tomcat、WebSphereなど)は、Oracle Shardingと連携できます。

OracleクライアントはUCPキャッシュのルーティング情報を使用し、アプリケーションから渡されたシャーディング・キーに基づいて、データベース・リクエストを適切なシャードに直接ルーティングします。データベース・リクエストをそのようにデータ依存でルーティングすることにより、余分なネットワークのホップが排除され、ボリュームの大きいアプリケーションのトランザクション待機時間が減少します。

ルーティング情報は、シャード・ディレクタを使用して確立されるシャードへの最初の接続時にキャッシュされます。キャッシュされた範囲内のシャーディング・キーに対する後続のデータベース・リクエストは、シャード・ディレクタをバイパスしてシャードに直接ルーティングされます。

UCPと同様に、シャード・ディレクタは接続文字列に指定されたシャーディング・キーを処理して、ルーティング情報をキャッシュできます。ただし、UCPはすでに確立されている接続を使用してデータベース・リクエストをルーティングしますが、シャード・ディレクタは接続リクエストをシャードにルーティングします。シャードが使用できなくなった場合、またはシャーディング・トポロジに変更が発生した場合、ルーティング・キャッシュは自動的にリフレッシュされます。高パフォーマンスのデータ依存のルーティングにするには、シャード・データベースのデータへのアクセス時に接続プールを使用することをお薦めします。

問合せコーディネータを介した直接ルーティングおよびルーティング・リクエストには、個別の接続プールを使用する必要があります。直接ルーティングの場合は、読取り書込みワークロードおよび読取り専用ワークロードのために、個別のグローバル・サービスを作成する必要があります。これは、Data Guardレプリケーションが使用されている場合にのみ当てはまります。プロキシ・ルーティングの場合は、シャード・カタログ・データベースでGDS$CATALOGサービスを使用します。

シャード・データベースの管理インタフェース

GDSCTLコマンドライン・ユーティリティは、Oracle Shardingシャード・データベースを構成、デプロイ、監視および管理するために使用します。Oracle Enterprise Manager Cloud Controlは、シャード・データベースの監視および管理にも使用できます。

SQL*Plusと同様に、GDSCTLは、シャード・データベースのライフ・サイクルのすべてのステージを制御できるコマンドライン・ユーティリティです。GDSCTLを別のサーバーまたはラップトップからリモートで実行してシャード・データベース・トポロジを構成およびデプロイし、シャード・データベースをモチエータおよび管理できます。

GDSCTLは、シャード・データベースの構成を指定し、そのデプロイメントを自動化する簡単な宣言的方法を提供します。わずかなGDSCTLコマンドを使用するだけで、シャード・データベースを作成できます。

グラフィカル・ユーザー・インタフェースが必要な場合は、シャード・データベースの監視およびライフ・サイクル管理にCloud Controlを使用することもできます。Cloud Controlを使用すると、可用性およびパフォーマンスを監視でき、シャード、サービス、シャード・ディレクタおよびその他のシャーディング・コンポーネントの追加およびデプロイなどのシャーディング構成を変更できます。