試験対策：パフォーマンスについて
以下2つの試験を同時に勉強しているのですが、試験範囲が被っていたので共通化して1つの記事にしました。
Salesforce の大量のデータ、ユーザが存在するときに非機能要件満たすためにはどう設計すれば良いだろうか、とかそこらへんのベストプラクティスとかをまとめました。
データスキュー
一つの親レコード (主従関係、参照関係) に対して、子レコードがたくさん紐付いてる状態のことを データスキュー といいます。この状態だと、例えば子レコードがめちゃめちゃある関連リストを持つレコードの詳細ページを開いた時に、いつまでたっても読み込みが終わらなくて表示されねーーー！って状態になる (らしいです。時間がある時に検証したい)。具体的な事例をかくと、展示会とかで集めた取引先がわからない取引先責任者をすべてダミー取引先に紐づける、とかありがちな例が挙げられます。目安としては 10,000 件超えるとやばいらしいので、そんな時は分割を検討するか、そもそもそんなリレーションにならないよう設計を再考慮するなどをした方がよいです。
スキニーテーブル / カスタムインデックス
エンジニアたるもの「車輪の再開発はしない」ということで、下記の SlideShare が参考になりました。
まとめるのがめんどくさくなってきたわけではありません。
ほかにも、カスタムインデックスを作成できる条件ってのは重要なので覚えていた方がよいです。
ディビジョン
Oracle でいうところのパーティショニングテーブルのことです。ユーザの詳細項目のところに ディビジョン って項目がありますよね。あれって何に使うんだろう、って思ってたのですがこの機能で利用します。
ですが、日本では使っている組織はあまりない、ってのを聞いたことがあります。
共有の再計算が走るタイミング
パフォーマンスに影響があるので調べておいた方が良いです。
上級アドミンの試験範囲にもあった気がするので覚えておいて損はないと思います
アクセス権の管理には内部的には3つのテーブルを利用しているとのこと。
RoleAndSubordinates とか RoleAndInternalSubordinates のテーブルは、下位ユーザの情報も持っているテーブルだからアクセスが早い。
Object Sharing テーブルにアクセスする条件
3つの条件があります。逆にいうと、これを満たさないように設計するとパフォーマンスが改善されるかもしれません。
大規模な再配置用のツール
営業チーム、テリトリー、取引先割り当ての大規模な変更を行う際には、上に書いた共有の再計算等々により、パフォーマンスに大きく影響がでます。そのために、以下のようなツールが用意されています。
いずれも、有効化するためには Salesforce 社への連絡が必要な機能 とのことです。私も実際には試したことのない機能なので、以下、語尾が伝聞の書き方となります。笑
並列処理による共有ルールの再適用
共有ルールの再適用処理を並列化します。
たしかに処理は早くなりそうですが、、、ロックの競合に引っかかる可能性が高くなるんじゃないかなぁ、と個人的に思うのですがどうなんでしょうか。
共有メンテナンスの延期
共有ルールの評価に非常に時間がかかる場合には、評価を一時的に停止できる機能だそうです。
そうすることで、組織のメンテナンス時間中に共有ルールを適用するといったことができるようです。
詳細なロック (Granular Lock)
大量データを一度に更新しすぎてロックが競合する場合はこれとのこと。
Salesforce では公開グループやロールを変更すると、たとえ小さな変更でも GroupMembership というオブジェクト全体にロックがかかってしまうので負荷が高い。また、ロックが競合しやすい。そんな時にはグラニュラーロックを有効化する。らしいです。
なんで括弧書きで英語名も書いてるかっていうと、ヘルプによっては詳細なロックだったり、Granular Lock だったりするからです。