この文章では、Adobe Campaign Classic(v6 または v7)データモデルの設計に関するベストプラクティスについて詳しく説明します。

概要

Adobe Campaign は外部データベースに依存しています。テーブルのサイズに制限はありません。パフォーマンスを最適化するには、大型のテーブルを特定のデザインにする必要があります。この文章では、大容量のデータベース設計を最適化する方法について説明します。

Campaign の組み込みテーブルとそのインタラクションについて理解を深めるには、Campaign のデータモデルの説明を参照してください。

注意:

Campaign のスキーマの操作を開始するには、このドキュメントを参照してください。

Adobe Campaign データベースの概念的なデータモデルを拡張するための拡張スキーマの設定方法については、このドキュメントを参照してください。

テーブルのサイズ

  • 小型のテーブルは、デリバリーテーブルに似ています。
  • 中型サイズのテーブルは、受信者テーブルのサイズと同じになります。顧客ごとに1件のレコードがあります。
  • 大型サイズのテーブルは、広域ログテーブルに似ています。顧客ごとには多数のレコードがあります。

例えば、データベースに1,000 万人の受信者が含まれている場合は、広域ログのテーブルには約 1〜2 億件のメッセージが含まれ、配信表には数千のレコードが含まれています。

注意:

より少ないフィールドとより多くの数値データで大型なテーブルを設計することがベストプラクティスです。

この例では、トランザクションとトランザクションアイテムのテーブルが大きくて:1千万を超えています。

プロダクトテーブルとストアーテーブルは小さい:10,000 未満です。

プロダクトラベルとレファレンスはプロダクトテーブルに配置されていました。

トランザクションアイテムテーブルには、プロダクトテーブルへのリンクのみがあります。これは数値です。

image2014-1-14_10-40-22

データ種類の選択

大型なテーブルには、主に数値フィールドを含み、レファレンステーブルへのリンクを含む必要があります。

フィールドの重複を避けるために、「expr」属性が使用できます。たとえば、受信者テーブルでは、電子メールフィールドに既に存在するドメインの式が使用されます。

あまりにも多くのフィールドを作成することを避けるためには、「XML」タイプが適切なトリックです。ただし、データベースで CLOB 列を使用するため、ディスク容量も占有されます。

フィールドの選択

フィールドをテーブルに格納する必要があることを確認するドライバには、ターゲティング目的またはパーソナライゼーション目的があります。言い換えれば、フィールドがパーソナライズされた電子メールの送信やクエリの基準として使用されない場合は、このフィールドは役に立たず、ディスクスペースを無駄にすると考える必要があります。


FDA(連合データアクセス、外部データにアクセスできるオプションの機能)は、キャンペーンプロセス中にフィールドを「on-the-fly」で追加する必要性をカバーしていることに注意してください。FDA を持っている場合は、すべてをインポートする必要はありません。

キーの選択

ほとんどのテーブルでデフォルトで定義されている「Autopk」の以外に、いくつかの論理キーまたはビジネスキー(アカウント番号、クライアント番号など)を追加することも検討してください。後でインポート/リコンシリエーションまたはデータパッケージに使用することができます。

効率的なキーはパフォーマンスにとって不可欠です。数値データ型は常にテーブルのキーとして優先されるべきです。

SQL サーバーデータベースの場合、パフォーマンスが必要な場合は「クラスタードインデックス」を使用することがお勧めします。アドビはこれを処理しないので、SQL で作成する必要があります。

インデックス

インデックスはパフォーマンスにとって不可欠です。スキーマでキーを宣言すると、アドビはキーのフィールドにインデックスを自動的に作成します。また、キーを使用しないクエリのインデックスインデックスをさらに宣言することもできます。

データの挿入時のパフォーマンスに影響するため、インデックスはサイズと数に制限される必要があります。

リンクとカーディナリティ

リンクを設計するときは、1-1 の関係が宣言されているときに、ターゲットレコードが一意であることを確認してください。それ以外に、レコードが1つだけの場合に、接続によって複数のレコードが返されることがあります。この結果、「クエリによって返された行の数が予想以上になる」ときに、配信準備中にエラーが発生します。リンク名をターゲットスキーマと同じ名前に設定します。

大型のテーブルの「own」整合性に注意してください。「own」整合性でワイドテーブルを持っているレコードを削除すると、インスタンスが停止することがあります。テーブルはロックされ、削除は 1 つずつおこなわれます。したがって、大型の子テーブルには「neutral」整合性を使用することをお勧めします。

リンクを外部連接として宣言すると、パフォーマンスが悪くなります。ゼロ ID レコードは、外部連接機能をエミュレートします。リンクが「autopk」を使用する場合は、外部連接を宣言する必要はありません。

パーティショニング

データベースレベルでのパーティショニングは、大容量を持っているある特定のテーブルに対してクエリを最適化するソリューションになります。策略はテーブルの目的とは異なります。

  • 応答またはレポート集計では、広域のログとトランザクションを週単位または月単位で分割し、最新のデータへのアクセスを最適化します。
  • 分散されたマーケティングの場合、ローカルデータへのアクセスを最適化するために、地域または代理によって受取人テーブルを分配します。

専用のテーブルスペース

スキーマのテーブルスペース属性を使用すると、テーブルに専用テーブルスペースを指定できます。

インストールウィザードを使用すると、オブジェクトをタイプ(データ、一時的、インデックス)で格納できます。

パーティション、セキュリティルール、流動性に富む、柔軟性の高い管理、最適化及びパフォーマンスの向上には、専用の tablespaces が適しています。

1対多の関係

データデザインはユーザビリティと機能に影響します。多くの多対1関係にあるデータモデルをデザインすると、ユーザーがアプリケーションで意味のあるロジックを構築するのに難しくなります。1対多フィルターロジックは、技術系ではいマーケッターにとって、正しく作成・理解するのに難しくなります。

ユーザーがクエリーをもっと簡単に作成できるように、1 つのテーブルに必須のフィールドをすべて含めることを勧める。また、結合を回避できる場合は、パフォーマンスは複数のテーブルに一部のフィールドを複製することがよい。

特定の組み込み機能を使用して 1 対多の関係を参照することはできない。たとえば、オファーの重み付けや配信など。

クリーンアップタスク

スキーマ内で「deleteStatus」属性が公表できる。削除済みのレコードをマークし、クリーンアップタスクで削除を延期するほうが効率的である。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー