大規模に向けた設計
ほかに 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章の学習ガイドです。まず4つのモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、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) ⟲
- 参照のスキューを知っている：多くの現役のレコードが1件のレコードを指し、それがレコードのロックを引き起こし得る。（参照のスキュー）
- 危険なスキューと無害なスキューを、件数だけでなく活動で見分けられる。（すべてのスキューが同じように危険なわけではない）
- 本物のビジネスエンティティのスキューは、意味のある分割（物流センターごとの子取引先）で解決し、偽物のコピーは決して作らない。（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ステップのアーカイブ）
- アーカイブされたデータは見つけられる状態を保ち、セキュリティも保たなければならないことを知っている。（誰も見つけられないアーカイブは、ほとんど削除と同じ、アーカイブも安全でなければならない）
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- 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、写真、状況の履歴はコアの外に置く。
- 数字はどこを見るべきかを教えてくれ、振る舞いはどれだけ心配すべきかを教えてくれる。
- この規模では、組織の変更がデータ操作になる。
- 規模のための解決策も、意味を保たなければならない。
- **図の上でホットスポットを見つける：**矢印を見て、それぞれの側にどれだけのレコードが積み重なるかを問う。
- 本当に設計の対象にしているゼロの数でテストする。
- **AIがさらにゼロを足す。**エージェントが生み出す量を明示的にモデル化する。
- 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?) ⟲
- 今日アーカイブしていないなら、いつかアーカイブすることがあるのか？
- **入口を設計するときに、出口も設計する。**オブジェクトごとに5つの答え：いつ現役でなくなるか、どこへ行くか、どう証明するか、誰かがどう見つけるか、いつ削除するか。
- アーカイブされたデータにエージェントが届くかどうかは、ビジネスが決めること。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| 大量データ（LDV） | 件数だけでなくプラットフォームの振る舞いが設計を形づくるほど多くのレコード |
| データスキュー | 一つの親、所有者、参照値に集中しすぎたレコード |
| 親子のスキュー | 1件の親レコードの下にある多すぎる子 |
| 所有のスキュー | 1人のユーザーが1つのオブジェクトのレコードを約1万件超所有する状態 |
| 参照のスキュー | 多くの現役のレコードが1件のレコードを参照し、ロックの競合を引き起こす状態 |
| 取引先プール | 人工的な親の子を分け合う、いくつかの仮置きの親 |
| 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ステップのアーカイブ | コピーして印をつけ、検証し、それから削除して切り替える |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. ある会社は年100万件の配送を行い、年30%成長し、5年分を保持します。どの量に向けて設計しますか？
100万件ではなく、5年間で保持される約900万件の配送、そしてその子です。配送1件あたり1.6件で約1,450万件の明細、1件あたり8件で7,200万件の状況イベント。今日の大きさを尋ねないを読み直しましょう。
2. 「未割り当ての取引先責任者」という一つの取引先の下に30万件の取引先責任者があります。どうしますか？
人工的な親子のスキューです。取引先責任者を、それぞれしきい値の下に収まる仮置きの親の取引先プールに分散し、それらの仮置きの親を通常の業務の画面から隠します。あるいは、そもそも取引先責任者に取引先が必要なのかを問いましょう。「未割り当て」の取引先と、取引先プールを読み直しましょう。
3. ある小売パートナーは360万件の作業指示を持つことになります。誰かがRedrock 001、002、003という取引先を提案します。あなたの見解は？
だめです。本物のビジネスエンティティを壊します。物流センターごとの子取引先のように、ビジネスが認識できる分け方を探し、完了済みの配送をアーカイブして現役の子を少なく保ちましょう。Steve Trucking：ホットスポットはどこか？を読み直しましょう。
4. 統合ユーザーが200万件のレコードを所有し、組織再編で動くことになっている地域のロールにいます。リスクと解決策は？
動かすと、200万件のレコードにわたってアクセスの再計算が起きます。大量のレコードを所有するユーザーにはロールを与えないか、最上位の別の安定したロールに置き、共有ルールのグループから外し、そもそもこれらのレコードで所有がアクセスを決めるべきかを判断しましょう。所有のスキューを読み直しましょう。
5. 組織再編で、ある週末に何百ものロール、グループ、共有ルールが変わります。どう実行しますか？
データ操作として扱います。フルコピーサンドボックスで実際の量でテストし、共有の計算を延期し、すべての変更を行い、合意したメンテナンス時間帯に一度だけ再計算し、代替策を用意したうえで検証します。共有の再計算は本物の仕事であるを読み直しましょう。
6. チームは、コピーと削除を行う一つのジョブで2,000万件のレコードをアーカイブするつもりです。何を変えますか？
3ステップにします。コピーして「待ち」の印をつけ、アーカイブを検証し（件数、識別子、リレーション、取得）、それから削除して切り替えます。状態を持たせて、1,400万件目での失敗から安全に再開できるようにします。そして何かを削除する前にバックアップを。3ステップのアーカイブを読み直しましょう。
7. 顧客はSalesforceの外にデータを保存したくありませんが、何年分もの予約の履歴を保持する必要があります。アーカイブはどこに置けますか？
プラットフォーム上です。Big Object、またはSalesforceのArchive。Big Objectを使うなら、まずアクセスの道筋を計画しましょう。標準のUIもレポートもなく、クエリはインデックスを通じて行います。そして、現役の予約の下にアーカイブされた予約を表示するなどして、見つけられる状態を保ちます。アーカイブはどこに置くべきか？を読み直しましょう。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce 認定 Platform Data アーキテクト受験ガイド （新しいタブで開きます）, 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のドキュメントを挙げています。