콘텐츠로 이동
SteveTechArcSteveTechArc Courses

What Works Today May Fail Tomorrow

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장이자 파트 2: 규모를 위한 아키텍처의 시작. 이전: 마스터 데이터와 정체성.

A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. The object is the same, the fields are the same, the relationships are the same. Add a few zeros, and the architecture changes. ⟲

Start with what the platform is built for. Salesforce’s core database handles “upwards of 1.1 trillion transactions per month,” and Salesforce’s own architects describe it as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow (새 탭에서 열림)). It’s built for transactions, on a multitenant database where Salesforce writes the SQL, not you. At small volumes you can ignore the platform’s shape. At large volumes, it reminds you it’s there. ⟲

So I teach large data volumes with a rough ruler, for records in a single object. At about 1 million, there’s a little drag as dashboards and reports show up. Around 10 million, some effect, but still performing. Heading toward 50 million, you notice it: list views take two, three, four seconds. Past 50 million, you’re driving a convertible with your head out the window, and your hair is blown back: you’ve got to be streamlined, and you’ve got to know what you’re doing. At 100 million or more, I start asking a different question: should these records be here at all? That’s a rule of thumb from the community, not a Salesforce limit. The lesson is that volume changes the design, and most large-data-volume problems are design problems: cheap to prevent, expensive to fix. ⟲

The LDV ruler The LDV ruler, four steps in records in a single object. One million: a little drag; dashboards and reports take a moment, depending on how you filter. Ten million: some effect, but still performing. Fifty million: the convertible; list views take two, three, four seconds, reports and dashboards take time, and past it your hair is blown back. One hundred million and up: should it be here? When will you archive, and is this operational data or an audit log? Underneath: records in a single object; a rule of thumb from the community, not a Salesforce limit. {"author": "Steve Simpson", "blueprint": "1.1.0", "builder": "standard 1.53.0", "built": "2026-10-29", "id": "DGM-DA-LDV-11", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} 1 million a little drag YOU NOTICE Dashboards and reports take a moment Depends on how you filter 10 million some effect YOU NOTICE Some effect Still performing 50 million the convertible YOU NOTICE List views take 2, 3, 4 seconds Reports and dashboards take time Past it, your hair is blown back 100 million + should it be here? YOU ASK When will you archive? Operational data, or an audit log? Records in a single object. A rule of thumb from the community, not a Salesforce limit. © 2026 Twinshark LLC · stevetecharc.com
클릭하여 확대

파트 1은 우리에게 보는 법을 가르쳤습니다. 파트 2는 아키텍처에 무게를 싣습니다. 이 장은 첫 번째 시험입니다. 뼈대가 0의 무게를 견딜 수 있을까요?

A small four-seat propeller plane parked beside a wide-body passenger jet that towers over it: the same job, built for a hundred times the load.

Image generated with AI. ⟲

이 장의 생각들

섹션 제목: “이 장의 생각들 ”
  • 0의 개수로 계획하십시오. 오늘의 볼륨이 아니라 성장과 보존 기간 전체를 포함해서요. 자식 여덟 개씩을 가진 부모 100만 개는 레코드 100만 개짜리 문제가 아닙니다.
  • What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
  • 깔끔하게 설계한 다음, 볼륨이 이유를 줄 때 의도적으로 물러서십시오. 그리고 핵심 CRM을 데이터 웨어하우스로 만들지 마십시오.
  • 10,000 children per parent is a design threshold, not a limit: Salesforce draws the same line, and past about 20,000 I’ve seen visible lag. Account pools work, but hide the placeholder parents. ⟲
  • 대량 레코드를 소유하는 사용자는 역할 계층 밖에 두거나, 맨 위의 안정적인 별도 역할에 두고, 공유 규칙 그룹에서 빼십시오.
  • 기계가 만든 레코드의 소유자는 소유권이 공유에 얼마나 중요한지에 따라 정합니다.
  • 대규모에서는 보안 재정렬이 데이터 작업입니다. 공유 계산을 연기하고, 풀 샌드박스에서 리허설하고, 한 번만 다시 계산하십시오. 그리고 비공개가 느리다는 이유로 데이터를 공개로 만들지 마십시오.
  • 오늘 아카이브하지 않는다면, 언젠가는 할까요? 첫날부터 삭제를 결정하고, 삭제 전에 백업하고, 아카이브를 찾을 수 있게 유지하십시오.
  • 아카이브된 데이터에 에이전트가 계속 닿을 수 있는지는 비즈니스가 결정합니다.

Where volume causes problems

섹션 제목: “Where volume causes problems”
무엇이 커지는가무엇이 느려지는가어디서 다루는가
한 객체의 레코드쿼리, 목록 보기, 보고서모듈 1, 8장
부모 하나 아래의 자식, 소유자 하나 아래의 레코드잠금, 공유 재계산모듈 2
Children under one master-detail parentLocking, roll-ups, cascade delete, a hard-to-undo choiceModule 2
사용자, 역할, 그룹, 규칙접근 권한 재계산, 재정렬모듈 3
아무도 쓰지 않는 이력전부, 그리고 저장 공간과 위험모듈 4

이 장의 길

섹션 제목: “이 장의 길 ”

네 개 모듈, 각각 독립적으로 읽을 수 있습니다.

  1. When Volume Changes Everything. Built for transactions, the ruler, the Number of Zeros at 30% growth, denormalizing for scale, and keeping analytics out of core. ⟲
  2. Hot Spots: Ownership, Parent and Lookup Skew. Too many records pointing at one thing, account pools, master-detail at volume (count the children before you choose the relationship), high-volume owners, and who owns agent-created records. ⟲
  3. 볼륨이 공유 모델을 만날 때. 접근 레버로서의 소유권, 안정적인 계층, 연기된 공유 계산, 세분화된 잠금, 대규모 파트너 격리.
  4. 오늘 아카이브하지 않는다면…. 첫날부터의 수명 주기, 삭제 전 백업, 아카이브를 둘 곳, 3단계 아카이브, 오래된 데이터와 에이전트.

아키텍트가 여기서 결정하는 것

섹션 제목: “아키텍트가 여기서 결정하는 것 ”
  • 각 객체가 얼마나 커지는지, 성장과 보존 기간 전체를 반영해서.
  • 레코드가 어디에 몰리는지, 그리고 어떤 쏠림이 위험한지.
  • 소유권이 무엇을 뜻하는지, 에이전트가 만드는 객체를 포함한 모든 대용량 객체에 대해.
  • 접근 모델이 어떻게 확장되는지, 그리고 큰 재정렬을 어떻게 계획하는지.
  • 데이터가 어떻게 나가는지: 아카이브, 영구 삭제, 백업, 그리고 누가 여전히 찾을 수 있는지.

시험 너머: 에이전트는 0을 더합니다. 사람이 하나 만들던 곳에서 열 개를 만들고, 기본값으로 그 전부를 소유하고, 누구보다 빨리 데이터를 조회하고, 누군가 막지 않으면 아카이브까지 닿을 수 있습니다. 각 모듈은 그 문제 영역에서 AI가 바꾸는 것으로 끝납니다.

더 알아보기

섹션 제목: “더 알아보기 ”

다음: 쿼리와 조회 아키텍처