Salesforce Architect Meetup Osaka #02 20191018

1. ⼤量データ(LDV)の考慮点
(LDV: Large Data Volume)
認定 Data Architecture and Management デザイナー
2019/10/18（⾦）
Salesforce Architects Meetup Osaka#02

2. 今回の対象︓
認定 Data Architecture and Management デザイナー
本⽇の
トピック
2

3. 今回の対象︓
認定 Data Architecture and Management デザイナー
http://tandc.salesforce.com/credentials
3

4. 認定 Data Architecture and Management デザイナー
に求められるスキル・知識
4

5. Salesforceの
データストレージソリューション

6. Salesforceの
データストレージソリューション
データストレージ
ソリューション
データの所在
Salesforce UI
での検索・表⽰・
変更
⾃動化プロセス
WF・トリガ・
プロセスビルダー
件数規模
標準・カスタム
オブジェクト
Salesforce(コア) ○ ○
⽬安として
〜2,000万件
Salesforce Connect
外部システム
(OData または
Apex Connectorで参照)
○ 不可
⽬安として
〜2,000万件
Heroku Connect
(⼀⽅向/双⽅向同期)
Salesforce
(Herokuとコアと同期)
○ ○ ⽬安として
〜2,000万件
Heroku Connect
(Proxy)
Salesforce(Heroku)
(Salesforce Connectの
外部Objectとして利⽤)
○ 不可
⽬安として
〜2,000万件
Big Objects Salesforce(⾮RDB) 不可 不可 〜数⼗億⾏
Einstein Analytics Salesforce(BI) 不可 不可 〜10億⾏
6

7. Salesforce Connect の例
7
外部オブジェクトを
シームレスに表⽰

8. データストレージソリューションの選択
https://trailhead.salesforce.com/ja/content/learn/
modules/big-data-strategy/choose-the-right-big-
data-solution 8
データのコピーを
Salesforceに置く
必要はある︖
顧客向けのモバイル
アプリでデータを公開
する必要はある︖
どのくらいの
データが格納
されますか︖
顧客向けのモバイル
アプリでデータを公開
する必要はある︖
2000万件
未満
データは2,000万件
を超えて成⻑して
いますか︖
2000万件を
超える
データはどの
ように分析さ
れますか︖ データの⼀部の
ビジネスロジッ
クを⾃動化する
必要があります
か︖
同じエン
ティティで
集約・
サブセット

9. Salesforceデータストレージでの
⼤量データの取り扱い

10. マルチテナントを可能とするアーキテクチャ
データ スキーマ
マルチテナントアーキテクチャ
組織(org)
インスタンス
データ スキーマ
組織(org)
仮想テーブル、メタデータ、
セキュリティ（共有・権限）、
性能（ガバナ制限）
10

11. RDBMSとSalesforceのアーキテクチャ⽐較
アプリケーション
11
インデックス テーブル外部キー
統計情報 実⾏計画
RDBMS
SQL 結果セット
アプリケーション
Salesforce
SQL 結果セット
RDBMS︖
SOQL 結果（レコード）
マルチテナント
アーキテクチャ
標準項⽬
インデックス
カスタム項⽬
関連
参照・主従
権限・共有
ガバナ制限

12. RDBMSとSalesforceのLDV対策の例
12
CRUD RDBMS Salesforce
C:登録 ・登録時はインデックスを削除、後で作成
・可能であれば、登録後に関連を設定
・共有の適⽤を延期
・WFルールなど⾃動化機構を無効化
R:参照
・選択性の⾼いインデックスを利⽤
・クエリする項⽬を少なく
・Mview、パーティショニング
・インデックス／カスタムインデックス
・スキニーテーブル
U:更新 ・・・
・UpdateとUpsertの特性を理解、
使い分け
D:削除 ・全件削除はtruncate
・論理削除、物理削除
・ごみ箱
・切り捨て
⾮
同
期
処
理
の
活
⽤
(
バ
þ
チ
︑
Bulk)

13. LDV︓データモデリングの考慮
親レコード ⼦レコード
Ø データスキュー(Skew、偏り)の回避
例︓⼦レコードの更新時、内部では親・⼦両⽅がロックされる。
→複数スレッドで更新を⾏う場合、ロックが取得できず失敗する場合がある
・1件の親レコードが⼤量の⼦レコードを持つ場合に考慮する(⽬安として1万件)
・1⼈のユーザが同じObjのレコードを⼤量に所有する場合、
1件のレコードに⼤量のレコードが関連付けられている場合、
などのスキュー(偏り)があるときも、共有やロックの問題が起こり得る。
⼦レコード
⼦レコード
⼦レコード
13

14. LDV︓クエリ・検索の考慮
Ø ⾮同期処理の活⽤
①Apexの⼀括処理(バッチApex)
バッチ単位で⾮同期処理する。
最⼤5,000万件のレコードにクエリを実⾏して処理できる。
14

15. LDV︓クエリ・検索の考慮
Ø ⾮同期処理の活⽤
②⼀括クエリ(Bulk APIクエリ)
10万件(既定値)〜25万件(最⼤)のチャンク(データの塊)に分割して抽出する。
最⼤15GBのデータを取得できる(1GB x 15ファイル)。
チャンクが1GBを超える場合や、取得に10分以上かかる場合、失敗する。
PK Chunking(IDによるチャンク分割)を検討する。
1,000万件を超えるオブジェクトをクエリする場合に推奨。
15
外部システム
Bulk API
例
Dataloader
①クエリの処理時間は2分まで
Bulk API
ジョブ
バッチ チャンク
チャンク
③結果は、1GBまでのファイルが
最⼤15個作成される
結果ファイル
結果ファイル
結果ファイル
PK チャンクが有効な場合、
分割して処理される
結果ファイル

16. LDV︓クエリ・検索の考慮
Ø スキャンするデータの削減
①スキニーテーブル(Skinny、痩せた)
特定のオブジェクトの⼀部の項⽬のみで構成されたDBテーブル
16
標準項⽬・カスタム項⽬は、
内部では別TBLで保持。
都度結合して結果セットを作成
⇒検索コストが⾼い
ユーザが参照
したい項⽬
スキニーテーブル
・参照に必要な項⽬をすべて保持（結合不要）
・参照しない項⽬は保持しない
（スキャンの効率良）
考慮点︓
・作成はSalesforceに申請が必要
・データは同期されるが、オーバーヘッドもあり
・Sandboxにコピーされない（Full Sandbox除く）
・ユーザーからは⼀切⾒えない
・利⽤するかどうかはクエリオプティマイザが決定

17. LDV︓クエリ・検索の考慮
Ø スキャンするデータの削減
②インデックス／カスタムインデックス
下記の項⽬には⾃動的にインデックスが作成される︓
ID、Name、RecordTypeId、Division、CreatedDate、参照関係、主従関係、
Systemmodstamp(LastModifiedDate)、Email(取引先責任者・リード)
カスタムインデックスの作成︓
・外部ID、ユニーク項⽬には⾃動的に作成
・Salesforce サポートへの申請により作成
考慮点︓
・クエリでインデックスが使⽤されるかは、オプティマイザの判断による
（統計情報から選択性を判断）
17

18. LDV︓読み込み(登録・ロード)の考慮
Ø ロードの前にデータをきれいにする
https://www.slideshare.net/DeveloperForceJapan/jp-extreme-salesforce-datavolumes/32
18

19. LDV︓読み込み(登録・ロード)の考慮
Ø 重要ではないプロセスを先送りする
①組織の共有設定
「⾮公開」は、レコード追加時に共有が適⽤される（時間がかかる）。
⇒「公開/参照・更新可能」として後で共有を適⽤する。必要以上にデータを保護しすぎない。
②オブジェクト間の関連
オブジェクト間の関連が多いと、レコード追加時に必要なチェックも増える。
⇒後で関連を確⽴することができれば、レコード追加スループットは向上する。
③共有ルール
レコード追加都度チェックが必要となる。
⇒レコード追加後に共有ルールを有効にする。共有適⽤の延期を検討する。
④ワークフロールール、⼊⼒規則、トリガ
レコード追加都度チェックが必要となる。
⇒無効化し、レコード追加後にApex⼀括処理（バッチ）で処理する
19

20. LDV︓読み込み(登録・ロード)の考慮
Ø 効率よいAPIの利⽤
①Bulk API の利⽤
・⼤量のデータを処理するのに向いている。
・サーバ側では要求を複数のジョブに分割し、⾮同期で処理される。
20
外部システム
Bulk API
例
Dataloader
①バッチの登録数は、24時間あたり
10,000個まで
Bulk API
ジョブ
バッチ
バッチ
チャンク
チャンク
②バッチのあたりの処理時間は10分まで
③バッチのあたりの処理件数は10,000件まで
さらに内部では
チャンクに分割して処理される
⼊⼒ファイル

21. リソース

22. 参考︓認定 Data Architecture and Management デザイナー
Trailmix
22

23. 参考︓⼤量データの取り扱いに関する Trailhead モジュール
23

24. 参考︓Webinar資料
https://www.slideshare.net/DeveloperForceJapan/
jp-extreme-salesforce-datavolumes
https://www.slideshare.net/DeveloperForceJapan/
tips-30066265
24

25. 参考︓⼤量データの取り扱いに関する 開発者ドキュメント
25