Campaign Classic での効率的なクエリの作成

効果的なクエリの作成方法

検索
Campaign Classic マニュアル

目次

対象アプリケーション: Campaign Classic

某些 Creative Cloud 应用程序、服务和功能在中国不可用。

このドキュメントでは、Adobe Campaign で実行する最適化されたクエリを作成してデータベースの負荷を制限し、ユーザーエクスペリエンスを向上させる方法について説明します。

クエリ設計

 より良く最適化された少ないクエリにでパフォーマンスを向上させます。

以下のヒントを参考にクエリを設計し最適化します。

  • 効率の良いクエリはインデックスに依存します。

  • 文字列フィールドではなく数値フィールドを使用して結合を実行します。

  • すべての結合に 1 つのインデックスを使用します。

  • 外部結合を実行しないでください。可能な場合は、ゼロ ID レコードを使用して外部結合機能を実現します。

  • Lower(...) などの関数に注意してください。

    Lower 関数を使用した場合、インデックスは使用されません。LIKE 演算子または UPPER 関数または LOWER 関数を使用してクエリをチェックします。データベースフィールドではなく、ユーザー入力に UPPER 関数を適用します。

  • 結合には正しいデータ型を使用します。 　

    WHERE 句がフィールドと同じ型であることを確認します。

    よくある間違いは次のとおりです。iBlacklist = '3' で iBlacklist が数値フィールド、 '3' がテキスト値になっている。

    あなたのクエリの実行計画を確認してください。

    特に、リアルタイムクエリや、1 分ごとに実行されるリアルタイムに近いクエリの場合は、全表スキャンは避けてください。

  • EXISTS 演算子を使用する代わりに、クエリのフィルタリングディメンションを使用します。

    AdobeCampaign_How_to_write_efficient_queries

    クエリにおいて、EXISTS SUCH AS 条件は効率的ではありません。

    EXISTS SUCH AS 条件は SQL のサブクエリと同等です。

    select iRecipientId from nmsRecipient where iRecipientId IN (select
iRecipientId from nmsBroadLog where (...))

    代わりに、クエリのフィルタリングディメンションを使用することがベストプラクティスです。

    AdobeCampaign_How_to_write_efficient_queries_Page_3_Image_0001

    SQL のフィルタリングディメンションに相当するのは、内部結合です。

    select iRecipientId from nmsRecipient INNER JOIN nmsBroadLog ON (...)

スキーマにおける結合の定義

スキーマでリンクを定義すると、結合条件が決まります。

リンクテーブルは主キーに固有のインデックスに持ち、結合はこのフィールド上にある必要があります。

文字列フィールドではなく数値フィールドでキーを定義します。

アーキテクチャのベストプラクティス

  1. PROD プラットフォームと同様のボリューム、パラメーター、およびアーキテクチャで DEV プラットフォームを構築します。

    PROD 環境と似た TEST（またはプリプロダクションプラットフォーム）を使用してください。TEST 環境および PROD 環境には、同じ値を使用してください。できるだけ以下と同じものを使ってください。

    • オペレーティングシステム。
    • バージョン。
    • データ。
    • アプリケーション。
    • 権限。
    • ボリューム。

    注意：

    TEST 環境で機能する機能であっても、異なるデータを用いる PROD 環境では機能しない場合があります。リスクを予測し、ソリューションを準備するために、主な違いを特定します。

  2. ターゲットのボリュームと一致する設定を作成します。

    大量のボリュームには特定の設定が必要です。10 万人の受信者に対して動作する設定は、100 万人の受信者に対して機能しない場合があります。

    システム稼働時、どのように計測するかを検討してください。小規模に対し機能するからといって、それが大容量に適しているとは限りません。テストは、稼働時のボリュームに似たボリュームでおこなう必要があります。また、ピークの時間帯、ピークの日にち、およびプロジェクトの存続期間中のボリュームの変化（呼び出し数、データベースのサイズ）の影響も評価する必要があります。 　

その他の関連ヘルプ