Hitachi

Hitachi Advanced Data Binder システム構築・運用ガイド


11.4.23 バックグラウンドインポートとチャンクを意識した運用例1(定期的にデータの追加と削除を繰り返す運用)

バックグラウンドインポートとチャンクを意識した運用例について説明します。バックグラウンドインポートを使用すると,次に示すような定期的にデータの追加と削除を繰り返す運用ができます。

ここでは,A社の運用例を基に説明します。

■A社の運用例

全国に約1,000の支店を持つA社では,商品の購買履歴を分析する分析システムを導入しています。A社の分析システムのデータベースは,次のように運用されています。

  • 全国にある約1,000の支店の購買履歴データは,分析システムのデータベースの購買履歴表で一元管理します。

  • 分析システムのデータベースには,購買履歴表だけでなく,購買履歴データ以外のマスタデータを管理する店舗表,商品表なども存在します。

  • 1日に1回,全国の各支店から購買履歴データを収集し,まとめて購買履歴表にインポートします。

  • 購買履歴表にデータをインポートしている間も,商品の購買履歴データの分析を実施します。

  • 商品の購買履歴の分析では,6か月ごと,3か月ごと,1か月ごと,1週間ごと,1日ごとの購買履歴をそれぞれ分析します。

  • システムの検索性能を維持するために,直近1か月分の購買履歴データを毎月1つのチャンクにマージします(チャンク数の増加を抑えます)。

  • A社の分析業務では,過去6か月分の購買履歴データを必要とします。そのため,購買履歴データが格納されている購買履歴表には,過去6か月分のデータを格納する運用とします。

  • 購買履歴表のデータ容量の増加を抑えるため,6か月より前のデータはバックアップを取得してから削除します。

  • 購買履歴表のデータのバックアップは,月単位で取得します。

  • 購買履歴データの内容に誤りがある場合は,データを修正します。

■分析システムのデータベースのスキーマモデル

A社で運用する分析システムのデータベースのスキーマモデルを,次の図に示します。

図11‒26 A社で運用する分析システムのデータベースのスキーマモデル

[図データ]

[説明]
  • 上記のスタースキーマの場合,購買履歴表(PURCHASE)がファクト表になります。購買履歴表は,データインポートが毎日実行され,その間も分析業務による検索で使用されます。データインポートと表の検索を同時に実行するため,購買履歴表はマルチチャンク表として定義します。また,分析業務では,特定のデータに対する値の集計(平均や合計などを求める)が多いため,購買履歴表はカラムストア表として定義します。「(3) 新しいデータの追加(バックグラウンドインポート)」以降では,この購買履歴表の運用について説明しています。

  • 購買履歴データ以外のマスタデータを管理するために,店舗表(SHOPLIST),商品表(ITEMLIST),顧客表(CUSTOMER),および取引時間表(TRADETIME)を定義します。これらの表は,スタースキーマのディメンジョン表になります。これらの表は,シングルチャンク表かつローストア表として定義します。

■購買履歴表(PURCHASE)に関する運用の流れ

購買履歴表に関する運用の流れを,次の図に示します。

図11‒27 購買履歴表に関する運用の流れ

[図データ]

〈この項の構成〉

(1) 更新行のカラム化機能の有効化

カラムストア表である購買履歴表(PURCHASE)に対して,UPDATE文でデータを更新することがあるため,adbcolumnizeコマンドを実行して更新行のカラム化機能を有効にします。

■コマンドの実行例
adbcolumnize --start
メモ

カラムストア表に対してUPDATE文またはINSERT文を実行すると,更新または追加されたデータはローストア形式で格納されるため,カラムストア表の検索性能の低下の原因になります。更新行のカラム化機能を有効にすると,ローストア形式で格納されたデータをカラムストア形式にHADBが自動的に変換するため,カラムストア表の検索性能の低下を防止できます。

(2) 分析システムのデータベースの定義

各支店の購買履歴データを購買履歴表で一元管理するために,購買履歴表(PURCHASE)を定義します。また,購買履歴表にレンジインデクスを定義します。

購買履歴データ以外のマスタデータを管理するために,次の4つの表も定義します。

(a) 購買履歴表(PURCHASE)の定義

購買履歴表(PURCHASE)は,次のように定義します。

  • 購買履歴表に対してバックグラウンドインポートを実行するため,購買履歴表はマルチチャンク表として定義します。

  • 購買履歴表はスタースキーマのファクト表とするため,購買履歴表はカラムストア表として定義します。

  • 購買履歴表は,DBエリアTBLDAT_001に格納します。

  • 購買履歴表のチャンクの最大数は44にします。見積もり方法を次に示します。

■購買履歴表のチャンクの最大数の見積もり方法

購買履歴表には,過去6か月分のデータを格納します。それを踏まえて,CREATE TABLE文のチャンク指定に指定するチャンク数の最大値を見積もります。

1か月を31日とすると,月に31回バックグラウンドインポートを実行するので,必要なチャンク数は31となります。残り5か月分については,検索性能を維持するために,毎月1つのチャンクにまとめることで,チャンク数を抑えるようにします。

安全率を1.2とすると,作成されるチャンク数の最大値は次の値となります。

作成されるチャンク数の最大値= ↑(31+5)×1.2(安全率)↑= 44
メモ

チャンク数が増加すると検索性能に影響を与えます。そのため,使用するチャンク数をできるだけ抑えるように,設計・運用することを推奨します。

この見積もりによって,チャンク数の最大値には44を設定します。この値をCREATE TABLE文のチャンク指定のCHUNKに指定します。購買履歴表を定義するCREATE TABLE文の指定例を次に示します。

■CREATE TABLE文の指定例
CREATE TABLE "PURCHASE"
            ("SHOP_ID"     INTEGER,
             "TRADE_TIME"  TIMESTAMP,
             "ITEM_ID"     INTEGER,
             "ITEM_NAME"   VARCHAR(100),
             "CUSTOMER_ID" INTEGER,
             "PURCHASE_ID" CHAR(8))
    IN "TBLDAT_001"
    CHUNK=44                                ...1
    STORAGE FORMAT COLUMN                   ...2
[説明]
  1. チャンク数の最大値を指定します。この指定をすると,購買履歴表がマルチチャンク表として定義されます。

  2. この指定をすると,購買履歴表がカラムストア表として定義されます。

CREATE TABLE文については,マニュアルHADB SQLリファレンス定義系SQLCREATE TABLE(表の定義)を参照してください。

(b) 購買履歴表(PURCHASE)に対するレンジインデクスの定義

購買履歴表(PURCHASE)に対して,レンジインデクスを定義します。レンジインデクスはDBエリアRIXDAT_001に格納するように定義します。

取引時間(TRADE_TIME列)に対してレンジインデクスを定義します。レンジインデクスを定義するCREATE INDEX文の指定例を次に示します。

CREATE INDEX文の指定例
CREATE INDEX "TRADE_TIME_RIX"
   ON "PURCHASE"("TRADE_TIME") IN "RIXDAT_001" 
      EMPTY INDEXTYPE RANGE

CREATE INDEX文については,マニュアルHADB SQLリファレンス定義系SQLCREATE INDEX(インデクスの定義)を参照してください。

(c) 購買履歴表(PURCHASE)以外の表の定義

購買履歴データ以外のマスタデータを管理するために,次の表も定義します。

  • 店舗表(SHOPLIST

  • 商品表(ITEMLIST

  • 顧客表(CUSTOMER

  • 取引時間表(TRADETIME

上記の表は,次のように定義します。

  • 上記の表に対しては,バックグラウンドインポートを実行しないため,シングルチャンク表として定義します。

  • 上記の表はスタースキーマのディメンジョン表とするため,ローストア表として定義します。

  • 上記の表は,それぞれDBエリアTBLDAT_002TBLDAT_005に格納するように定義します。

  • 上記の表の次に示す列に対して,それぞれB-treeインデクスを定義します。B-treeインデクスは,それぞれDBエリアIDXDAT_002IDXDAT_005に格納するように定義します。

    • 店舗表(SHOPLIST)の支店コード(SHOP_ID列)

    • 商品表(ITEMLIST)の商品ID(ITEM_ID列)

    • 顧客表(CUSTOMER)の顧客番号(CUSTOMER_ID列)

    • 取引時間表(TRADETIME)の取引時間(TRADE_TIME列)

(d) この運用例で使用する表のイメージ

この運用例で使用する購買履歴表(PURCHASE)のイメージを,次の図に示します。

図11‒28 この運用例で使用する購買履歴表(PURCHASE)のイメージ

[図データ]

(3) 新しいデータの追加(バックグラウンドインポート)

1日に1回,全国の各支店から収集した新しい購買履歴データを,購買履歴表(PURCHASE)に追加します。

新しいデータの追加は,バックグラウンドインポートで実行します。1回のバックグラウンドインポートでマルチチャンク表に格納したデータ,およびそのインデクスは,1つの固まり(チャンク)として管理されます。チャンクについては,「2.14.2 データインポート単位のデータ管理(チャンク)」を参照してください。

メモ

データをチャンク単位で管理することで,チャンク単位でのバックアップの取得や,データの削除ができます。バックグラウンドインポートやチャンクのマージの際に,チャンクに対してコメントを設定できます。コメントを設定しておくと,管理対象とするチャンクを特定しやすくなります。

バックグラウンドインポートには,-bオプションを指定したadbimportコマンドを使用します。adbimportコマンドの実行例を次に示します。

■コマンドの実行例
adbimport -u ADBUSER01 -p '#HelloHADB_01' -k "'" -s , -g 10
          -w /home/adbmanager/tmp
          -z /home/adbmanager/imp_file/imp_opt_file01.txt
          -b -m 'January 2014_daily'
          PURCHASE
          /home/adbmanager/imp_file/imp_data_path01.txt
[説明]

購買履歴表(PURCHASE)に対して,入力データパスファイル(/home/adbmanager/imp_file/imp_data_path01.txt)に設定した入力データファイルの内容をバックグラウンドインポートします。

adbimportコマンドについては,マニュアルHADB コマンドリファレンスadbimport(データのインポート)を参照してください。また,「11.4.2 マルチチャンク表にデータを格納する方法(バックグラウンドインポート)」も参照してください。

(4) バックグラウンドインポートしたデータの修正

(3) 新しいデータの追加(バックグラウンドインポート)」でバックグラウンドインポートしたデータの内容に誤りがあった場合,データの修正量が少ないときは,UPDATE文またはDELETE文でデータを修正してください。UPDATE文でデータを1件修正する例を次に示します。

■SQL文の実行例
UPDATE "PURCHASE" SET "ITEM_ID"=103 WHERE "PURCHASE_ID"='A0015309'

[説明]

購買履歴表(PURCHASE)に対して,購買履歴ID(PURCHASE_ID)がA0015309のデータの,商品ID(ITEM_ID)を103に更新します。

UPDATE文については,マニュアルHADB SQLリファレンスUPDATE(行の更新)を参照してください。

なお,大量のデータ修正が必要な場合は,入力データファイルの内容を修正し,adbimportコマンドを実行して,修正後のデータに入れ替えることを推奨します。修正後のデータに入れ替える手順については,「11.4.12 チャンクの状態を変更する方法」の「(4) 運用例(チャンク内のデータを入れ替える)」を参照してください。

(5) データの検索

購買履歴表(PURCHASE)に対するバックグラウンドインポートの実行中も,購買履歴表中のデータを検索できます。

バックグラウンドインポートによってデータを追加することで,インポートの対象となるデータベースに対して検索を実行しているユーザが存在しても,データのインポートを実行できます(検索と並行してデータのインポートを実行できます)。

バックグラウンドインポートとデータの検索の関係を次の図に示します。

図11‒29 バックグラウンドインポートとデータの検索の関係

[図データ]

購買履歴表に格納されている購買履歴データを,半年間,3か月間,1か月間,1週間,1日単位で分析します。

マルチチャンク表である購買履歴表にレンジインデクスが定義されている場合,レンジインデクスはキーとなるデータの,チャンク内での最大値・最小値(値域)を保持しています。検索時には探索条件に含まれないデータを格納しているチャンクがスキップされるため,効率良く検索できます。

購買履歴表にレンジインデクスが定義されている場合の処理を次の図に示します。

図11‒30 購買履歴表にレンジインデクスが定義されている場合の処理

[図データ]

[説明]

この例の場合,取引時間(TRADE_TIME列)に対してレンジインデクスが定義されています。そのため,取引時間で検索する際に,探索条件に含まれない取引時間のデータが格納されているチャンクの検索はスキップされます。

(6) チャンクのマージ

購買履歴表(PURCHASE)中の月ごとのデータを1つのチャンクにまとめることで,チャンク数の増加による検索性能の低下を回避します。この例では,購買履歴表中の1か月分(2014年1月分)のデータを1つのチャンクにまとめます。

(a) マージ対象とするチャンクの特定

マージ対象とするチャンクのチャンクIDを特定するには,次に示すように,システム表STATUS_CHUNKSを検索します。

SQL文の例を次に示します。

■SQL文の例
SELECT "CHUNK_ID" FROM "MASTER"."STATUS_CHUNKS" TC
   WHERE "TABLE_SCHEMA"='ADBUSER01' AND "TABLE_NAME"='PURCHASE' 
      AND "CHUNK_COMMENT"='January 2014_daily'
■検索結果
 CHUNK_ID
 --------------------
                    1
           (中略)
                   31
[説明]

この例の場合は,バックグラウンドインポート時に付加したチャンクのコメント('January 2014_daily')をキーにSTATUS_CHUNKS表を検索することで,マージ対象とするチャンクのチャンクID(131)を特定しています。

対象となるチャンクと,そのチャンクIDについては,「11.4.8 チャンクの状態や作成されているチャンク数を確認する方法」を参照して確認してください。

(b) チャンクの再編成要否の確認

(a) マージ対象とするチャンクの特定」で確認したマージ対象のチャンクに対して,チャンクの再編成が必要かどうかを確認します。確認するには,adbdbstatusコマンドで再編成要否の情報を取得します。

コマンドの実行例を次に示します。

■コマンドの実行例
adbdbstatus -d reorginfo -n ADBUSER01.PURCHASE -c 1-31

[説明]

この例の場合は,マージ対象とするチャンクのチャンクID(131)の再編成要否の情報を取得しています。

再編成要否の情報(Reorganization_necessity)はチャンクごとに出力されます。Reorganization_necessityRecommendedの場合,そのチャンクの再編成を実行してください。チャンクの再編成手順については,「(c) チャンクの再編成」を参照してください。

チャンクの再編成後,「(d) チャンクのマージ」に示す方法で1つのチャンクにマージします。

(c) チャンクの再編成

(b) チャンクの再編成要否の確認」で,再編成要否の情報(Reorganization_necessity)がRecommendedのチャンクがある場合,そのチャンクの再編成を実行します。ここでは,チャンクIDが2のチャンクが再編成の対象となった場合を例に,チャンクを再編成する手順を説明します。

■チャンクを再編成する手順
  1. 購買履歴表(PURCHASE)を更新するコマンド,ジョブ,およびAPを停止する

  2. システム表STATUS_CHUNKを検索し,チャンクIDが2のチャンクの状態とコメントを確認する

    ■SQL文の実行例

    SELECT CHUNK_ID, CHUNK_COMMENT, CHUNK_STATUS
      FROM "MASTER"."STATUS_CHUNKS"
        WHERE "TABLE_SCHEMA"='ADBUSER01' AND "TABLE_NAME"='PURCHASE'
          AND "CHUNK_ID"=2

    ■SQL文の実行結果

    CHUNK_ID    CHUNK_COMMENT CHUNK_STATUS
    ----------- ------------- ------------------------
              2 daily         Normal
  3. adbexportコマンドで,チャンクIDが2のチャンクのデータを出力する

    エクスポートオプションファイル(/home/adbmanager/exp_file/exp_opt_file01.txt),出力データパスファイル(/home/adbmanager/exp_file/exp_filepath.txt)を,それぞれ指定して実行します。

    ■コマンドの実行例

    adbexport -u ADBUSER01 -p '#HelloHADB_01'
              -z /home/adbmanager/exp_file/exp_opt_file01.txt
              -n PURCHASE
              -c 2
              /home/adbmanager/exp_file/exp_filepath.txt

    ■出力データパスファイル(/home/adbmanager/exp_file/exp_filepath.txt)の内容

    /home/adbmanager/exp_file/purchase_data0.csv
    /home/adbmanager/exp_file/purchase_data1.csv
    /home/adbmanager/exp_file/purchase_data2.csv
    /home/adbmanager/exp_file/purchase_data3.csv
    /home/adbmanager/exp_file/purchase_data4.csv
    /home/adbmanager/exp_file/purchase_data5.csv
    /home/adbmanager/exp_file/purchase_data6.csv
    /home/adbmanager/exp_file/purchase_data7.csv
    /home/adbmanager/exp_file/purchase_data8.csv
    /home/adbmanager/exp_file/purchase_data9.csv
  4. adbimportコマンドで,出力したデータをインポートする

    インポートオプションファイル(/home/adbmanager/imp_file/imp_opt_file01.txt),入力データパスファイル(/home/adbmanager/exp_file/exp_filepath.txt)を,それぞれ指定して実行します。

    入力データパスファイルには,adbexportコマンドの実行で使用した出力データパスファイルをそのまま使用します。また,-mオプションには,手順2.で確認したチャンクのコメント(daily)を指定します。

    ■コマンドの実行例

    adbimport -u ADBUSER01 -p '#HelloHADB_01' -k "'" -s , -g 10
              -w /home/adbmanager/tmp
              -z /home/adbmanager/imp_file/imp_opt_file01.txt
              -b --status wait
              -m 'daily'
              PURCHASE
              /home/adbmanager/exp_file/exp_filepath.txt
  5. adbchgchunkstatusコマンドで,チャンクの状態を変更する

    再編成の対象のチャンク(チャンクIDは2)と,手順4.で作成したチャンク(チャンクIDは32)の状態を変更します。

    ■コマンドの実行例

    adbchgchunkstatus -u ADBUSER01 -p '#HelloHADB_01'
                      -w 2 -n 32 PURCHASE

    上記のコマンドを実行すると,チャンクIDが2のチャンクは待機状態になり,チャンクIDが32のチャンクは通常状態になります。

  6. PURGE CHUNK文で,再編成の対象のチャンク(チャンクIDは2)を削除する

    ■SQL文の実行例

    PURGE CHUNK PURCHASE WHERE CHUNKID=2
  7. 購買履歴表(PURCHASE)を更新するコマンド,ジョブ,およびAPを開始する

(d) チャンクのマージ

チャンクのマージには,adbmergechunkコマンドを使用します。adbmergechunkコマンドの実行例を次に示します。

■コマンドの実行例
adbmergechunk -u ADBUSER01 -p '#HelloHADB_01' -g 2
              -w /home/adbmanager/tmp
              -z /home/adbmanager/merge_file/merge_opt_file01.txt
              -m 'January 2014'
              -c 1-31
              PURCHASE
[説明]

購買履歴表(PURCHASE)に対してマージチャンクオプションファイル(/home/adbmanager/merge_file/merge_opt_file01.txt)に設定した値を入力情報として,-cオプションに指定したチャンクのマージを実行します。

この例では,1から31のチャンクIDのチャンクを1つのチャンクにマージすることで,2014年1月分のデータとしてまとめています。

チャンクのマージの例を次の図に示します。

図11‒31 チャンクのマージの例

[図データ]

チャンクID1から31のチャンクは,adbmergechunkコマンドの正常終了時に自動的に削除されます。

メモ

チャンクをマージすることで検索性能を向上させることができます。また,1表,1DBエリアが管理できるチャンク数には限りがあります。チャンク数が足りない場合には,複数のチャンクを1つにマージすることで,使用するチャンク数を削減できます。

マージ対象のチャンクに対して検索を実行しているユーザが存在しても,マージチャンクは実行できます。

adbmergechunkコマンドについては,マニュアルHADB コマンドリファレンスadbmergechunk(チャンクのマージ)を参照してください。また,「11.4.9 チャンクをマージする方法(チャンク数を減らす方法)」も参照してください。

(e) マージしたチャンクの再編成要否の確認

2014年1月分のデータを1つのチャンクにマージしたあとに,adbdbstatusコマンドを実行して,このチャンクに対する再編成要否の情報(Reorganization_necessity)を確認します。手順を次に示します。

手順

  1. マージしたチャンクのチャンクIDを確認する

    ■SQL文の実行例

    SELECT "CHUNK_ID" FROM "MASTER"."STATUS_CHUNKS" TC
        WHERE "TABLE_SCHEMA"='ADBUSER' AND "TABLE_NAME"='PURCHASE'
          AND "CHUNK_COMMENT"='January 2014'

    ■SQL文の実行結果

     CHUNK_ID
     -----------------
                    32

    [説明]

    2014年1月分のデータとしてマージされたチャンクのチャンクIDは,上記のSQL文を実行すると確認できます。この例の場合,マージされたチャンクのチャンクIDが32であることがわかります。

  2. 再編成要否の情報を確認する

    ■コマンドの実行例

    adbdbstatus -d reorginfo -n ADBUSER01.PURCHASE -c 32

    チャンクIDが32のチャンクの再編成要否の情報(Reorganization_necessity)を確認します。Reorganization_necessityRecommendedの場合,このチャンクの再編成を実行してください。

(7) データのバックアップ

購買履歴表(PURCHASE)のデータ容量の増加を抑えるために,購買履歴表には過去6か月分のデータを格納する運用にしています。6か月より前のデータはバックアップを取得してから,削除します。バックアップの取得は,1か月に1度実行します。

具体的な手順について,次に示します。

(a) 作成日時が最も古いチャンクの特定

購買履歴表(PURCHASE)で6か月より前のチャンク(作成した日時が最も古いチャンク)を特定します。購買履歴表の最もチャンクの作成日時が古いチャンクを特定するには,次に示すように,システム表STATUS_CHUNKSを検索します。

SQL文の例を次に示します。

■SQL文の例
SELECT "CHUNK_ID" FROM "MASTER"."STATUS_CHUNKS" TC
   WHERE "TABLE_SCHEMA"='ADBUSER01' AND "TABLE_NAME"='PURCHASE' 
      AND "CREATE_TIME"=(SELECT MIN("CREATE_TIME")
         FROM "MASTER"."STATUS_CHUNKS"
            WHERE TC."TABLE_SCHEMA"='ADBUSER01'
               AND TC."TABLE_NAME"='PURCHASE')
■検索結果
 CHUNK_ID
 --------------------
                   32
KFAA96404-I 1 rows were selected.
[説明]

STATUS_CHUNKS表を検索した結果,この例の場合はチャンクIDが32のチャンクが,作成日時が最も古いチャンク(6か月より前のチャンク)であることがわかります。

メモ

チャンクをマージした場合は,STATUS_CHUNKS表には,マージ元チャンクのうち,最も古い「チャンクの作成日時」が格納されます。

STATUS_CHUNKS表の検索方法については,「付録C.9 システム表の検索」を参照してください。

(b) バックアップの取得

購買履歴表(PURCHASE)で最もチャンクの作成日時が古いチャンクのチャンクIDが32であるとわかったので,そのチャンクに含まれるデータのバックアップをCSV形式のファイルで取得します。

バックアップの取得には,adbexportコマンドを使用します。adbexportコマンドの実行例を次に示します。

■コマンドの実行例
adbexport -u ADBUSER01 -p '#HelloHADB_01'
          -z /home/adbmanager/exp_file/exp_opt_file01.txt
          -n PURCHASE
          -c 32
          /home/adbmanager/exp_file/exp_data_path01.txt
■出力データパスファイル(/home/adbmanager/exp_file/exp_data_path01.txt)の内容
/home/adbmanager/exp_backup/backup0001.csv
/home/adbmanager/exp_backup/backup0002.csv
/home/adbmanager/exp_backup/backup0003.csv
[説明]

チャンクIDが32のチャンクに含まれるデータのバックアップをCSV形式のファイル(/home/adbmanager/exp_backup/backup0001.csv/home/adbmanager/exp_backup/backup0002.csv/home/adbmanager/exp_backup/backup0003.csv)に取得します。

この例の場合,月ごとにチャンクがマージされているので,1か月分のデータのバックアップになります。

メモ

バックアップを取得するファイルは1つにすることもできますが,複数のファイルに分散することで,出力にかかるオーバヘッドを分散させ性能を向上させることができます。

adbexportコマンドについては,マニュアルHADB コマンドリファレンスadbexport(データのエクスポート)を参照してください。また,「11.4.5 チャンク単位にデータをエクスポートする方法」も参照してください。

(8) 古いデータ(チャンク)の削除

購買履歴表(PURCHASE)のデータ容量の増加を抑えるために,6か月より前のデータを削除します。

購買履歴表(PURCHASE)から作成日時が最も古いチャンクを削除します。チャンクを削除するには,PURGE CHUNK文の探索条件にチャンクIDを指定して実行します。

■SQL文の例
PURGE CHUNK "PURCHASE" WHERE CHUNKID=32
[説明]

チャンクIDが32のチャンクに含まれるデータを削除します。

この例の場合,月ごとにチャンクがマージされているので,1か月分のデータが削除されます。

PURGE CHUNK文については,マニュアルHADB SQLリファレンス操作系SQLPURGE CHUNK(チャンク内の全行削除)を参照してください。また,「11.4.6 チャンク単位にデータを削除する方法」も参照してください。

(9) 新しいデータの追加・マージと古いデータの削除の繰り返し

バックグラウンドインポートの実行とチャンクのマージ,およびPURGE CHUNK文を利用したチャンクの削除を繰り返すことで,HADBが管理するデータ量を増やすことなく,購買履歴を分析する運用が継続できます。