규모를 위한 설계
19개 언어로도 제공
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect 과정 7장의 학습 가이드입니다. 먼저 네 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
이 장은 파트 2와 시험의 Large Data Volumes 영역(20%)을 열고, Data Modeling의 데이터 스큐도 함께 다룹니다. 쿼리 설계는 다음 장이고, 이 장은 볼륨, 핫스팟, 대규모 공유, 수명 주기를 다룹니다. 플랫폼 숫자는 바뀌니, 의지하기 전에 최신 값을 확인하십시오.
시험 대비
섹션 제목: “시험 대비 ”하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.
LDV-1: 확장되는 모델
- 오늘의 볼륨이 아니라 보존 기간 전체의 성장을 기준으로 설계 크기를 정하고, 자식 수를 곱한다는 것을 압니다. (오늘 얼마나 큰지 묻지 마십시오, 이제 자식을 곱하십시오)
- 볼륨이 쿼리 이상의 것에 영향을 준다는 것을 압니다. 공유, 소유권, 잠금, 목록 보기, 보고서, 배치, 적재, 삭제, 복구. (느려지는 것은 쿼리만이 아닙니다)
- 통제된 비정규화가 언제 규모 때문에 정당화되는지, 그리고 그 비용이 무엇인지 압니다. (깔끔한 모델이 비싼 모델이 될 수 있습니다)
- 운영 CRM을 데이터 웨어하우스로 만들면 안 되고, 보고서 스냅샷은 데이터 웨어하우스 전략이 아니라는 것을 압니다. (핵심 CRM을 데이터 웨어하우스로 만들지 마십시오)
- 볼륨에는 모양이 있다는 것을 압니다. 무엇을 하는 레코드 2,000만 개인가? (볼륨에는 모양이 있습니다)
DM-5: 데이터 스큐
- Test knowledge: I know parent-child skew and the guidance of no more than about 10,000 children per parent; it’s a design threshold, not a cliff. Where security allows, Controlled by Parent on the child takes away the parent’s implicit shares to maintain. (Parent-Child Skew) ⟲
- 인위적인 부모에 대한 계정 풀 해법과, 자리 표시용 부모를 사용자에게서 숨겨야 한다는 것을 압니다. (“미할당” 계정, 그리고 계정 풀)
- Test knowledge: I know Salesforce’s best practice of no more than 10,000 children for one master-detail parent, and what master-detail brings at volume: no owner on the detail, cascade delete, no reparenting unless allowed, roll-up summaries, parent locking. I count the children before I choose master-detail or lookup, and I know converting back to a lookup needs no roll-up summaries on the master. (Master-Detail at Volume) ⟲
- Test knowledge: I know ownership skew (one user owning more than 10,000 records of an object) and the fix: no role, or a separate stable role at the top, and out of public groups used by sharing rules. (Ownership Skew) ⟲
- 조회 스큐를 압니다. 많은 활성 레코드가 레코드 하나를 가리키는 것, 그리고 그것이 일으킬 수 있는 레코드 잠금. (조회 스큐)
- 위험한 스큐와 무해한 스큐를 개수만이 아니라 활동으로 구별할 수 있습니다. (모든 스큐가 똑같이 위험하지는 않습니다)
- 실제 비즈니스 엔티티의 스큐는 가짜 사본이 아니라 의미 있는 분할(물류 센터마다 하위 계정)로 해결합니다. (Steve Trucking: 핫스팟은 어디에 있을까요?)
DM-2: 대규모 공유
- 접근 구조(소유자, 역할, 그룹, 공유)도 데이터이고, 함께 커진다는 것을 압니다. (공유도 데이터입니다)
- Test knowledge: I know the share object (
AccountShare,Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. (The Share Table Has Its Own Number of Zeros) ⟲ - 대용량에서 역할 계층 변경은 데이터 작업이므로 안정성이 설계 기능이라는 것을 압니다. (역할 계층은 조직도가 아닙니다)
- Test knowledge: I know deferred sharing calculations: make all the changes, then recalculate once in a maintenance window, tested first in a full copy sandbox. (Sharing Recalculation Is Real Work) ⟲
- Test knowledge: I know granular locking (on by default) lets unrelated group operations run together, but doesn’t fix a poor design. (Granular Locking Helps) ⟲
- 성능은 비공개여야 할 데이터를 공개로 만들 핑계가 아니라는 것을 압니다. (최적화하느라 보안을 버리지 마십시오)
LDV-2: 아카이브와 영구 삭제
- 보존, 아카이브, 영구 삭제를 구분하고, 프로젝트 초기에 정할 수 있습니다. (삭제는 피할 수 없습니다)
- 무엇이든 삭제하기 전에 백업을 갖추고, 백업과 아카이브가 다른 기능이라는 것을 압니다(Salesforce Backup & Recover, Archive). (삭제하기 전에 백업하십시오)
- Test knowledge: I can choose an archive destination by constraint: big objects, an external store through Salesforce Connect (OData, SQL adapters or a custom adapter), or Salesforce’s Archive. (Where Should the Archive Live?) ⟲
- Test knowledge: I know what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. (Where Should the Archive Live?) ⟲
- Test knowledge: I know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, Bulk API 2.0 hard delete; children before parents. (Deletion Is Inevitable) ⟲
- 3단계 아카이브(복사하고 표시, 검증, 삭제하고 전환)와, 그것이 재시작 가능해야 한다는 것을 압니다. (3단계 아카이브)
- 아카이브된 데이터는 찾을 수 있어야 하고 보안을 유지해야 한다는 것을 압니다. (아무도 찾을 수 없는 아카이브는 거의 삭제입니다, 아카이브도 여전히 안전해야 합니다)
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- Salesforce is built for transactions on structured data, on a multitenant database where Salesforce writes the SQL. Millions of records perform well because somebody designed for them. (Built for Transactions) ⟲
- My large data volume ruler (records in one object): around a million, a little drag; ten million, some effect but still performing; heading toward fifty million, list views take seconds, and past it you’re the convertible with your hair blown back; at a hundred million or more, ask whether the records should be here at all. ⟲
- What works today may fail tomorrow. ⟲
- 때로는 가장 좋은 해법이 문제를 만들지 않는 것입니다: GPS, 사진, 상태 이력을 코어 밖에 두십시오.
- 숫자는 어디를 볼지 알려 주고, 동작은 얼마나 걱정할지 알려 줍니다.
- 이 규모에서는 조직 변경이 데이터 작업이 됩니다.
- 규모를 위한 해법도 의미를 지켜야 합니다.
- 다이어그램에서 핫스팟을 찾으십시오: 화살표를 보고 양쪽에 레코드가 얼마나 쌓이는지 물으십시오.
- 실제로 설계하는 0의 개수로 테스트하십시오.
- AI는 0을 더 붙일 것입니다. 에이전트가 만드는 볼륨을 명시적으로 모델링하십시오.
- Who owns machine-created records depends on whether ownership matters for sharing. Created by and owned by aren’t the same question; decide what Owner means for each object. (Who Should Own Machine-Created Records?) ⟲
- 오늘 보관하지 않는다면, 언젠가 보관하긴 할 건가요?
- 입구를 설계할 때 출구를 설계하십시오. 객체마다 다섯 가지 답: 언제 활성 상태를 멈추는지, 어디로 가는지, 어떻게 증명하는지, 누가 어떻게 찾는지, 언제 삭제되는지.
- 에이전트가 아카이브된 데이터에 닿을 수 있는지는 비즈니스가 결정합니다.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 대용량 데이터(LDV) | 개수만이 아니라 플랫폼의 동작이 설계를 좌우할 만큼 많은 레코드 |
| 데이터 스큐(data skew) | 너무 많은 레코드가 부모, 소유자, 조회 값 하나에 몰리는 것 |
| 상위-하위 스큐 | 부모 레코드 하나 아래 자식이 너무 많은 것 |
| 소유권 스큐 | 사용자 한 명이 한 객체의 레코드를 약 10,000개 넘게 소유하는 것 |
| 조회 스큐 | 많은 활성 레코드가 레코드 하나를 참조해 잠금 경합을 일으키는 것 |
| 계정 풀 | 인위적인 부모의 자식을 나눠 갖는 여러 개의 자리 표시용 부모 |
| Controlled by Parent | A sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain |
| Share object | The table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause |
| Big object | An object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only |
| 공유 재계산 | 소유자, 역할, 그룹, 규칙이 바뀐 뒤 플랫폼이 접근 권한을 다시 계산하는 것 |
| 연기된 공유 계산 | 변경 묶음이 끝날 때까지 재계산을 미뤘다가 한 번만 실행하는 것 |
| 세분화된 잠금 | 그룹 멤버십 테이블 중 작업에 필요한 부분만 잠그는 것 |
| 보존 | 데이터를 얼마나 오래, 왜 보관하는지 |
| 아카이브 | 비즈니스에 필요한 접근은 유지하면서 데이터를 활성 워크로드 밖으로 옮기는 것 |
| 영구 삭제 | 보존 기간이 끝난 데이터를 영구히 제거하는 것 |
| 3단계 아카이브 | 복사하고 표시, 검증, 그다음 삭제하고 전환 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. 한 회사가 1년에 배송 100만 건을 하고, 30퍼센트씩 성장하며, 5년을 보관합니다. 어떤 볼륨을 위해 설계하나요?
100만 건이 아니라 5년간 보관되는 배송 약 900만 건, 그리고 그 자식들입니다. 배송당 1.6개로 품목 약 1,450만 개, 배송당 여덟 번으로 상태 이벤트 7,200만 건. 오늘 얼마나 큰지 묻지 마십시오를 다시 읽으십시오.
2. “미할당 연락처”라는 계정 하나 아래 연락처 30만 개가 있습니다. 어떻게 하겠습니까?
인위적인 상위-하위 스큐입니다. 연락처를 자리 표시용 부모로 이루어진 계정 풀에 나누고, 각각을 기준선 아래로 유지하며, 그 자리 표시용 부모를 일반적인 비즈니스 화면에서 숨기십시오. 아니면 연락처에 정말 계정이 필요한지 물으십시오. “미할당” 계정, 그리고 계정 풀을 다시 읽으십시오.
3. 한 리테일 파트너가 작업 주문 360만 건을 갖게 됩니다. 누군가 Redrock 001, 002, 003 계정을 제안합니다. 어떻게 보나요?
안 됩니다. 실제 비즈니스 엔티티를 오염시킵니다. 물류 센터마다 하위 계정처럼 비즈니스가 알아보는 분할을 찾고, 완료된 배송을 아카이브해 활성 자식을 적게 유지하십시오. Steve Trucking: 핫스팟은 어디에 있을까요?를 다시 읽으십시오.
4. 통합 사용자 하나가 레코드 200만 개를 소유하고, 곧 조직 개편으로 옮겨질 지역 역할에 있습니다. 위험은 무엇이고, 해법은 무엇인가요?
옮기면 레코드 200만 개에 대한 접근 재계산이 강제됩니다. 대량 레코드 소유자에게는 역할을 주지 않거나 맨 위의 별도의 안정적인 역할을 주고, 공유 규칙 그룹에서 빼고, 이 레코드들에서 소유권이 정말 접근을 좌우해야 하는지 정하십시오. 소유권 스큐를 다시 읽으십시오.
5. 조직 개편으로 주말 동안 역할, 그룹, 공유 규칙 수백 개가 바뀝니다. 어떻게 진행하나요?
데이터 작업으로 진행합니다. 풀 샌드박스에서 실제 볼륨으로 테스트하고, 공유 계산을 연기하고, 모든 변경을 한 다음, 합의된 유지 보수 창에서 한 번만 재계산하고, 대비책을 갖춘 채 검증하십시오. 공유 재계산은 진짜 일입니다를 다시 읽으십시오.
6. 팀이 복사와 삭제를 한 번에 하는 작업 하나로 레코드 2,000만 개를 아카이브할 계획입니다. 무엇을 바꾸겠습니까?
세 단계로 하십시오. 복사하고 대기로 표시, 아카이브 검증(건수, 식별자, 관계, 조회), 그다음 삭제하고 전환. 1,400만 번째 레코드에서 실패해도 안전하게 다시 시작할 수 있도록 상태를 두고, 무엇이든 삭제하기 전에 백업하십시오. 3단계 아카이브를 다시 읽으십시오.
7. 고객은 Salesforce 밖에 데이터를 저장하고 싶어 하지 않지만, 여러 해의 예약 이력을 보관해야 합니다. 아카이브는 어디에 둘 수 있을까요?
플랫폼 안입니다. 빅 오브젝트나 Salesforce의 Archive. 빅 오브젝트라면 접근 경로부터 계획하십시오. 표준 UI나 보고서가 없고 인덱스로 쿼리합니다. 그리고 아카이브된 예약을 활성 예약 아래에 보여 주는 식으로 찾을 수 있게 유지하십시오. 아카이브는 어디에 두어야 할까요?를 다시 읽으십시오.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (새 탭에서 열림), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- 각 모듈의 더 알아보기 섹션에는 그 사실의 근거가 된 Salesforce 문서가 나와 있습니다.