メインコンテンツへスキップ

複数ファイルをキャッシュしクエリを実行する方法

  • 更新

    概要

    データソースとして大量の複数ファイルがある場合に、それらを外部データベースにキャッシュしクエリを実行する方法について説明します。

    TDVでは、ファイル形式のデータソースを必ずしもキャッシュする必要はありませんが、データベースにキャッシュしておくことで、他のデータソースとの結合処理等において性能の劣化を防ぐことができる場合があります。

     

    利用データソース

    本記事では、以下のようなファイル形式のデータソースを利用します。

    ログファイル

    以下のように Cluster-1、Cluster-2、Cluster-3 に関するログファイルがそれぞれ log1、log2、log3フォルダに日別で1ヶ月分が格納されています。
    1ファイルあたり1万件のデータが収録されており、全ファイル合計で90万件です。
    ファイルはTDV Serverが接続可能な場所に保存されていることを前提とします。

    cluster_logs01.png

    cluster_logs02.png

    cluster_logs03.png

    Excelファイル

    以下のようなExcel形式の対応表データが所定のフォルダに格納されています。

    excel_master01.png

    excel_master02.png

     

    データソース追加

    以下のようにTDV Studioからデータソースを追加します。

    studio_resource01.png

    このときに、logsデータソースについては以下のように Detect New Resources During Re-Introspection オプションを有効にしておきます。
    これにより、今後新しいファイルが追加されば場合はイントロスペクト時に自動で利用対象リソースとして追加されます。
    詳細はデータソース内のテーブル追加を再イントロスペクトでTDVに自動反映するをご参照ください。

    log_introspect01.png

    また、定期的に自動で再イントロスペクトを行うために、以下のように再イントロスペクトのスケジュール設定も行います。
    メールアドレスを設定しておくことで、再イントロスペクトの結果が通知されます。
    詳細はイントロスペクト結果をメールで通知する方法をご参照ください。

    log_introspect02.png

    データは以下のようにプレビューすることができます。
    この時点ではキャッシュされていないため、ファイルを直接参照しています。

    cluster_logs04.png

    excel_master03.png

     

    ファイル結合プロシージャ

    ログファイルはこの時点で、3クラスターのログファイルが日別で1ヶ月分あるため、ファイル数が 90 となっています。
    したがって、キャッシュ対象のテーブルが90件存在することになり、それらすべてに対してキャッシュ設定を行うことは非現実的です。
    ここでは、90件のファイルを1つのテーブルとして扱うために、プロシージャを利用して複数ファイルを結合します。
    この方法は対象の複数ファイルがすべて同じスキーマを持つことが前提となりますので、その点にはご注意ください。

    union_proc.png

    以下はプロシージャのサンプルです。
    TDVの組み込みテーブルであるALL_RESOURCESを利用して対象のテーブル（ここではcsvファイル）を全件取得し、一括でSELECTを実行しています。

    PROCEDURE union_logs(OUT result CURSOR(datetime VARCHAR(32768), "cluster number" VARCHAR(32768), requests VARCHAR(32768), access VARCHAR(32768), status VARCHAR(32768)))
    BEGIN
        DECLARE query VARCHAR(2147483647);
        DECLARE ds CURSOR(row_num INTEGER, ds_path VARCHAR(32768));
        DECLARE row_num INTEGER default 0;
        DECLARE ds_path VARCHAR(32768);
        -- '/shared/files_cached/Data Source/cluster_logs/logs/' 配下のテーブルをすべて取得
        SET query = 'SELECT ROW_NUMBER() OVER (ORDER BY PARENT_PATH, RESOURCE_NAME) row_num, REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(CONCAT(PARENT_PATH,CONCAT(''/'',RESOURCE_NAME)), ''\/'', ''"/"''), ''^"\/'', ''/''), ''$'', ''"'') ds_path FROM /services/databases/system/ALL_RESOURCES WHERE RESOURCE_TYPE = ''TABLE'' AND PARENT_PATH LIKE ''/shared/files_cached/Data Source/cluster_logs/logs/%'' ORDER BY ROW_NUM';
        OPEN ds FOR query;
        -- 取得されたすべてのテーブルに対してSELECT UNION ALL を実行
        FOR r AS ds DO
            SET row_num = r.row_num;
            --CALL /lib/debug/Log('row_num = ' || row_num);
            SET ds_path = r.ds_path;
            --CALL /lib/debug/Log('ds_path = ' || ds_path);
            IF row_num = 1 THEN
                SET query = 'SELECT * FROM ' || ds_path;
            ELSE 
                SET query = query || ' UNION ALL SELECT * FROM ' || ds_path;
            END IF;
        END FOR;
        --CALL /lib/debug/Log('query = ' || query);
        OPEN result FOR query;
    END

     

    キャッシュ用ビュー

    キャッシュ対象となるビューを作成します。

    ログファイル

    ファイル結合プロシージャに対してSELECTを実行するとともに、いくつかの列のデータ型を変更します。

    log_l1_view.png

    Excelファイル

    status_l1_view.png

     

    キャッシュ設定

    ログファイルおよびExcelファイルのキャッシュ用ビューに対してキャッシュ設定を行います。
    ここでは、キャッシュ毎にスケジュール設定を行わずに、それぞれのビューのキャッシュ更新のスケジュール管理はキャッシュポリシーで一元管理します。
    キャッシュポリシーについてはキャッシュポリシー利用方法をご参照ください。

    以降の説明では、キャッシュターゲット（キャッシュ用外部データベース）の設定手順についての説明は省略します。

    ログファイル

    logs_cache_setting.png

    Excelファイル

    status_cache_setting.png

    キャッシュポリシー

    管理対象のキャッシュ対象リソースを追加します。

    cache_policy01.png

    以下の設定では、更新モードを手動にしていますが、スケジュール実行を設定することも可能です。

    cache_policy02.png

     

    キャッシュ初期化

    キャッシュポリシーのキャッシュポリシーの設定タブにある今すぐ更新ボタンをクリックしてキャッシュを初期化（初回ロード）します。

    initialize_cache01.png

    正常に更新されると、ステータスが UP になります。

    initialize_cache02.png

    キャッシュ対象の各ビューでキャッシュにロードされたデータが取得されていることが確認できます。

    initialize_cache03.png

    initialize_cache04.png

     

    クライアントからのクエリ実行

    キャッシュした2つのビューをデータサービスとして公開し、外部クライアントからクエリを実行します。

    published_dataservice.png

    データソースはファイルではありますが、キャッシュしたことでデータベースにクエリを実行することになるため、非キャッシュ時よりもクエリ実行結果は早く返って来ることが期待できます。

    client_result.png

     

    キャッシュ更新

    ログファイル格納フォルダに新しいログファイルを追加し、新しいデータをキャッシュにも反映させるためにキャッシュを更新します。

    まずは、新しいファイルを所定のフォルダに配置します。

    cluster_logs_added01.png

    データソースの再イントロスペクト設定により、自動でリソースの追加が検知され、メールで通知されます。
    注意：再イントロスペクトのタイミングは設定の内容に依存します。

    cluster_logs_added_by_autointrospec02.png

    リソースツリー上でも新しいファイルの追加が確認できます。

    cluster_logs_added_by_autointrospec01.png

    キャッシュポリシーのキャッシュポリシーの設定タブにて今すぐ更新ボタンをクリックしてキャッシュを更新します。
    この作業も当然ながら更新モードを定期的に設定することで、スケジューラによる自動実行が可能です。

    refresh_cache01.png

    キャッシュ更新が完了後にビューにクエリを実行すると、追加分のデータがキャッシュにも反映されていることが確認できます。

    result_diff.png

     

    まとめ

    大量のファイルをキャッシュデータベースにロードして運用していく場合に役立つTipsについて説明しました。
    本記事で活用した重要な機能について以下のとおりまとめます。

    機能 説明 効果
    プロシージャ（リソースへの一括クエリ実行） systemテーブルを活用した特定のPARENT_PATH配下のリソースに対する一括クエリ実行を実現するプロシージャ 同じスキーマをもつファイル群を1つのテーブルと見なして扱うことができます。
    それにより、キャッシュ設定などをテーブル（ファイル）ごとに実施せずに済むため設定作業の負担を軽減させることができます。
    再イントロスペクトのスケジュール実行 再イントロスペクトを所定のスケジュールにより自動で定期的に実行 大量のファイルを扱う場合にデータソース側のファイルの追加・削除に自動で対応できるため、運用負荷の低減につながります。
    キャッシュポリシー 複数のリソースに対するキャッシュ更新をまとめて管理 キャッシュの更新タイミングの設定をリソースごとに実施せずに済むため設定作業の負荷を軽減させることができます。
    また、複数のリソースのキャッシュをまとめて管理できるため、一部のキャッシュだけが更新に成功して他は失敗するといった状況を回避することが可能です。