이 문서에서는 Adobe Campaign 데이터 모델을 디자인하는 동안 주요 권장 사항에 대해 간략히 설명합니다.
Campaign 내장 테이블 및 그 상호 작용에 대한 자세한 내용은 Campaign Classic 데이터 모델 섹션을 참조하십시오.
캠페인 스키마를 시작하려면 이 설명서를 읽어 보십시오. 이 문서에서 Adobe Campaign 데이터베이스의 개념 데이터 모델을 확장하기 위해 확장 스키마를 구성하는 방법을 알아봅니다.
Adobe Campaign 시스템은 매우 유연하므로 초기 구현 이후에도 확장할 수 있습니다. 그러나 가능성은 무한하지만 현명한 의사 결정을 내리고 데이터 모델 디자인을 시작할 강력한 기반을 구축하는 것이 중요합니다.
이 문서에서는 Adobe Campaign 툴을 적절하게 설계하는 방법을 배울 수 있는 일반적인 사용 사례와 모범 사례를 제공합니다.
Adobe Campaign Standard은 온라인과 오프라인 전략을 연계하여 개인화된 고객 경험을 구축할 수 있는 강력한 크로스채널 캠페인 관리 시스템입니다.
대부분의 이메일 서비스 제공업체는 목록 중심의 접근 방식을 통해 고객과 커뮤니케이션하고 있지만 Adobe Campaign은 고객과 고객의 속성을 보다 광범위하게 파악하기 위해 관계형 데이터베이스를 사용합니다.
이 고객 중심의 접근 방법은 아래 차트에 나와 있습니다. Recipient 테이블이 회색으로 표시되어 있으면 모든 것이 작성되고 있는 주 고객 테이블을 나타냅니다.
각 테이블의 설명에 액세스하려면 Admin > Configuration > Data schemas으로 이동하여 목록에서 리소스를 선택하고 Documentation 탭을 클릭합니다.
Adobe Campaign 기본 데이터 모델은 이 문서에 표시됩니다.
Adobe Campaign Classic에서는 사용자 지정 고객 테이블을 만들 수 있습니다. 그러나 대부분의 경우 이미 사전 구성된 추가 테이블 및 기능이 있는 표준 Recipient 테이블을 활용하는 것이 좋습니다.
Adobe Campaign으로 어떤 데이터를 전송해야 합니까? 마케팅 활동에 필요한 데이터를 결정하는 것은 매우 중요합니다.
Adobe Campaign은 데이터 웨어하우스나 보고 도구가 아닙니다. 따라서 가능한 모든 고객 및 관련 정보를 Adobe Campaign으로 가져오거나 보고서를 작성하는 데만 사용할 데이터를 가져오려고 하지 마십시오.
Adobe Campaign에서 속성을 필요로 하는지 여부를 결정하려면 속성이 다음 카테고리 중 하나에 해당하는지 자신에게 문의하십시오.
이러한 속성에 해당되지 않는 경우 Adobe Campaign에서 이 속성이 필요하지 않을 가능성이 큽니다.
시스템의 우수한 아키텍처와 성능을 유지하려면 아래 모범 사례를 따라 Adobe Campaign에서 데이터를 설정하십시오.
타깃팅 또는 개인화 목적이 있는 필드는 테이블에 저장해야 합니다. 즉, 필드를 개인 설정된 이메일을 보내는 데 사용하지 않거나 쿼리의 기준으로 사용할 경우 디스크 공간이 필요한 반면, 이것은 쓸모 없는 것입니다.
하이브리드 인스턴스와 온-프레미스 인스턴스의 경우 FDA(외부 데이터에 액세스할 수 있는 옵션 기능인 Federated Data Access)는 캠페인 프로세스 중에 필드를 "즉시" 추가해야 하는 필요성을 다룹니다. FDA를 가지고 있다면 모든 것을 가져올 필요가 없습니다. 자세한 내용은 통합 데이터 액세스 정보를 참조하십시오.
대부분의 표에서 기본적으로 정의된 자동 이외에 일부 논리 또는 비즈니스 키(계정 번호, 클라이언트 번호 등)를 추가하는 것을 고려해야 합니다. 나중에 가져오기/조정 또는 데이터 패키지에 사용할 수 있습니다. 자세한 내용은 식별자를 참조하십시오.
성능 향상에는 효율적인 키가 중요합니다. 숫자 데이터 유형은 항상 표의 키로 선호되어야 합니다.
SQLServer 데이터베이스의 경우 성능이 필요한 경우 "클러스터된 인덱스"를 사용하는 것을 고려해 볼 수 있습니다. Adobe에서 이 작업을 처리하지 않으므로 SQL에서 만들어야 합니다.
스키마의 테이블스페이스 속성을 사용하여 테이블에 대한 전용 테이블스페이스를 지정할 수 있습니다.
설치 마법사를 사용하면 유형별로 객체를 저장할 수 있습니다(데이터, 임시 및 인덱스).
전용 테이블스페이스는 파티셔닝, 보안 규칙 및 유동적이고 유연한 관리, 최적화 및 성능을 제공하는 데 더 적합합니다.
Adobe Campaign 리소스에는 3개의 식별자가 있으며 추가 식별자를 추가할 수 있습니다.
다음 표에서는 이러한 식별자 및 해당 용도를 설명합니다.
식별자 | 설명 | 모범 사례 |
---|---|---|
Id |
|
|
이름(또는 내부 이름) |
|
|
레이블 |
|
|
기본 키는 Adobe Campaign에서 만든 모든 표에 필요합니다.
대부분의 조직은 외부 시스템에서 레코드를 가져옵니다. 수신자 테이블의 물리적 키는 "id" 속성이지만 사용자 지정 키를 추가로 결정할 수 있습니다.
이 사용자 지정 키는 Adobe Campaign을 제공하는 외부 시스템의 실제 레코드 기본 키입니다.
기본 테이블에 자동 및 내부 키가 모두 있으면 내부 키가 물리적 데이터베이스 테이블에서 고유 인덱스로 설정됩니다.
사용자 정의 테이블을 만들 때 다음과 같은 두 가지 옵션이 있습니다.
자동화는 워크플로우에서 참조로 사용되어서는 안 됩니다.
Adobe Campaign 기본 키는 모든 기본 테이블에 대해 자동으로 생성되는 id이며 사용자 지정 표에 대해 같을 수 있습니다. 자세한 내용은 이 섹션을 참조하십시오.
이 값은 숫자 시퀀스를 생성하는 데 사용되는 데이터베이스 개체인 sequence라는 값에서 가져옵니다.
다음과 같은 두 가지 유형의 시퀀스가 있습니다.
시퀀스는 사용 가능한 값의 한정된 수가 있는 정수 32비트 값입니다.21억 4천만. 최대 값에 도달한 후 ID를 재활용하기 위해 시퀀스가 0으로 돌아갑니다.
이전 데이터가 삭제되지 않으면 그 결과는 고유한 키 위반이 되며 이는 플랫폼 상태 및 사용에 대한 차단이 됩니다. Adobe Campaign은 전달 로그 표에 영향을 줄 때 커뮤니케이션을 보낼 수 없으며 성능에 큰 영향을 미칠 수 있습니다.
따라서 연간 60억 개의 이메일을 유지 기간 180일과 함께 전송하는 고객은 4개월 후에 ID가 부족하게 됩니다. 이러한 문제를 방지하려면 볼륨에 따라 제거 설정을 지정해야 합니다. 자세한 내용은 이 섹션을 참조하십시오.
기본 키가 autoPK인 Adobe Campaign에서 사용자 지정 테이블을 만드는 경우, 사용자 지정 전용 시퀀스가 해당 테이블과 체계적으로 연결되어 있어야 합니다.
기본적으로 사용자 지정 시퀀스에는 +1,000~+2.1BB 범위의 값이 있습니다. 기술적으로, 네거티브 ID를 활성화하여 전체 범위의 4BB를 가져올 수 있습니다. 이것은 주의해서 사용해야 하며, 음수에서 양수로 건너갈 때 하나의 id가 손실됩니다.레코드 0은 생성된 SQL 쿼리에서 일반적으로 Adobe Campaign Classic에서 무시됩니다.
관련 항목:
인덱스는 성능에 필수적입니다. 스키마에서 키를 선언하면 Adobe은 키의 필드에 인덱스를 자동으로 만듭니다. 키를 사용하지 않는 쿼리에 대해 더 많은 인덱스를 선언할 수도 있습니다.
Adobe은 성능을 향상시킬 수 있으므로 추가 인덱스를 정의하는 것이 좋습니다.
그러나 다음 사항에 유의하십시오.
색인을 관리하는 것은 매우 복잡해질 수 있으므로 색인이 작동하는 방식을 이해하는 것이 중요합니다. 이러한 복잡성을 설명하기 위해 이름과 성을 필터링하여 받는 사람을 검색하는 등의 기본적인 예를 살펴보겠습니다. 방법은 다음과 같습니다.
데이터베이스에 있는 모든 받는 사람을 나열하는 폴더로 이동합니다. 자세한 내용은 프로필 관리를 참조하십시오.
First name 필드를 마우스 오른쪽 단추로 클릭합니다.
Filter on this field을(를) 선택합니다.
Last name 필드에 대해 이 작업을 반복합니다.
해당 필터 2개가 화면 상단에 추가됩니다.
이제 다양한 필터 조건에 따라 First name 및 Last name 필드에 대해 검색 필터링을 수행할 수 있습니다.
이제 이러한 필터에 대한 검색 속도를 높이기 위해 색인을 추가할 수 있습니다. 하지만 어떤 색인을 사용해야 하는가?
이 예는 PostgreSQL 데이터베이스를 사용하는 호스팅 고객에게 적용됩니다.
다음 표는 아래 설명된 3개의 인덱스를 첫 번째 열에 표시된 액세스 패턴에 따라 사용하거나 사용하지 않는 경우를 보여줍니다.
검색 기준 | 색인 1(이름 + 성) | 색인 2(이름 전용) | 색인 3(성에만 해당) | 댓글 |
---|---|---|---|---|
이름은 "조니"입니다. | 사용됨 | 사용됨 | 사용되지 않음 | 이름이 색인 1의 첫 번째 위치에 있으므로 어쨌든 사용됩니다.성을 기준으로 할 필요는 없습니다. |
이름은 "조니"이고 성은 "스미스"입니다. | 사용됨 | 사용되지 않음 | 사용되지 않음 | 두 속성이 동일한 쿼리에서 검색되므로 두 속성을 모두 결합하는 색인만 사용됩니다. |
성은 "Smith"입니다. | 사용되지 않음 | 사용되지 않음 | 사용됨 | 인덱스의 속성 순서를 고려합니다. 이 순서와 일치하지 않으면 색인을 사용하지 않을 수 있습니다. |
이름은 "Joh"로 시작합니다. | 사용됨 | 사용됨 | 사용되지 않음 | "왼쪽 검색"을 사용하면 색인이 활성화됩니다. |
이름은 "nny"로 끝납니다. | 사용되지 않음 | 사용되지 않음 | 사용되지 않음 | "올바른 검색"을 사용하면 색인이 비활성화되고 전체 검색이 수행됩니다. 일부 특정 색인 유형은 이 사용 사례를 처리할 수 있지만 Adobe Campaign에서는 기본적으로 사용할 수 없습니다. |
이름에 "John"이 있음 | 사용되지 않음 | 사용되지 않음 | 사용되지 않음 | "왼쪽" 및 "오른쪽" 검색의 조합입니다. 후기 때문에 색인을 비활성화하고 전체 스캔을 수행합니다. |
이름은 "john"입니다. | 사용되지 않음 | 사용되지 않음 | 사용되지 않음 | 인덱스는 대/소문자를 구분합니다. 대/소문자를 구분하지 않도록 하려면 "upper(firstname)"와 같은 SQL 함수를 포함하는 특정 인덱스를 만들어야 합니다. "unaccent(firstname)"와 같은 다른 데이터 변환도 동일하게 수행해야 합니다. |
큰 식탁에서 "자체" 청렴성을 주의하라. "자체" 무결성에 넓은 테이블이 있는 레코드를 삭제하면 인스턴스가 중지될 수 있습니다. 테이블이 잠겼고, 한 테이블씩 삭제된 항목이 만들어집니다. 따라서 볼륨이 큰 하위 테이블에서 "중립" 무결성을 사용하는 것이 가장 좋습니다.
링크를 외부 연결로 선언하는 것은 성능에 좋지 않습니다. 0ID 레코드는 외부 조인 기능을 에뮬레이션합니다. 링크가 자동을 사용하는 경우 외부 조인을 선언할 필요가 없습니다.
워크플로우에서 테이블을 조인할 수 있지만 Adobe은 데이터 구조 정의에서 직접 리소스 간에 공통 링크를 정의하는 것이 좋습니다.
링크는 표의 실제 데이터와 일치하도록 정의해야 합니다. 잘못된 정의는 링크를 통해 검색된 데이터에 영향을 줄 수 있습니다(예: 예기치 않게 레코드를 복제하는 경우).
표 이름으로 링크 이름을 일관되게 지정합니다.링크 이름은 먼 테이블이 무엇인지 이해하는 데 도움이 됩니다.
"id"를 접미어로 지정한 링크 이름을 지정하지 마십시오. 예를 들어 "transactionId"가 아닌 "transaction"이라는 이름을 지정합니다.
기본적으로 Adobe Campaign은 외부 테이블의 기본 키를 사용하여 링크를 만듭니다. 보다 명확하게 하자면, 링크 정의에서 연결을 명시적으로 정의하는 것이 좋습니다.
링크에 사용된 속성에 인덱스가 추가됩니다.
Adobe의 만들어진 링크와 마지막으로 수정된 링크가 많은 표에 있습니다. 이 정보가 비즈니스에 사용되지 않는 경우 링크에 noDbIndex 속성을 사용하여 인덱스를 비활성화할 수 있습니다.
링크를 디자인할 때 1-1 관계가 선언되었을 때 대상 레코드가 고유해야 합니다. 그렇지 않으면 한 개만 예상될 때 조인이 여러 레코드를 반환할 수 있습니다. 이렇게 하면 "쿼리가 예상보다 많은 행을 반환"할 때 배달 준비 중에 오류가 발생합니다. 링크 이름을 대상 스키마와 동일한 이름으로 설정합니다.
(1) 쪽의 스키마에 기수(1-N)가 있는 링크를 정의합니다. 예를 들어 관계 수신자(1) - (N) 트랜잭션은 트랜잭션 스키마에 정의해야 합니다.
링크의 역방향 카디널리티는 기본적으로 (N)입니다. revCardinality='single' 속성을 링크 정의에 추가하여 링크(1-1)를 정의할 수 있습니다.
사용자가 역방향 링크를 볼 수 없으면 링크 정의 revLink='NONE'으로 숨길 수 있습니다. 이 경우, 받는 사람에서 마지막으로 완료된 트랜잭션으로의 링크를 정의하는 것이 좋습니다(예:). 받는 사람에서 마지막 트랜잭션으로의 링크만 볼 수 있고, 트랜잭션 테이블에 역 링크가 표시되지 않아도 됩니다.
외부 조인(1-0.1)을 수행하는 링크는 시스템 성능에 영향을 줄 수 있으므로 주의해서 사용해야 합니다.
Adobe Campaign은 데이터 웨어하우스나 보고 도구가 아닙니다. 따라서 Adobe Campaign 솔루션의 성능을 향상시키기 위해 데이터베이스 성장은 계속 제어되어야 합니다. 이를 실현하려면 아래 우수 사례 중 일부를 따르는 것이 도움이 될 수 있습니다.
기본적으로 Adobe Campaign 배달 및 추적 로그는 180일의 보존 기간을 갖습니다. 정리 프로세스가 실행되어 이전 로그를 제거합니다.
캠페인 개인 정보 및 보안 지침에서 데이터 유지에 대해 자세히 알아보십시오.
이 섹션](…/…/production/using/database-cleanup-workflow.md)에서 캠페인 데이터 기본 정리 작업 과정 [에 대해 자세히 알아보십시오.
사용자 지정 테이블은 표준 정리 프로세스로 삭제되지 않습니다. 이것이 첫 번째 요일에는 필요하지 않지만, 성능 문제로 이어질 수 있으므로 사용자 정의 테이블에 대한 삭제 프로세스를 만드는 것을 잊지 마십시오.
Adobe Campaign에서 기록 필요성을 최소화할 수 있는 몇 가지 솔루션이 있습니다.
스키마에서 "deleteStatus" 속성을 선언할 수 있습니다. 레코드를 삭제로 표시한 다음 정리 작업에서 삭제를 연기하는 것이 더 효율적입니다.
언제든지 더 나은 성능을 보장하려면 아래 모범 사례를 따르십시오.
Adobe Campaign은 타사 데이터베이스 엔진을 사용합니다. 공급업체에 따라 큰 테이블에 대한 성능을 최적화하려면 특정 디자인이 필요할 수 있습니다.
다음은 큰 테이블과 복잡한 조인을 사용하여 데이터 모델을 디자인할 때 따라야 하는 몇 가지 일반적인 우수 사례입니다.
표 크기는 레코드 수와 레코드당 열 수의 조합입니다. 둘 다 쿼리 성능에 영향을 줄 수 있습니다.
PostgreSQL에서 행이 TOAST 메커니즘을 피하려면 8KB를 초과할 수 없습니다. 따라서 시스템의 최적의 성능(메모리 및 CPU)을 유지하기 위해 열 수와 각 행의 크기를 최대한 줄이십시오.
행 수는 성능에도 영향을 줍니다. Adobe Campaign 데이터베이스는 타깃팅 또는 개인화를 위해 적극적으로 사용되지 않는 내역 데이터를 저장하도록 설계되지 않았습니다. 이 데이터는 운영 데이터베이스입니다.
많은 수의 행과 관련된 성능 문제를 방지하려면 데이터베이스에 필요한 레코드만 보관하십시오. 다른 모든 레코드는 타사 데이터 웨어하우스로 내보내고 Adobe Campaign 운영 데이터베이스에서 제거해야 합니다.
다음은 표 크기와 관련된 몇 가지 우수 사례입니다.
다음은 한 예입니다.
이 예에서: