데이터 모델 모범 사례 data-model-best-practices

이 문서에서는 Adobe Campaign 데이터 모델을 디자인하는 동안 주요 권장 사항에 대해 간략하게 설명합니다.

Campaign 기본 제공 테이블과 상호 작용에 대한 자세한 내용은 을(를) 참조하십시오. 이 섹션 섹션.

읽기 이 설명서 Campaign 스키마를 시작하려면 에서 Adobe Campaign 데이터베이스의 개념 데이터 모델을 확장하기 위해 확장 스키마를 구성하는 방법을 알아봅니다. 이 문서.

개요 overview

Adobe Campaign 시스템은 매우 유연하며 초기 구현 이상으로 확장할 수 있습니다. 그러나 가능성은 무한하지만 현명한 결정을 내리고 데이터 모델 디자인을 시작하기 위한 강력한 기반을 구축하는 것이 중요합니다.

이 문서에서는 Adobe Campaign 도구를 올바르게 설계하는 방법을 배울 수 있는 일반적인 사용 사례와 모범 사례를 제공합니다.

데이터 모델 아키텍처 data-model-architecture

Adobe Campaign은 개인화된 고객 경험을 구축하기 위해 온라인 및 오프라인 전략을 연계할 수 있는 강력한 크로스채널 캠페인 관리 시스템입니다.

고객 중심 접근 방식 customer-centric-approach

대부분의 이메일 서비스 공급자는 목록 중심 접근 방식을 통해 고객과 통신하고 있지만 Adobe Campaign은 고객 및 해당 속성에 대한 광범위한 보기를 활용하기 위해 관계형 데이터베이스를 사용합니다.

이러한 고객 중심 접근 방식은 아래 차트에 나와 있습니다. 다음 수신자 회색 테이블은 모든 것이 만들어지는 기본 고객 테이블을 나타냅니다.

각 테이블의 설명에 액세스하려면 Admin > Configuration > Data schemas ​목록에서 리소스를 선택하고 Documentation 탭.

Adobe Campaign 기본 데이터 모델이에 나와 있습니다. 이 문서.

NOTE
Adobe Campaign Classic을 사용하면 사용자 지정 고객 테이블을 작성할 수 있습니다. 그러나 대부분의 경우 표준을 활용하는 것이 좋습니다 수신자 테이블 이미 사전 빌드된 추가 테이블 및 기능이 있습니다.

Adobe Campaign용 데이터 data-for-campaign

Adobe Campaign에 전송해야 하는 데이터는 무엇입니까? 마케팅 활동에 필요한 데이터를 결정하는 것이 중요합니다.

NOTE
Adobe Campaign은 data warehouse도 보고 도구도 아닙니다. 따라서 가능한 모든 고객 및 관련 정보를 Adobe Campaign으로 가져오거나 보고서를 작성하는 데만 사용할 데이터를 가져오지 마십시오.

Adobe Campaign에서 속성이 필요한지 여부를 결정하려면 다음 범주 중 하나에 해당하는지 자문하십시오.

  • 다음에 사용된 속성 세분화
  • 다음에 사용된 속성 데이터 관리 프로세스 (예: 집계 계산)
  • 다음에 사용된 속성 개인화

이러한 속성에 해당하지 않으면 Adobe Campaign에서 이 속성이 필요하지 않을 가능성이 높습니다.

데이터 유형 선택 data-types

시스템의 우수한 아키텍처 및 성능을 보장하려면 아래 모범 사례에 따라 Adobe Campaign에서 데이터를 설정하십시오.

  • 큰 테이블은 대부분 숫자 필드를 포함하고 참조 테이블에 대한 링크를 포함해야 합니다(값 목록으로 작업할 때).
  • 다음 expr 속성을 사용하면 스키마 속성을 테이블의 물리적 세트 값이 아닌 계산된 필드로 정의할 수 있습니다. 이렇게 하면 두 값을 모두 저장하지 않고도 다른 형식(예: 연령 및 생년월일)으로 정보에 액세스할 수 있습니다. 이는 필드가 중복되지 않도록 하는 좋은 방법입니다. 예를 들어 수신자 테이블은 이메일 필드에 이미 있는 도메인에 대한 표현식을 사용합니다.
  • 그러나 표현식 계산이 복잡한 경우 를 사용하지 않는 것이 좋습니다. expr 속성 as the-fly 계산은 쿼리 성능에 영향을 줄 수 있습니다.
  • 다음 XML 유형은 너무 많은 필드를 만들지 않는 좋은 방법입니다. 그러나 데이터베이스의 CLOB 열을 사용하므로 디스크 공간도 차지합니다. 또한 복잡한 SQL 쿼리가 발생할 수 있으며 성능에 영향을 줄 수 있습니다.
  • 의 길이 문자열 필드는 항상 열로 정의해야 합니다. 기본적으로 Adobe CampaignAdobe 의 최대 길이는 255이지만, 크기가 더 짧은 길이를 초과하지 않는다는 것을 이미 알고 있는 경우에는 필드를 더 짧게 유지하는 것이 좋습니다.
  • 소스 시스템의 크기가 과대평가되어 도달하지 않을 것이 확실한 경우 Adobe Campaign에서 소스 시스템보다 더 짧은 필드를 가질 수 있습니다. 이는 Adobe Campaign에서 더 짧은 문자열 또는 더 작은 정수를 의미할 수 있습니다.

필드 선택 choice-of-fields

필드는 타겟팅 또는 개인화 목적이 있는 경우 표에 저장해야 합니다. 즉, 필드가 개인화된 이메일을 보내는 데 사용되지 않거나 쿼리의 기준으로 사용되지 않으면 디스크 공간을 사용하지만 사용할 수는 없습니다.

하이브리드 및 온프레미스 인스턴스의 경우 FDA(Federated Data Access, 외부 데이터에 액세스할 수 있는 선택 기능)에서는 캠페인 프로세스 중에 "즉시" 필드를 추가해야 하는 경우를 다룹니다. FDA가 있는 경우 모든 항목을 가져올 필요는 없습니다. 자세한 내용은 Federated Data Access 정보.

키 선택 choice-of-keys

이외에도 autopk 대부분의 테이블에서 기본적으로 정의되므로 일부 논리 키 또는 비즈니스 키(계정 번호, 클라이언트 번호 등)를 추가하는 것이 좋습니다. 나중에 가져오기/조정 또는 데이터 패키지에 사용할 수 있습니다. 자세한 내용은 식별자.

효율적인 키는 성능을 위해 필수적입니다. 숫자 데이터 유형은 항상 테이블의 키로 선호되어야 합니다.

SQLServer 데이터베이스의 경우 성능이 필요한 경우 "클러스터형 인덱스" 사용을 고려할 수 있습니다. Adobe은 이 작업을 처리하지 않으므로 SQL에서 만들어야 합니다.

전용 테이블스페이스 dedicated-tablespaces

스키마의 테이블스페이스 속성을 사용하여 테이블에 대한 전용 테이블스페이스를 지정할 수 있습니다.

설치 마법사를 사용하여 데이터, 임시, 색인 등 유형별로 개체를 저장할 수 있습니다.

전용 테이블스페이스는 분할, 보안 규칙에 더 적합하며 유동적이고 유연한 관리, 더 나은 최적화 및 성능을 제공합니다.

식별자 identifiers

Adobe Campaign 리소스에는 세 개의 식별자가 있으며, 식별자를 더 추가할 수 있습니다.

다음 표에서는 이러한 식별자 및 해당 목적에 대해 설명합니다.

식별자
설명
모범 사례
ID
  • ID는 Adobe Campaign 테이블의 물리적 기본 키입니다. 기본 제공 테이블의 경우 시퀀스에서 생성된 32비트 숫자입니다
  • 이 식별자는 일반적으로 특정 Adobe Campaign 인스턴스에 대해 고유합니다.
  • 자동 생성된 ID는 스키마 정의에 표시될 수 있습니다. 검색 autopk="true" 특성.
  • 자동 생성된 식별자는 워크플로우 또는 패키지 정의에서 참조로 사용할 수 없습니다.
  • ID가 항상 증가하는 숫자라고 가정해서는 안 됩니다.
  • 기본 제공 테이블의 ID는 32비트 숫자이며 이 유형은 변경해서는 안 됩니다. 이 번호는 동일한 이름의 섹션에서 다루는 "시퀀스"에서 가져온 것입니다.
이름(또는 내부 이름)
  • 이 정보는 테이블에 있는 레코드의 고유 식별자입니다. 이 값은 일반적으로 생성된 이름으로 수동으로 업데이트할 수 있습니다.
  • 이 식별자는 Adobe Campaign의 다른 인스턴스에 배포할 때 값을 유지하며 비워 둘 수 없습니다.
  • 객체가 환경에서 다른 환경으로 배포되는 경우 Adobe Campaign에서 생성된 레코드 이름의 이름을 바꿉니다.
  • 오브젝트에 네임스페이스 특성( )이 있는 경우​ 스키마 예를 들어) 이 공통 네임스페이스는 생성된 모든 사용자 지정 개체에 활용됩니다. 일부 예약된 네임스페이스는 사용할 수 없습니다. nms, xtk, nl, ncl, crm, xxl.
  • 오브젝트에 네임스페이스()가 없는 경우​ 워크플로우 또는 게재 예를 들어) 이 네임스페이스 개념은 내부 이름 개체의 접두사로 추가됩니다. namespaceMyObjectName.
  • 공백 ", 세미콜론 ":" 또는 하이픈 "-"와 같은 특수 문자는 사용하지 마십시오. 이 모든 문자는 밑줄 "_"(허용된 문자)로 대체됩니다. 예를 들어 "abc-def"와 "abc:def"는 "abc_def"로 저장되고 서로 덮어쓰기됩니다.
레이블
  • 레이블은 Adobe Campaign에 있는 개체 또는 레코드의 비즈니스 식별자입니다.
  • 이 개체에는 공백과 특수 문자가 허용됩니다.
  • 그것은 기록의 고유성을 보장하지 않는다.
  • 개체 레이블의 구조를 결정하는 것이 좋습니다.
  • 이는 Adobe Campaign 사용자의 레코드 또는 개체를 식별하는 가장 사용자 친화적인 솔루션입니다.

사용자 정의 내부 키 custom-internal-keys

Adobe Campaign에서 만든 모든 테이블에 기본 키가 필요합니다.

대부분의 조직은 외부 시스템에서 레코드를 가져오고 있습니다. 수신자 테이블의 물리적 키는 "id" 속성이지만 사용자 지정 키를 결정할 수도 있습니다.

이 사용자 지정 키는 Adobe Campaign에 공급되는 외부 시스템의 실제 레코드 기본 키입니다.

기본 제공 테이블에 autopk와 내부 키가 모두 있는 경우 내부 키는 물리적 데이터베이스 테이블에서 고유 인덱스로 설정됩니다.

사용자 지정 테이블을 만들 때는 두 가지 옵션이 있습니다.

  • 자동 생성 키(id)와 내부 키(사용자 지정)의 조합입니다. 이 옵션은 시스템 키가 복합 키이거나 정수가 아닌 경우에 유용합니다. 정수는 큰 표에서 더 높은 성능을 제공하고 다른 표와 결합합니다.
  • 기본 키를 외부 시스템 기본 키로 사용. 이 솔루션은 서로 다른 시스템 간에 일관된 키를 사용하여 데이터를 가져오고 내보내는 접근 방식을 단순화하기 때문에 일반적으로 선호됩니다. 키 이름이 "id"이고 외부 값으로 채워져야 하는 경우(자동 생성이 아님) Autopk를 비활성화해야 합니다.
IMPORTANT
워크플로에서는 autopk를 참조로 사용하지 않아야 합니다.

시퀀스 sequences

Adobe Campaign 기본 키는 모든 기본 제공 테이블에 대해 자동으로 생성된 id이며 사용자 지정 테이블에 대해 동일할 수 있습니다. 자세한 내용은 이 섹션을 참조하십시오.

이 값은 라고 하는 것에서 가져옵니다. 시퀀스: 숫자 시퀀스를 생성하는 데 사용되는 데이터베이스 개체입니다.

시퀀스에는 두 가지 유형이 있습니다.

  • 공유됨: 두 개 이상의 테이블이 동일한 시퀀스에서 id를 선택합니다. 즉, ID 'X'를 한 테이블에서 사용하는 경우 동일한 시퀀스를 공유하는 다른 테이블에는 해당 ID 'X'의 레코드가 없습니다. XtkNewId 는 Adobe Campaign에서 사용할 수 있는 기본 공유 시퀀스입니다.
  • 전용: 한 테이블만 시퀀스에서 id를 선택하고 있습니다. 일반적으로 시퀀스 이름에는 테이블 이름이 포함됩니다.
IMPORTANT
이 시퀀스는 정수 32비트 값이며, 사용 가능한 값의 유한 최대 수는 21억 4000만 개입니다. 최대값에 도달하면 ID를 재생하기 위해 시퀀스가 0으로 돌아갑니다.
이전 데이터가 제거되지 않은 경우 그 결과는 고유 키 위반이 되어 플랫폼 상태 및 사용에 대한 차단기가 됩니다. Adobe Campaign은 커뮤니케이션을 전송할 수 없으며(게재 로그 테이블에 영향을 줄 때) 성능에 큰 영향을 줍니다.

따라서 연간 60억 개의 이메일을 보내고 로그에 대해 보존 기간을 180일로 지정한 고객은 4개월 후에 ID가 고갈됩니다. 이러한 문제를 방지하려면 볼륨에 따라 제거 설정을 지정해야 합니다. 자세한 내용은 이 섹션을 참조하십시오.

Adobe Campaign에서 기본 키를 autoPK로 사용하여 사용자 지정 테이블을 만들 때 사용자 지정 전용 시퀀스를 해당 테이블과 체계적으로 연결해야 합니다.

기본적으로 사용자 지정 시퀀스의 값은 +1,000에서 +2.1BB입니다. 기술적으로 음수 ID를 활성화하여 4BB의 전체 범위를 가져올 수 있습니다. 이 변수는 주의하여 사용해야 하며 음수에서 양수로 교차하면 ID 하나가 손실됩니다. 레코드 0은 일반적으로 생성된 SQL 쿼리에서 Adobe Campaign에서 무시됩니다.

순서 고갈에 대한 자세한 내용은 다음을 참조하십시오. 이 비디오.

색인 indexes

인덱스는 성능에 필수적입니다. 스키마에서 키를 선언하면 Adobe은 키 필드에 자동으로 인덱스를 만듭니다. 키를 사용하지 않는 쿼리에 대해 더 많은 색인을 선언할 수도 있습니다.

Adobe은 성능을 향상시킬 수 있으므로 추가 인덱스를 정의하는 것을 권장합니다.

그러나 다음 사항에 유의하십시오.

  • 색인 사용은 액세스 패턴에 바인딩됩니다. 인덱싱을 최적화하는 것은 종종 데이터베이스 설계의 핵심 부분이며 전문가가 처리해야 합니다. 인덱스 추가는 종종 데이터베이스 유지 관리에 연결된 반복적인 워크플로우입니다. 시간이 지남에 따라 성능 문제를 해결하기 위해 단계별로 수행됩니다.
  • 인덱스는 인덱스 자체를 저장하기 위해 전체 테이블 크기를 늘립니다.
  • 열에 인덱스를 추가하면 데이터 읽기 액세스(SELECT) 성능은 향상되지만 데이터 쓰기 액세스(UPDATE) 성능은 저하될 수 있습니다.
  • 이 경우 데이터를 삽입하는 동안 성능에 영향을 주므로 인덱스의 크기와 수를 제한해야 합니다.
  • 필요하지 않은 경우 색인을 추가하지 마십시오. 이 옵션이 필요한지 확인하고 쿼리(테스트 및 학습)의 전체 성능을 높여야 합니다.
  • 일반적으로 쿼리가 10% 이상의 레코드를 가져오지 않는다는 것을 알고 있으면 색인이 효율적입니다.
  • 정의해야 하는 색인을 신중하게 선택합니다.
  • 기본 제공 테이블에서 네이티브 인덱스를 제거하지 마십시오.

예제

색인 관리는 매우 복잡해질 수 있으므로 작동 방식을 이해하는 것이 중요합니다. 이러한 복잡성을 설명하기 위해 이름과 성을 필터링하여 수신자를 검색하는 기본적인 예를 살펴보겠습니다. 방법은 다음과 같습니다.

  1. 데이터베이스의 모든 수신자를 나열하는 폴더로 이동합니다. 자세한 내용은 프로필 관리.

  2. 마우스 오른쪽 단추 클릭 First name 필드.

  3. Filter on this field ​을(를) 선택합니다.

  4. 다음에 대해 이 작업 반복 Last name 필드.

해당 필터 두 개가 화면 맨 위에 추가됩니다.

이제 검색 필터링을 수행할 수 있습니다. First nameLast name 다양한 필터 조건에 따른 필드입니다.

이제 이러한 필터에서 검색 속도를 높이기 위해 색인을 추가할 수 있습니다. 그러나 어떤 색인을 사용해야 합니까?

NOTE
이 예는 PostgreSQL 데이터베이스를 사용하는 호스트된 고객에게 적용됩니다.

다음 표는 첫 번째 열에 표시된 액세스 패턴에 따라 아래에 설명된 세 가지 색인이 사용되거나 사용되지 않는 경우를 보여 줍니다.

검색 기준
색인 1(이름 + 성)
색인 2(이름만)
색인 3(성만)
댓글
이름은 "Johnny"입니다.
사용됨
사용됨
사용되지 않음
이름은 색인 1의 첫 번째 위치에 있으므로 성(last name)에 기준을 추가할 필요가 없으므로 계속 사용됩니다.
이름은 "Johnny"이고 성은 "Smith"입니다.
사용됨
사용되지 않음
사용되지 않음
동일한 쿼리에서 두 속성을 모두 검색하므로 두 속성을 모두 결합한 인덱스만 사용됩니다.
성은 "Smith"와 같습니다.
사용되지 않음
사용되지 않음
사용됨
인덱스의 속성 순서가 고려됩니다. 이 순서와 일치하지 않으면 색인이 사용되지 않을 수 있습니다.
이름이 "Joh"로 시작
사용됨
사용됨
사용되지 않음
"왼쪽 검색"을 지정하면 색인이 활성화됩니다.
이름은 "nny"로 끝남
사용되지 않음
사용되지 않음
사용되지 않음
"오른쪽 검색"을 수행하면 색인이 비활성화되고 전체 검사가 수행됩니다. 일부 특정 색인 유형은 이 사용 사례를 처리할 수 있지만 기본적으로 Adobe Campaign에서 사용할 수 없습니다.
이름에 "John"이 포함됨
사용되지 않음
사용되지 않음
사용되지 않음
"왼쪽"과 "오른쪽" 검색의 조합입니다. 후자로 인해 색인이 비활성화되고 전체 검사가 수행됩니다.
이름이 "john"과 같음
사용되지 않음
사용되지 않음
사용되지 않음
색인은 대/소문자를 구분합니다. 대/소문자를 구분하지 않게 하려면 "upper(firstname)"와 같은 SQL 함수를 포함하는 특정 인덱스를 만들어야 합니다. "unaccent(firstname)"와 같은 다른 데이터 변환에서도 동일한 작업을 수행해야 합니다.

큰 테이블에 "자신의" 무결성을 주의하십시오. "고유" 무결성의 넓은 테이블이 있는 레코드를 삭제하면 인스턴스가 중지될 수 있습니다. 테이블이 잠기고 삭제 작업이 하나씩 수행됩니다. 따라서 볼륨이 큰 하위 테이블에 대해 "중립" 무결성을 사용하는 것이 가장 좋습니다.

링크를 외부 조인으로 선언하는 것은 성능에 좋지 않습니다. 제로 ID 레코드는 외부 조인 기능을 에뮬레이션합니다. 링크가 autopk를 사용하는 경우에는 외부 조인을 선언할 필요가 없습니다.

Adobe 워크플로우의 모든 테이블을 조인할 수 있지만 데이터 구조 정의에서 직접 리소스 간의 공통 링크를 정의하는 것이 좋습니다.

링크는 표의 실제 데이터에 맞추어 정의해야 합니다. 잘못된 정의는 예기치 않게 레코드를 복제하는 것과 같이 링크를 통해 검색된 데이터에 영향을 줄 수 있습니다.

링크 이름을 테이블 이름으로 일관되게 지정합니다. 링크 이름은 떨어진 테이블이 무엇인지 이해하는 데 도움이 됩니다.

"id"가 접미사 인 링크의 이름을 지정하지 마십시오. 예를 들어 이름을 "transactionId"가 아닌 "transaction"으로 지정합니다.

기본적으로 Adobe Campaign은 외부 테이블의 기본 키를 사용하여 링크를 만듭니다. 좀 더 명확하게 하기 위해, 링크 정의에서 조인을 명시적으로 정의하는 것이 바람직하다.

링크에 사용된 속성에 색인이 추가됩니다.

작성자 및 마지막 수정자 링크는 많은 표에 있습니다. 비즈니스에서 이 정보를 사용하지 않는 경우 링크의 noDbIndex 속성을 사용하여 인덱스를 비활성화할 수 있습니다.

카디널리티 cardinality

링크를 디자인할 때는 1-1 관계가 선언되었을 때 대상 레코드가 고유한지 확인합니다. 그렇지 않으면 가입이 하나만 예상될 때 여러 레코드를 반환할 수 있습니다. 이로 인해 "쿼리가 예상보다 많은 행을 반환합니다"가 발생할 경우 게재 준비 중에 오류가 발생합니다. 링크 이름을 대상 스키마와 동일한 이름으로 설정합니다.

(1)측의 스키마에 카디널리티(1-N)가 있는 링크를 정의합니다. 예를 들어 수신자 (1) - (N) 트랜잭션 관계는 트랜잭션 스키마에서 정의되어야 합니다.

링크의 역카디널리티는 기본적으로 (N)입니다. 링크 정의에 revCardinality='single' 속성을 추가하여 링크(1-1)를 정의할 수 있습니다.

역방향 링크가 사용자에게 표시되지 않아야 하는 경우 링크 정의 revLink='로 숨길 수 있습니다​ 없음'. 이에 대한 유용한 사용 사례는 수신자로부터 예를 들어 완료된 마지막 거래로의 링크를 정의하는 것입니다. 수신자에서 마지막 트랜잭션으로의 링크만 표시하면 되며, 트랜잭션 테이블에서 역방향 링크를 볼 필요는 없습니다.

외부 조인(1-0…1)을 수행하는 링크는 시스템 성능에 영향을 주므로 주의하여 사용해야 합니다.

데이터 보존 - 정리 및 제거 data-retention

Adobe Campaign은 data warehouse도 보고 도구도 아닙니다. 따라서 Adobe Campaign 솔루션의 성능을 향상시키려면 데이터베이스 증가를 제어해야 합니다. 이를 위해 아래의 몇 가지 모범 사례를 따르는 것이 도움이 될 수 있습니다.

기본적으로 Adobe Campaign 게재 및 추적 로그는 180일의 보존 기간을 가집니다. 정리 프로세스가 실행되어 이보다 오래된 모든 로그가 제거됩니다.

  • 로그를 더 오래 보관하려면 데이터베이스 크기와 보낸 메시지 양에 따라 신중히 결정해야 합니다. 다시 말해서 Adobe Campaign 시퀀스는 32비트 정수입니다.
  • 사용 가능한 모든 ID를 소비할 위험을 제한하기 위해 이 표에서 한 번에 10억 개 이상의 레코드(사용 가능한 21억 4000만 ID의 약 50%)를 보유하지 않는 것이 좋습니다. 따라서 일부 고객은 보존 기간을 180일 미만으로 낮추어야 합니다.

의 데이터 유지에 대해 자세히 알아보기 Campaign 개인 정보 보호 및 보안 지침.

Campaign 데이터 베이스 정리 워크플로우에 대해 자세히 알아보기 이 섹션에서.

IMPORTANT
사용자 정의 테이블은 표준 정리 프로세스에서 삭제되지 않습니다. 첫날에는 이 작업이 필요하지 않지만 사용자 정의 테이블에 대한 제거 프로세스를 빌드하는 것을 잊지 마십시오. 이렇게 하면 성능에 문제가 발생할 수 있습니다.

Adobe Campaign에서 레코드의 필요성을 최소화하는 몇 가지 솔루션이 있습니다.

  • Adobe Campaign 외부의 데이터 웨어하우스에서 데이터를 내보냅니다.
  • 마케팅 사례에 충분한 공간을 사용하면서도 더 적은 공간을 사용할 집계된 값을 생성합니다. 예를 들어 마지막 구매를 추적하기 위해 Adobe Campaign의 전체 고객 거래 내역이 필요하지 않습니다.

스키마에서 "deleteStatus" 속성을 선언할 수 있습니다. 레코드를 삭제된 것으로 표시한 다음 정리 작업에서 삭제를 연기하는 것이 더 효율적입니다.

성능 performance

언제든지 더 나은 성능을 보장하기 위해 아래의 모범 사례를 따르십시오.

일반 권장 사항 general-recommendations

  • 쿼리에 "포함"과 같은 작업을 사용하지 마십시오. 예상되는 항목을 알고 필터링하려는 경우 "EQUAL TO" 또는 다른 특정 필터 연산자를 사용하여 동일한 조건을 적용합니다.
  • 워크플로우에서 데이터를 작성하는 동안 인덱싱되지 않은 필드로 가입하지 마십시오.
  • 업무 시간 외에 가져오기 및 내보내기 등의 프로세스가 수행되는지 확인하십시오.
  • 모든 일상 활동에 대한 일정이 있는지 확인하고 일정을 준수합니다.
  • 일별 프로세스 중 하나 또는 일부가 실패하고 해당 날짜에 실행해야 하는 경우, 시스템 성능에 영향을 줄 수 있으므로 수동 프로세스를 시작할 때 충돌하는 프로세스가 실행되고 있지 않은지 확인하십시오.
  • 가져오기 프로세스 중에 또는 수동 프로세스가 실행될 때 일일 캠페인이 실행되지 않도록 하십시오.
  • 모든 행에 필드를 복제하지 않고 하나 또는 여러 참조 테이블을 사용합니다. 키/값 쌍을 사용할 때 숫자 키를 선택하는 것이 좋습니다.
  • 짧은 문자열을 사용할 수 있습니다. 참조 테이블이 외부 시스템에 이미 있는 경우 이를 재사용하면 Adobe Campaign과의 데이터 통합이 용이해집니다.

일대다 관계 one-to-many-relationships

  • 데이터 설계는 유용성과 기능에 영향을 줍니다. 일대다 관계가 많은 데이터 모델을 디자인하는 경우 사용자가 애플리케이션에서 의미 있는 논리를 구성하는 것이 더 어려워집니다. 일대다 필터 논리는 기술 전문가가 아닌 마케터가 올바르게 구성하고 이해하기 어려울 수 있습니다.
  • 사용자가 쿼리를 더 쉽게 작성할 수 있도록 하기 때문에 모든 필수 필드를 한 테이블에 포함하는 것이 좋습니다. 때로는 조인을 방지할 수 있는 경우 테이블 간에 일부 필드를 복제하는 것이 성능에도 좋습니다.
  • 특정 기본 제공 기능은 일대다 관계(예: 오퍼 가중치 공식 및 게재)를 참조할 수 없습니다.

큰 테이블 large-tables

Adobe Campaign은 타사 데이터베이스 엔진을 사용합니다. 공급업체에 따라 큰 표에 대해 성능을 최적화하려면 특정 디자인이 필요할 수 있습니다.

다음은 큰 테이블과 복잡한 조인을 사용하여 데이터 모델을 디자인할 때 따라야 할 몇 가지 일반적인 모범 사례입니다.

  • 추가 사용자 지정 수신자 테이블을 사용할 때는 각 게재 매핑에 대한 전용 로그 테이블이 있는지 확인하십시오.
  • 특히 사용되지 않는 열을 식별하여 열의 수를 줄입니다.
  • 여러 조건 및/또는 여러 열의 조인과 같은 복잡한 조인을 방지하여 데이터 모델 관계를 최적화합니다.
  • 조인 키의 경우 항상 문자 문자열보다는 숫자 데이터를 사용합니다.
  • 로그 보존의 깊이를 최대한 줄일 수 있습니다. 더 자세한 기록이 필요한 경우 계산을 집계하거나 사용자 지정 로그 테이블을 처리하여 더 큰 기록을 저장할 수 있습니다.

표 크기 size-of-tables

테이블 크기는 레코드 수와 레코드당 열 수의 조합입니다. 둘 다 쿼리 성능에 영향을 줄 수 있습니다.

  • A 작은 크기 테이블은 게재 테이블과 유사합니다.
  • A 중간 크기 테이블은 수신자 테이블의 크기와 동일합니다. 고객당 하나의 기록이 있습니다.
  • A 대형 테이블은 브로드 로그 테이블과 유사합니다. 고객당 많은 레코드가 있습니다.
    예를 들어 데이터베이스에 1천만 명의 수신자가 포함되어 있는 경우 브로드 로그 테이블에는 약 1억 ~ 2억 개의 메시지가 포함되어 있으며 게재 테이블에는 수천 개의 레코드가 포함되어 있습니다.

PostgreSQL에서 행을 피하려면 8KB를 초과할 수 없습니다. 토스트 메커니즘. 따라서 시스템의 최적의 성능(메모리 및 CPU)을 유지하기 위해 열의 수와 각 행의 크기를 최대한 줄이십시오.

행 수는 성능에도 영향을 줍니다. Adobe Campaign 데이터베이스는 타기팅 또는 개인화 목적으로 활발하게 사용되지 않는 기록 데이터를 저장하도록 설계되지 않았습니다. 이것은 작업 데이터베이스입니다.

행 수가 많은 것과 관련된 성능 문제를 방지하려면 데이터베이스에 필요한 레코드만 보관하십시오. 다른 모든 레코드는 타사 데이터 웨어하우스로 내보내고 Adobe Campaign 운영 데이터베이스에서 제거해야 합니다.

다음은 테이블 크기와 관련된 몇 가지 모범 사례입니다.

  • 적은 필드와 더 많은 숫자 데이터로 큰 테이블을 디자인합니다.
  • 큰 숫자 유형의 열(예: Int64)을 사용하여 부울 값과 같은 작은 숫자를 저장하지 마십시오.
  • 테이블 정의에서 사용하지 않는 열을 제거합니다.
  • Adobe Campaign 데이터베이스에 이전 데이터나 비활성 데이터를 유지하지 마십시오(내보내기 및 정리).

예를 들면 다음과 같습니다.

이 예제에서는

  • 다음 거래거래 품목 1000만 개 이상의 큰 테이블.
  • 다음 제품저장 표는 10,000개 미만으로 더 작습니다.
  • 제품 레이블 및 참조가 제품 테이블.
  • 다음 거래 품목 테이블에는 다음 링크만 있습니다. 제품 테이블, 숫자
recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1