コンテンツにスキップ
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部：規模に向けた設計の始まりです。前へ：マスターデータとID。

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部ではアーキテクチャに重みをかけます。この章が最初の試験です。その骨格はゼロの数を支えられるでしょうか？

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. ⟲

この章の考え方

Section titled “この章の考え方 ”
  • **ゼロの数で計画する。**今日の件数ではなく、成長を織り込み、保持期間全体で考えます。子を8件ずつ持つ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

Section titled “Where volume causes problems”
増えるもの遅くなるもの扱う場所
1つのオブジェクトのレコードクエリ、リストビュー、レポートモジュール1、第8章
1件の親の下の子、1人の所有者の下のレコードロック、共有の再計算モジュール2
Children under one master-detail parentLocking, roll-ups, cascade delete, a hard-to-undo choiceModule 2
ユーザー、ロール、グループ、ルールアクセスの再計算、再編成モジュール3
誰も使わない履歴すべて、加えてストレージとリスクモジュール4

この章の道筋

Section titled “この章の道筋 ”

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ステップのアーカイブ、そしてエージェントと古いデータ。

ここでアーキテクトが決めること

Section titled “ここでアーキテクトが決めること ”
  • **各オブジェクトがどこまで大きくなるか。**成長を織り込み、保持期間全体で。
  • **レコードがどこに集中するか。**そして、どの集中が危険か。
  • **所有が何を意味するか。**エージェントが作成するものも含め、大量の各オブジェクトについて。
  • **アクセスモデルがどう拡張するか。**そして大きな再編成をどう計画するか。
  • **データがどう出ていくか：**アーカイブ、パージ、バックアップ、そして誰がまだそれを見つけられるか。

**試験の先へ：**エージェントはゼロを増やします。人が1件作るところで10件作り、既定ですべてを所有し、誰よりも速く取得し、誰かが止めない限りアーカイブにも手を伸ばします。各モジュールの最後で、その部分の問題についてAIが何を変えるかを扱います。

さらに学ぶ

Section titled “さらに学ぶ ”

次へ： クエリと取得のアーキテクチャ