Oracle Globally Distributed Database 23ai: 偏ったデータを処理するためのディレクトリベースのデータ分散の概要 (2024/09/26)

Oracle Globally Distributed Database 23ai: 偏ったデータを処理するためのディレクトリベースのデータ分散の概要 (2024/09/26)

https://blogs.oracle.com/database/post/oracle-globally-distributed-database-introducing-directorybased-data-distribution-a-new-method-in-23ai

投稿者:Ajay Joshi | Consulting Member of Technical Staff

Deeksha Sehgal | Senior Product Manager


ディレクトリベースのデータ分散は、Oracle Database 23aiで導入された新機能であり、シャードでのデータの配置を制御できる、より柔軟なデータ配置および管理方法を提供することで、ユーザー定義のシャーディング方法を強化します。ディレクトリベースのデータ分散では、シャードへのキー値のマッピングを完全に制御できます。シャード・キーに関連付けられたデータ・レコードの場所は、ユーザー・プリファレンスに基づいて実行時に動的に指定されます。キーの場所情報はディレクトリ表に格納され、キー値の大きなセット(数十万単位)を保持できます。


個々のキー値をある場所から別の場所に移動したり、一括で移動してスケール・アップまたはスケール・ダウンしたり、データとロード・バランシングを行う柔軟性があります。場所情報には、シャード・データベース情報およびパーティション情報を含めることができます。



ディレクトリベースのデータ分散の概念とアーキテクチャ


次に、ディレクトリベースのデータ分散を理解するための主な概念を示します。


  • パーティションおよびシャードへのキー値のマッピングは、ディレクトリ表に格納されます。
  • ディレクトリによってシャードされた表が作成されると、ディレクトリ表はカタログおよびシャードに自動的に作成されます。
  • シャード・ディレクタ(GSM)およびクライアント側の接続プールは、ルーティングのためにディレクトリをキャッシュします。キャッシュ内のキー値は暗号化されます。
  • シャード表に行が挿入または削除されると、ディレクトリが自動的に更新されます。
  • シャード表には、パーティション情報を含む仮想列が含まれており、パーティション・プルーニングに使用されます。


次の図は、ディレクトリベースのデータ分散の主なコンポーネントを示しています。ディレクトリ表はカタログでホストされ、すべてのシャードに複製されます。シャード表は、ディレクトリ表のキー/パーティション・マッピングに基づいて、異なるシャード間に分散されます。


ディレクトリベースのデータ分散アーキテクチャ


キーの挿入および更新操作はカタログで実行され、コミット時にシャードに同期的に複製されます。


クライアント・プールは、他のシャーディング方法と同様に、各シャードからチャンク/シャードへのキー・マッピングをフェッチします。また、新しいキー・マッピングまたは削除について通知するFANイベントをサブスクライブします。



ディレクトリベースのデータ分散のユースケース


次のユース・ケースは、Globally Distributedデータベースでディレクトリベースのデータ分散方法を使用するとどのようなメリットが得られるかを示しています。


データ主権


ディレクトリベースのデータ分散は、データのローカリゼーションによってデータ主権を達成し、プライバシー違反を回避するために実装できます。データは、特定のパーティションに割り当てられたディレクトリ表内の定義済のシャーディング・キーに基づいてシャード・データベースに格納されます。クロスシャード問合せは、カタログ・データベースから実行して、すべてのシャード・データベースからデータを取得できます。したがって、アプリケーション・スーパーユーザー(データセット全体へのアクセスが必要なユーザー)は、カタログ・データベースからのレポート作成など、データ(読取り/書込み権限)を完全に制御できます。アプリケーションは、要件に基づいてカタログ・データベースに接続することも、シャードに直接接続することもできます。


データ主権のためのディレクトリベースのシャーディング



ディレクトリベースのデータ分散を実装してデータ主権を達成する方法


複数のシャーディング・キーを使用してデータ主権を達成する方法について学びましょう。ディレクトリベースのデータ分散実装では、シャーディング・キーは実行時に定義および管理できます。


ディレクトリベースのデータ分散は、ユーザー定義のシャーディングへの新しい追加であるため、ユーザー定義の共有トポロジについて理解できます。ディレクトリベースのデータ分散データベース・スキーマを実装するには、ディレクトリベースのOracle Globally Distributed Databaseのデプロイおよび管理が必要です。ディレクトリベースのデータ分散では「PARTITION BY DIRECTORY」が使用され、「PARTITION BY LIST」はユーザー定義の共有で使用されます。


シャーディング構成の検証後、Oracle Globally Distributed Databaseスキーマ設計を参照し、シャード・スキーマ・ユーザーを使用してカタログ・データベースに接続し、ディレクトリベースのデータ分散テスト用に次のサンプルDDLを実行して、想定どおりに機能することを確認できます。


A) GSMトポロジ構成で定義されているとおりに、シャード領域内の各シャードの表領域を作成します(このステップはユーザー定義のシャーディングに似ています)。


CREATE TABLESPACE TBS_USA IN SHARDSPACE shardspace_usa; 

CREATE TABLESPACE TBS_IND IN SHARDSPACE shardspace_ind; 

CREATE TABLESPACE TBS_CHN IN SHARDSPACE shardspace_chn;


B) Globally Distributed Databaseに複数のモジュール/スキーマを統合できるように、オプションのルート/親表を表ファミリの最初の表として追加できます。汎用表を親/ルート表として追加すると、そのシャーディング・キーが子表で参照されているかぎり、同じシャーディング・データ・モデル内の異なるモジュール/スキーマ表を許可できます。ディレクトリベースのデータ分散を使用してルート/親表を作成する次の例では、DIRECTORYでパーティション化し、id、ctry_cdおよびdept_idの3つのシャーディング・キーを使用しています。


CREATE SHARDED TABLE SHARD_ROOT (

    id VARCHAR2(50) NOT NULL,

    ctry_cd VARCHAR2(50) NOT NULL,

    dept_id VARCHAR2(50) NOT NULL,

    CONSTRAINT "PK_SHARD_ROOT" PRIMARY KEY ( id, ctry_cd, dept_id )

) <strong>PARTITION BY DIRECTORY</strong>( id, ctry_cd, dept_id ) ( PARTITION p1 TABLESPACE tbs_usa,

PARTITION p2 TABLESPACE tbs_ind,

PARTITION p3 TABLESPACE tbs_chn);


ここで、「PARTITION BY DIRECTORY」は、ディレクトリベースのデータ分散に使用される句です。




C)前述のステップでは、ディレクトリ表SHARD_ROOT$SDIRが自動的に作成されます。この表SHARD_ROOT$SDIRは、各シャードのパーティションで許可されるシャーディング・キーの組合せを保持します。


ディレクトリ表SHARD_ROOT$SDIRに様々なシャード(PARTITION名で区別)のデータを挿入するサンプル・コマンドを次に示します。


exec gsmadmin_internal.dbms_sharding_directory.addkeytopartition ('APP_SCHEMA', 'SHARD_ROOT', 'P1’, ‘U0001’, 'USA’, 'USA_DEPT_001' );

exec gsmadmin_internal.dbms_sharding_directory.addkeytopartition ('APP_SCHEMA', 'SHARD_ROOT', ‘P2’, ‘I4001’, ‘IND’, ‘IND_DEPT_401' );

exec gsmadmin_internal.dbms_sharding_directory.addkeytopartition ('APP_SCHEMA', 'SHARD_ROOT', ‘P3, ‘C7001’, ‘CHN’, ‘CHN_DEPT_701' ); commit;


SHARD_ROOT$SDIRのシャーディング・キーは、アプリケーションによって追加/更新/削除することも、カタログ・データベースから手動で削除することもできます。




D)ディレクトリ表SHARD_ROOT$SDIRから選択するには:


SELECT * FROM SHARD_ROOT$SDIR ORDER BY ID;


E)ディレクトリベースのデータ分散の場合は、親のSHARD_ROOT表に対する子表を作成します。


CREATE SHARDED TABLE CUSTOMERS (

    cust_id VARCHAR2(50) NOT NULL,

    shard_root_id VARCHAR2(50) NOT NULL,

    ctry_cd VARCHAR2(50) NOT NULL,

    dept_id VARCHAR2(50) NOT NULL,

    status VARCHAR2(10) NOT NULL,

CONSTRAINT PK_SHARD_ROOT PRIMARY KEY (cust_id, shard_root_id, ctry_cd, dept_id),

CONSTRAINT FK_CUSTOMERS  FOREIGN KEY (shard_root_id, ctry_cd, dept_id)

<strong>REFERENCES  SHARD_ROOT</strong>(id, ctry_cd, dept_id) ON DELETE CASCADE

) PARTITION BY REFERENCE (FK_CUSTOMERS);


F)表ファミリSHARD_ROOTの最初のシャード表に挿入します。


insert into shard_root (id, ctry_cd, dept_id)) values (‘U0001', 'USA’, 'USA_DEPT_001');

commit;


G)子表(最初のビジネス関連のシャード表の例)に挿入します。


insert into CUSTOMERS (cust_id, shard_root_id, ctry_cd, dept_id,status) values ('USA_000001', ‘U0001 ', 'USA’, 'USA_DEPT_001','active') ;

insert into CUSTOMERS (cust_id, shard_root_id, ctry_cd, dept_id,status) values ('IND_400001', ‘I4001’', 'IND’, 'IND_DEPT_401','active') ;

insert into CUSTOMERS (cust_id, shard_root_id, ctry_cd, dept_id,status) values ('CHN_700001', ‘C7001’', 'CHN’, 'CHN_DEPT_701','active') ;

commit;


H)各データベース(カタログ、shard1、shard2、shard3など)に接続し、次の問合せを実行してレコードを検証します。


Select count(1) from CUSTOMERS;


カタログ問合せは、すべてのシャードからデータを取得します。したがって、この問合せでは、カタログ・データベースから合計3件のレコードが提供されます。シャーディング・キーを照合するためにシャードにデータが保持されるため、3つのシャード・データベースのそれぞれから1件のレコードが取得されます。


この例では、異なるシャーディング・キーの組合せを使用して異なるリージョンに基づいてデータを永続化するために、ディレクトリベースのデータ分散を使用してデータ主権を達成できることを確認できます。



アプリケーション/バッチ・プログラムによる実行時におけるシャーディング・キーの定義


ディレクトリベースの配布では、Java、Python、PL/SQLなどの任意の言語で、アプリケーションまたはスタンドアロン・バッチ・プログラムによって実行時にシャーディング・キーを定義できます。ここでは、特定のパーティションに5つのシャーディング・キーを追加するJavaコード・スニペットを示します。このキーは、実行時にパラメータ化することもできます。


try {

             Connection con = datasource.getConnection();

             for (int i = 0; i < 5; i++) {

                 String addkeytopartitionParams = "begin gsmadmin_internal.dbms_sharding_directory.addkeytopartition(?,?,?,?,?,? ); end;";

                 CallableStatement callStmtParams = con.prepareCall(addkeytopartitionParams);

                  callStmtParams.setString(1, "APP_SCHEMA");

                  callStmtParams.setString(2, "SHARD_ROOT"); callStmtParams.setString(3, "P1");

                  String id = "U" + 0101 + i;  callStmtParams.setString(4, id);

                  callStmtParams.setString(5, "USA");      callStmtParams.setString(6, "USA_DEPT_001");

                  callStmtParams.execute();

            }

      } catch (Exception e) { 

             e.printStackTrace();

         }

前述のコード・スニペットでは、実行時にパラメータを提供するためにaddkeytopartition()プロシージャがコールされ、その形式は次のとおりです。


DBMS_SHARDING_DIRECTORY.addKeyToPartition(

   (schema_name IN varchar2,

    parent_root_table IN varchar2,

    partition_name IN varchar2,

    sharding_keys_comma_ separated_1,..n … );


ここで、sharding_keysは英数字にできます。これは、シャーディング・キーをプログラムで管理するために非常に役立ちます。



また、ディレクトリベースのデータ分散は、次の場合に使用できます。


  • 多数のビジネス顧客アカウントのデータを管理するB2Bアプリケーション。
    • たとえば、多くの自動車ディーラーのデータをホストおよび管理するディーラ・アプリケーションです。さらに、異なるディーラーのデータ量は大幅に異なる場合があります。あるディーラーは大規模なオペレーションを、他のディーラーははるかに小さいです。また、アプリケーション固有の基準に基づいて、ディーラごとに異なるリソース/ロケーションを指定する必要がある場合もあります。
  • アフィニティーのために特定のキー値を同じ場所またはチャンクにグループ化する必要があるアプリケーション。また、必要に応じてこのグループを効率的に一緒に移動できます。
    • たとえば、ソーシャル・ネットワーク・アプリケーションでは、同じシャードでメッセージを交換することが多い顧客をグループ化すると、シャード間のトラフィックが最小限に抑えられます。シャード間でデータを移動する場合は、グループ化を保持する必要があります。一方、グループのメンバーが別のグループのメンバーとのより多くの通信を開始した場合、そのデータをアプリケーションへの影響を最小限に抑えながら適切なグループに移動できます。



ディレクトリベースのデータ分散の利点:


  • シャーディング・キーが同じであるかぎり、任意の数の表、スキーマおよびアプリケーション・モジュールを統合できます。これは、シャーディング構成ではシャーディング・キーを使用して、ディレクトリベースのデータ分散を使用して階層データ・モデル内の表を関連付けるためです。
  • 同じスキーマ・モデルを、異なるパーティションおよび複数のシャードを使用するディーラ/ベンダー・アプリケーションに使用できます。
  • 仮想プライベート・データベース(VPD)をディレクトリベースのデータ分散とともに使用して、データの分散とアクセスのために、さまざまな国や地域内のデータのセキュリティと分離を強化できます。
  • アプリケーション・スーパーユーザー(データセット全体へのアクセスが必要なユーザー)は、散布/収集やレポート作成などのニーズのためにカタログ・データベースからデータにアクセスできます。また、スーパーユーザー以外(シャーディング・キーに基づいて特定のシャードにアクセスする必要があるユーザー)には、特定の国/地域/部門などのシャーディング・キーに対する特定のデータ・パーティションに基づくアクセス権を付与できます。
  • 地理的に分散したデータベースでのデータ移動ではなく、アプリケーション自体からデータを分散および制御できるため、日々のトランザクションに対するデータベース管理タスクが削減されます。
  • ディレクトリベースのデータ分散により、スケーラビリティ、ディザスタ・リカバリ、ゼロ・ダウンタイム、データ損失ゼロなど、様々なアプリケーション・ニーズを満たすグローバルに分散したデータベース実装が可能になります。


その他のリソース:

コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

Oracle GoldenGate 23aiでMicrosoft Fabricでのオープン・ミラーリングがサポートされるようになりました (2024/11/19)

Oracle APEX 24.1の一般提供の発表 (2024/06/17)