Show Menu
화제×

데이터 모델 모범 사례

이 문서에서는 Adobe Campaign 데이터 모델을 디자인하는 동안 주요 권장 사항에 대해 간략하게 설명합니다.
Campaign 내장 테이블 및 그 상호 작용에 대한 자세한 내용은 Campaign Classic 데이터 모델 섹션을 참조하십시오.
캠페인 스키마를 시작하려면 이 설명서를 읽어 보십시오. 이 문서에서 Adobe Campaign 데이터베이스의 개념 데이터 모델을 확장하기 위해 확장 스키마 구성 방법 을 알아봅니다 .

개요

Adobe Campaign 시스템은 매우 유연하며 초기 구현 이상으로 확장할 수 있습니다. 그러나 가능성은 무한하지만 현명한 의사 결정을 내리고 데이터 모델 디자인을 시작할 강력한 기반을 구축하는 것이 중요합니다.
이 문서에서는 Adobe Campaign 툴을 적절하게 설계하는 방법을 배울 수 있는 일반적인 활용 사례와 모범 사례를 제공합니다.

데이터 모델 아키텍처

Adobe Campaign Standard는 강력한 크로스채널 캠페인 관리 시스템으로 온라인과 오프라인 전략을 연계하여 개인화된 고객 경험을 제공할 수 있습니다.

고객 중심의 접근 방식

대부분의 이메일 서비스 제공업체는 목록 중심의 접근 방식을 통해 고객과 커뮤니케이션하고 있지만 Adobe Campaign은 관계형 데이터베이스를 사용하여 고객과 고객의 속성을 보다 광범위하게 파악합니다.
이 고객 중심의 접근 방법은 아래 차트에 나와 있습니다. 회색 수신자 테이블은 모든 것이 구축되는 주 고객 테이블을 나타냅니다.
각 테이블의 설명에 액세스하려면 로 이동하여 목록에서 리소스 Admin > Configuration > Data schemas ​를 선택하고 탭을 Documentation 클릭합니다.
Adobe Campaign 기본 데이터 모델이 이 문서에 표시됩니다 .
Adobe Campaign Classic에서는 사용자 지정 고객 테이블을 만들 수 있습니다. 그러나 대부분의 경우 이미 사전 구성된 추가 표와 기능이 있는 표준 수신자 테이블을 활용하는 것이 좋습니다.

Adobe Campaign용 데이터

Adobe Campaign으로 전송할 데이터는 무엇입니까? 마케팅 활동에 필요한 데이터를 결정하는 것은 매우 중요합니다.
Adobe Campaign은 데이터 웨어하우스나 보고 도구가 아닙니다. 따라서 모든 가능한 고객 및 관련 정보를 Adobe Campaign으로 가져오거나 보고서를 작성하는 데만 사용할 데이터를 가져오려고 하지 마십시오.
Adobe Campaign에서 속성이 필요한지 여부를 결정하려면 속성이 다음 카테고리 중 하나에 해당하는지 자신에게 문의하십시오.
  • 세그멘테이션에 사용되는 속성
  • 데이터 관리 프로세스에 사용되는 속성(예: 집계 계산)
  • 개인화에 사용되는 속성
이러한 속성에 해당되지 않는 경우 Adobe Campaign에서 이 속성이 필요하지 않을 가능성이 높습니다.

데이터 유형 선택

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

필드 선택

타깃팅 또는 개인화 목적이 있는 필드는 테이블에 저장해야 합니다. 즉, 필드가 개인화된 이메일을 보내는 데 사용되지 않거나 쿼리의 기준으로 사용되는 경우 디스크 공간이 필요한 반면, 이것은 쓸모 없는 것입니다.
하이브리드 인스턴스와 온-프레미스 인스턴스의 경우 FDA(외부 데이터에 액세스할 수 있는 옵션 기능)는 캠페인 프로세스 중에 "즉각적인" 필드를 추가해야 하는 필요성을 다룹니다. FDA가 있다면 모든 것을 가져올 필요는 없습니다. 자세한 내용은 통합 데이터 액세스 정보를 참조하십시오 .

키 선택

대부분의 테이블에서 기본적으로 정의된 자동 기능 외에도 일부 논리 또는 비즈니스 키(계정 번호, 클라이언트 번호 등)를 추가하는 것이 좋습니다. 나중에 가져오기/조정 또는 데이터 패키지에 사용할 수 있습니다. 자세한 내용은 식별자를 참조하십시오 .
효율적인 키는 성능에 필수적입니다. 표의 키로 항상 숫자 데이터 유형을 선호해야 합니다.
SQLServer 데이터베이스의 경우 성능이 필요한 경우 "클러스터된 인덱스"를 사용하는 것을 고려해 볼 수 있습니다. Adobe에서 처리하지 않으므로 SQL에서 만들어야 합니다.

전용 테이블스페이스

스키마의 테이블스페이스 속성을 사용하여 테이블에 대한 전용 테이블스페이스를 지정할 수 있습니다.
설치 마법사를 사용하면 유형별로(데이터, 임시 및 인덱스) 객체를 저장할 수 있습니다.
전용 테이블스페이스는 분할, 보안 규칙, 유동적이고 유연한 관리, 향상된 최적화 및 성능에 보다 적합합니다.

식별자

Adobe Campaign 리소스에는 세 개의 식별자가 있으며 추가 식별자를 추가할 수 있습니다.
다음 표에서는 이러한 식별자 및 해당 용도를 설명합니다.
식별자
설명
권장사항
ID
  • id는 Adobe Campaign 테이블의 실제 기본 키입니다. 바로 사용 가능한 표의 경우 시퀀스에서 생성된 32비트 번호입니다
  • 이 식별자는 일반적으로 특정 Adobe Campaign 인스턴스에 고유합니다.
  • 자동 생성된 ID는 스키마 정의에 표시될 수 있습니다. autok=" true" 속성을 검색합니다.
  • 자동 생성된 식별자는 워크플로우 또는 패키지 정의에서 참조로 사용할 수 없습니다.
  • ID가 항상 증가하는 숫자라는 가정을 해서는 안 됩니다.
  • 기본 테이블의 id는 32비트 숫자이므로 이 유형을 변경할 수 없습니다. 이 번호는 같은 이름의 섹션에 있는 "시퀀스"에서 가져옵니다.
이름(또는 내부 이름)
  • 이 정보는 테이블에 있는 레코드의 고유 식별자입니다. 이 값은 일반적으로 생성된 이름으로 수동으로 업데이트할 수 있습니다.
  • 이 식별자는 다른 Adobe Campaign 인스턴스에 배포할 때 값을 유지하며 비워 둘 수 없습니다.
  • 개체가 환경에서 다른 개체로 배포되도록 되어 있는 경우 Adobe Campaign에서 생성된 레코드 이름의 이름을 변경합니다.
  • 개체에 namespace 속성( 스키마 등)이 있는 경우 이 공통 네임스페이스는 만들어진 모든 사용자 정의 개체에 적용됩니다. 일부 예약된 네임스페이스는 사용할 수 없습니다. nms , xtk .
  • 개체에 네임스페이스(예: 워크플로 또는 배달 )가 없는 경우 이 네임스페이스 개념은 내부 이름 개체의 접두사로 추가됩니다. namespaceMyObjectName .
  • 공백 "", 세미열 ":" 또는 하이픈 "-"과 같은 특수 문자는 사용하지 마십시오. 이러한 모든 문자는 밑줄 "_"(허용되는 문자)로 대체됩니다. 예를 들어 "abc-def" 및 "abc:def"는 "abc_def"로 저장되고 서로를 덮어씁니다.
레이블
  • 레이블은 Adobe Campaign에서 개체 또는 레코드의 비즈니스 식별자입니다.
  • 이 개체는 공백과 특수 문자를 허용합니다.
  • 그렇다고 기록의 고유성을 보장하지는 않는다.
  • 개체 레이블의 구조를 결정하는 것이 좋습니다.
  • Adobe Campaign 사용자의 레코드 또는 개체를 식별하기 위한 가장 사용자 친화적인 솔루션입니다.

사용자 정의 내부 키

기본 키는 Adobe Campaign에서 만든 모든 테이블에 필요합니다.
대부분의 조직은 외부 시스템에서 레코드를 가져옵니다. 수신자 테이블의 물리적 키가 "id" 속성이지만 사용자 지정 키도 확인할 수 있습니다.
이 사용자 지정 키는 Adobe Campaign을 제공하는 외부 시스템의 실제 레코드 기본 키입니다.
기본 테이블에 자동 및 내부 키가 모두 있으면 내부 키가 물리적 데이터베이스 테이블에서 고유 인덱스로 설정됩니다.
사용자 지정 테이블을 만들 때 다음 두 가지 옵션이 있습니다.
  • 자동 생성된 키(id)와 내부 키(사용자 지정)의 조합입니다. 이 옵션은 시스템 키가 정수가 아닌 복합 키일 경우에 유용합니다. 정수는 큰 테이블에서 더 높은 성과를 제공하고 다른 테이블과 결합합니다.
  • 기본 키를 외부 시스템 기본 키로 사용합니다. 이 솔루션은 일반적으로 서로 다른 시스템 간의 일관된 키를 사용하여 데이터를 가져오고 내보내는 방법을 단순화하므로 선호하는 솔루션입니다. 키 이름이 "id"이고 외부 값(자동 생성되지 않음)으로 채워질 경우 자동 실행을 사용하지 않도록 설정해야 합니다.
워크플로우에서 자동화를 참조로 사용하면 안 됩니다.

시퀀스

Adobe Campaign 기본 키는 모든 기본 테이블에 대해 자동으로 생성되는 ID이며 사용자 지정 표에 대해 동일할 수 있습니다. 자세한 내용은 이 섹션을 참조하십시오 .
이 값은 숫자 시퀀스를 생성하는 데 사용되는 데이터베이스 개체인 시퀀스라는 ​값에서 가져옵니다.
두 가지 유형의 시퀀스가 있습니다.
  • 공유 : 동일한 시퀀스에서 두 개 이상의 테이블이 해당 id를 선택합니다. 즉, id 'X'를 한 테이블에서 사용하는 경우 동일한 시퀀스를 공유하는 다른 테이블에 해당 id 'X'의 레코드가 없을 것입니다. XtkNewId 는 Adobe Campaign에서 사용할 수 있는 기본 공유 시퀀스입니다.
  • 전용 : 시퀀스에서 해당 id를 선택하는 테이블이 한 개뿐입니다. 일반적으로 시퀀스 이름에는 테이블 이름이 포함됩니다.
시퀀스는 32비트 정수 값이며 사용 가능한 값의 제한된 최대 개수입니다. 21억 4000만 달러. 최대 값에 도달한 후 ID를 재활용하기 위해 시퀀스가 0으로 돌아갑니다.
이전 데이터를 제거하지 않은 경우, 그 결과는 고유한 키 위반이 되며, 이는 플랫폼 상태 및 사용에 대한 차단이 됩니다. Adobe Campaign은 통신(배달 로그 표에 영향을 줄 때)을 전송할 수 없으며 성능에 큰 영향을 줍니다.
따라서 연간 60억 개의 이메일을 180일 단위로 전송하면 ID가 4개월 만에 바닥날 수 있습니다. 이러한 문제를 방지하려면 볼륨에 따라 제거 설정을 지정해야 합니다. 자세한 내용은 이 섹션을 참조하십시오 .
기본 키가 autoPK인 Adobe Campaign에서 사용자 지정 테이블을 만드는 경우 사용자 지정 전용 시퀀스가 해당 테이블과 체계적으로 연결되어 있어야 합니다.
기본적으로 사용자 지정 시퀀스는 +1,000부터 +2.1BB 사이의 값을 가집니다. 기술적으로, 네거티브 ID를 활성화함으로써 전체 범위의 4BB를 얻을 수 있습니다. 이 ID는 주의해서 사용해야 하며 부정 ID에서 양수로 교차할 때 ID가 하나씩 손실됩니다. 레코드 0은 생성된 SQL 쿼리에서 일반적으로 Adobe Campaign Classic에서 무시됩니다.
관련 항목:

인덱스

색인은 성능에 필수적입니다. 스키마에서 키를 선언하면 키 필드에 인덱스가 자동으로 만들어집니다. 키를 사용하지 않는 쿼리에 대해 더 많은 색인을 선언할 수도 있습니다.
성능을 향상시킬 수 있으므로 추가 색인을 정의하는 것이 좋습니다.
그러나 다음 사항에 주의하십시오.
  • 색인 사용은 액세스 패턴에 적용됩니다. 색인 최적화는 데이터베이스 디자인에서 중요한 부분을 차지하기 때문에 전문가들이 해결해야 합니다. 인덱스 추가는 데이터베이스 유지 관리에 연결된 반복적인 워크플로우입니다. 성능 문제를 해결하기 위해 단계별로 수행됩니다.
  • 색인은 전체 표 크기를 늘립니다(색인 자체를 저장하려면).
  • 열에 인덱스를 추가하면 데이터 읽기 액세스(SELECT)의 성능이 향상되지만 UPDATE(데이터 쓰기 액세스)의 성능이 저하될 수 있습니다.
  • 이는 데이터 삽입 도중 성능에 영향을 주므로 색인은 크기와 수로 제한되어야 합니다.
  • 필요할 때 색인을 추가하지 마십시오. 필수 항목인지 확인하고 쿼리의 전반적인 성능을 향상시키십시오(테스트 및 학습).
  • 일반적으로 쿼리가 레코드의 10% 이상을 반환하지 않는다는 것을 알고 있으면 인덱스가 효율적입니다.
  • 정의해야 하는 인덱스를 신중하게 선택합니다.
  • 기본 색인을 기본 테이블에서 제거하지 마십시오.

색인을 관리하는 것은 매우 복잡해질 수 있기 때문에 어떻게 작동하는지 이해하는 것이 중요합니다. 이러한 복잡성을 설명하기 위해 이름과 성을 필터링하여 받는 사람을 검색하는 등의 기본 예를 살펴보겠습니다. 이렇게 하려면:
  1. 데이터베이스의 모든 받는 사람이 나열된 폴더로 이동합니다. 자세한 내용은 프로필 관리를 참조하십시오 .
  2. 필드를 마우스 오른쪽 단추로 First name 클릭합니다.
  3. 선택합니다 Filter on this field .
  4. 필드에 대해 이 작업을 Last name 반복합니다.
해당 필터 2개가 화면 상단에 추가됩니다.
이제 다양한 필터 조건에 따라 First name Last name 필드에 대해 검색 필터링을 수행할 수 있습니다.
이제 이러한 필터에 대한 검색 속도를 높이기 위해 색인을 추가할 수 있습니다. 하지만 어떤 색인을 사용해야 하는가?
이 예는 PostgreSQL 데이터베이스를 사용하는 호스팅 고객에게 적용됩니다.
다음 표는 아래 설명된 세 개의 인덱스가 첫 번째 열에 표시된 액세스 패턴에 따라 사용되거나 사용되지 않는 경우를 보여줍니다.
검색 조건
인덱스 1(이름 + 성)
색인 2(이름만)
인덱스 3(성만)
댓글
이름은 "조니"입니다.
사용됨
사용됨
사용되지 않음
이름이 index 1의 첫 번째 위치에 있으므로 어쨌든 사용됩니다. 성명에 기준을 추가할 필요가 없습니다.
이름은 "조니"이고 성은 "스미스"입니다.
사용됨
사용되지 않음
사용되지 않음
동일한 쿼리에서 두 속성이 모두 검색되므로 두 속성을 결합하는 색인만 사용됩니다.
성은 "Smith"입니다.
사용되지 않음
사용되지 않음
사용됨
인덱스의 속성 순서를 고려합니다. 이 순서와 일치하지 않으면 색인을 사용하지 않을 수 있습니다.
이름은 "Joh"로 시작됩니다.
사용됨
사용됨
사용되지 않음
"왼쪽 검색"을 사용하면 색인이 활성화됩니다.
이름은 "nny"로 끝납니다.
사용되지 않음
사용되지 않음
사용되지 않음
"Right search"는 색인을 비활성화하고 전체 검색을 수행합니다. 일부 특정 인덱스 유형은 이 사용 사례를 처리할 수 있지만 Adobe Campaign에서는 기본적으로 사용할 수 없습니다.
이름에 "John"이 포함됨
사용되지 않음
사용되지 않음
사용되지 않음
"left" 및 "right" 검색의 조합입니다. 이후 버전이므로 색인이 비활성화되고 전체 검색이 수행됩니다.
이름은 "john"입니다.
사용되지 않음
사용되지 않음
사용되지 않음
색인은 대소문자를 구분합니다. 대/소문자를 구분하지 않도록 하려면 "upper(firstname)"와 같은 SQL 함수를 포함하는 특정 인덱스를 만들어야 합니다. "unaccent(firstname)"와 같은 다른 데이터 변환도 동일하게 수행해야 합니다.

데이터 유지 - 정리 및 제거

Adobe Campaign은 데이터 웨어하우스나 보고 도구가 아닙니다. 따라서 Adobe Campaign 솔루션의 성능을 향상시키기 위해 데이터베이스 성장은 계속 제어되어야 합니다. 이를 실현하기 위해 아래의 몇 가지 우수 사례를 따르는 것이 도움이 될 수 있습니다.
기본적으로 Adobe Campaign 게재 및 추적 로그의 보존 기간은 180일입니다. 정리 프로세스가 실행되어 이전 로그가 제거됩니다.
  • 로그를 길게 유지하려면 데이터베이스 크기와 전송된 메시지 볼륨에 따라 신중하게 결정해야 합니다. 다시 말해 Adobe Campaign 시퀀스는 32비트 정수입니다.
  • 사용 가능한 모든 ID를 사용할 수 있는 위험을 제한하기 위해 이러한 표에 한 번에 10억 개 이상의 레코드(사용 가능한 21억 4천만 ID의 약 50%)를 포함하지 않는 것이 좋습니다. 이를 위해서는 일부 고객이 보존 기간을 180일 이하로 낮춰야 합니다.
사용자 지정 테이블은 표준 정리 프로세스로 삭제되지 않습니다. 이는 첫째 날에 필요하지 않지만, 성능 문제로 이어질 수 있으므로 사용자 정의 테이블에 대한 삭제 프로세스를 만드는 것을 잊지 마십시오.
Adobe Campaign에는 기록 필요성을 최소화하는 몇 가지 솔루션이 있습니다.
  • Adobe Campaign 외부에 있는 데이터 웨어하우스의 데이터를 내보냅니다.
  • 마케팅 관행에 따라 충분한 공간을 확보하면서 더 적은 공간을 사용할 수 있는 집계된 값을 생성합니다. 예를 들어 Adobe Campaign에서 마지막 구매를 추적하기 위해 전체 고객 거래 내역이 필요하지 않습니다.
스키마에서 "deleteStatus" 속성을 선언할 수 있습니다. 레코드를 지운 것으로 표시한 다음 정리 작업에서 삭제를 연기하는 것이 더 효율적입니다.

성능

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

일반 추천

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

일대다 관계

  • 데이터 디자인은 유용성과 기능에 영향을 줍니다. 일대다 관계로 데이터 모델을 설계하면 애플리케이션에서 의미 있는 논리를 만드는 것이 더 어렵습니다. 일대다 필터 로직은 기술적인 면을 잘 모르는 마케터가 올바르게 구성하거나 이해하기가 어려울 수 있습니다.
  • 사용자는 쿼리를 손쉽게 작성할 수 있으므로 하나의 테이블에 모든 필수 필드를 포함하는 것이 좋습니다. 조인을 피할 수 있는 경우 테이블 간에 일부 필드를 복제하는 것도 성능이 좋은 경우가 있습니다.
  • 특정 내장 기능은 일대다 관계(예: 오퍼 가중치 공식 및 배달)를 참조할 수 없습니다.

큰 표

Adobe Campaign은 타사 데이터베이스 엔진에 의존합니다. 공급업체에 따라 큰 표의 성능을 최적화하려면 특정 디자인이 필요할 수 있습니다.
다음은 큰 표와 복잡한 조인을 사용하여 데이터 모델을 디자인할 때 따라야 할 몇 가지 일반적인 우수 사례입니다.
  • 추가 사용자 지정 수신자 테이블을 사용할 때는 각 배달 매핑에 대한 전용 로그 테이블이 있어야 합니다.
  • 특히 사용하지 않은 열을 확인하여 열 수를 줄입니다.
  • 여러 조건 및/또는 여러 열에 연결된 연결과 같은 복잡한 조인을 방지하여 데이터 모델 관계를 최적화합니다.
  • 조인 키의 경우 항상 문자 문자열이 아닌 숫자 데이터를 사용하십시오.
  • 로그 보존 깊이를 최대한 줄일 수 있습니다. 더 깊은 내역이 필요한 경우 계산 및/또는 사용자 정의 로그 테이블을 처리하여 더 큰 내역을 저장할 수 있습니다.

표 크기

테이블 크기는 레코드 수와 레코드당 열 수의 조합입니다. 둘 다 쿼리의 성능에 영향을 줄 수 있습니다.
  • 작은 크기의 테이블은 배달 테이블과 유사합니다.
  • 중간 크기 표는 받는 사람 테이블의 크기와 동일합니다. 고객 한 명당 1개의 기록을 가지고 있습니다.
  • 는 Broad 로그 테이블과 유사합니다. 고객당 기록이 많다. 예를 들어 데이터베이스에 수신자가 1천만 명인 경우 Broad 로그 테이블에는 약 1억~2억 개의 메시지가 포함되고 Delivery 테이블에는 천 개의 레코드가 포함됩니다.
PostgreSQL에서 TOAST 메커니즘을 방지하기 위해 행은 8KB를 초과할 수 없습니다. 따라서 시스템의 최적 성능(메모리 및 CPU)을 유지하려면 열 수와 각 행의 크기를 최대한 줄이십시오.
행 수도 성능에 영향을 줍니다. Adobe Campaign 데이터베이스는 타깃팅 또는 개인화 용도로 적극적으로 사용되지 않는 내역 데이터를 저장하도록 설계되지 않았습니다. 이것은 운영 데이터베이스입니다.
행 수와 관련된 성능 문제를 방지하려면 데이터베이스에 필요한 레코드만 보관하십시오. 다른 모든 레코드는 타사 데이터 웨어하우스로 내보낸 후 Adobe Campaign 운영 데이터베이스에서 제거해야 합니다.
다음은 표 크기와 관련된 몇 가지 우수 사례입니다.
  • 필드 및 숫자 데이터가 더 적은 대형 표를 디자인합니다.
  • 큰 열 유형을 사용하지 마십시오(예: Int64)를 사용하여 부울 값과 같은 작은 숫자를 저장합니다.
  • 테이블 정의에서 사용되지 않은 열을 제거합니다.
  • Adobe Campaign 데이터베이스에 내역 또는 비활성 데이터를 유지하지 마십시오(내보내기 및 정리).
다음은 한 예입니다.
이 예에서:
  • 트랜잭션 및 트랜잭션 항목 테이블은큽니다. 1,000만 이상.
  • 제품 스토어 ** 테이블이 더 작습니다. 10,000 미만.
  • 제품 레이블과 참조가 제품 테이블에 배치됩니다.
  • 트랜잭션 항목 테이블에는 제품 테이블에 대한 링크만 있으며 이는 숫자입니다.