Salesforceでの大規模データの取り扱い

Salesforceでの大規模データの
取り扱い

Force.com アーキテクチャベストプラクティス

Safe harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995:

This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties
materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results
expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be
deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other
financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any
statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our
operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of
intellectual property and other litigation, risks associated with possible mergers and acquisitions, the immature market in which we
operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new
releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization
and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com,
inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. This documents and others
containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.

Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently
available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based
upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-
looking statements.

ハッシュタグでShareしよう : #forcewebinarjp

スピーカー

Daisuke Kawamoto Mitsuhiro Okamoto
Customer Centric Engineer Developer Programs Manager
@DaisukeSfdc @mitsuhiro

Join the conversation: #forcewebinar

Developer Force Japanをフォロー下さい!!

@developerforcej / #forcewebinarjp

Developer Force Japan



Developer Force group

アーキテクトコアリソースページ
•  アーキテクト向け注目記事
•  Twitterをフォロー
週ごとにUpdate
http://developer.force.com/architect

日本語の場合
DeveloperForce Japan
Blogをチェック!!
http://jp.force.com/blogs

質問がある場合には?

§  質問がある場合にはGoToMeetingのチャットを経由して(Organizer
宛 or 全体に)質問して下さい。
§  後ほどスピーカーが要望のおおい質問から順番にWebinarの最後に
回答していきます。
§  あとでチャットのログを遡りますので、質問は一度すれば大丈夫です。


本日のゴール

理解・認識


どれぐらいの規模のデータがSalesforce Platform
で扱えますか?

どれぐらいだと
思います？


ベストプラクティス
デザインロードコンフィグメンテナンス


デザインベストプラクティス


デザインベストプラクティス

データ量と
ビジネス要件増加

クエリテキスト
デザインサーチ


ビジネス要件


アプリケーション及びユーザの要件を理解する

どれぐらいのどれぐらいの業務
レコード数が、データが本当に必
リストビューや要なのか?
レポートにおいて
適切か?

データを履歴
としてアーカイブ
したり、ビューや
レポートで使用し
ないようにできな
いか?


例: 意味のあるリストビューのデザイン

人間はどれぐらいのデータレコードを扱う事ができますか?


データボリュームと
データ増加


データのボリューム及び増加量を予測する

データのロード時
どのようなに不要なタイプの
タイミングで、データをスキーマ
どれぐらいデータから取り除く事は
の量は増加しますできますか?
か?

アーカイブでデー
タの増加を相殺で
きますか?
ハードデリート?
ゴミ箱を空にす
る?


例: プロジェクトの月毎及び年毎の成長
!
250"
大容量オブジェクト X (月毎)
200"
トランザクション増加率
•  レコード数
•  GB
150"
データ増加率
•  レコード数
100" •  GB

アーカイブによる相殺
50" •  レコード数
•  GB

0"
3"

"

3"

3"

3"

"

3"

"
"

"

3"

"
13

13

13

13

13

13
)1

)1

r)1

)1

)1

t)1
n)
b)

g)

p)

v)

c)
ar

ay
n

l
Ju

Oc
Ap

De
No
Au
Ja

Fe

Se
Ju
M

M


キーとなる成功要因 : データ量を最小化する

過度ではない、アーカイブ不要な
要件にあったデータは
データロードの破棄をする計画を
立てる
プランを作成する

アーカイブ後、
ハードデリートか、
ゴミ箱を空にする


クエリのデザイン


効果的なクエリのデザインを学ぶ

インデックスを SOQLの最適化を
有効活用する理解する

選択リストビュー、
レポート、SOQL
クエリを
デザインする


インデックスを有効活用する


Cheat Sheet(早見表):
インデックス済みフィールド

※英語


例: 特定のSOQLをモニタリングして改善する


テキストサーチ


効果的なサーチのデザインを学ぶ

インデックスを SOSLの最適化を
有効活用する理解する

選択リストビュー、
レポート、SOSL
をデザインする


"テキスト"系の項目は検索インデックス化される


Cheat Sheet(早見表):
サーチフィールド

※英語


どのようにサーチは行を見つけるか？
インデックス

数百万
の
DB
レコード

サーチ文字
に合致する
データを全
インデックサーチに合致 DBが共有ルール
スから探すしたデータののチェックなど
レコードIDをを行う
処理するため
にDBへ送る


おさらい: デザイン時のベストプラクティス

ü  要件を認識する
ü  データの増加量を想定する
ü  データのボリュームを最小化する
ü  効率的なオペレーションをデザインする
ü  効率的な共有モデルを適用する


データロードのベストプラクティス


データロードのベストプラクティス

ロードの前にデー AppExchangeの
タをきれいにしてツール利用を
おく検討する

よりよりスルー
無効化や遅延処理
プットの為にBulk
できるものを知る
APIを利用する


オーバーヘッドを避けるようにデータを準備する
1 2 3 4 5

標準化浄化補強(オプション) 重複除去確認
名称検索 & 置換会社名 & 住所アイデンティティ Sandboxへ
アクメ株式会社 -> アクメ(株 ) Hot -> Hight
&スコアマッチロード
Cold -> Low 渡邉渡邊 -> 80%

住所命名規約階層構造マージ編集検証
渡邉部長 , 渡邊聡
アクメ-会議資料-453 アクメ株式会社 - 本社
JP,Japan -> 日本 -> 渡邉聡
アクメ - イギリス

郵便番号データ変換統計主従関係本番環境へ
統合、買収、独立の見直しロード
取引先、部門、商談
取引先責任者
アーカイブ
&フィルタ


データロード処理前に無効化しておく

検証ルール

ワークフロールール

トリガ


Force.com Bulk APIを理解する


Bulk APIのリミットについて留意する


ユーティリティを使えばもっと簡単に処理ができる


共有ルールの計算を遅延させる

もしくは、デフォルトの公開状態でロードする


おさらい: データロード時のベストプラクティス

ü  整形済みのデータをロードする
ü  Bulk APIを利用する
ü  APIを使ったロードユーティリティを検討する
ü  トリガ、検証ルール、ワークフローを無効化する
ü  共有ルールの適用を延期する


コンフィグのベストプラクティス


効率的な共有モデル作成方法を学ぶ

ロール階層やグ
ループの入れ子を
データを過度に最適化する
保護しすぎない

レコードオーナー更新時のロックに
及び親レコードは留意する
適切に分配する


必要以上にデータを保護しすぎない


ロール階層を最適化する

複雑な階層構造 = より多くの時間が共有
の計算にかかる

階層は10以下にする

テリトリー管理を使っているならば、
シンプルなブランチにする


歪なデータ構造を避ける

オーナー主従関係


更新時のロックに留意する

組織ロックレコードロック

X

X

単一スレットグループ歪な主従関係をさける
小規模のロックを心がけるシーケンスがParentIDを更新します


おさらい: 設定時のベストプラクティス

ü  可能であればデータは公開で利用する
ü  ロール階層を最適化して利用する
ü  歪なデータ構造を避ける
ü  レコードロックの罠を最小限にする


メンテナンス


メンテナンス時のベストプラクティス

カスタムデータ
インデックスパーティショニ
ング

マッシュアップ
や外部データ
データのウェアハウスの
非正規化利用


カスタムインデックス


自身でインデックスを作成する


非標準のインデックスをリクエストする

サポートに単項目もしくは
２項目のインデックス作成
を依頼できる


スキニーテーブル


スキニーテーブルで、自動的に非正規化する


データのパーティショニング


ディビジョンを利用してテスト及び実装する

地域毎に

役職毎に


アプリケーションの
パーティショニング


Salesforce Platformコンポーネントを活用する

Force.com Canvasを利用すれば、
オペレーションデータと履歴データを
シームレスに統合を可能にします。

ETLプロセス

100010010

Salesforce組織はオペレーションデータ(現業務で利用しているデータ) Herokuアプリ & データベースは履歴データ
を管理するを管理する


Demo

インテグレーション


インテグレーションのベストプラクティス

ü  Salesforceのデータベースについて特性を知る
ü  履歴データをアーカイブする
ü  アーカイブしたレコードはハードデリートする
ü  外部アプリケーション (Heroku等) を分析に利用する
ü  Force.com Canvas等を利用してUIでインテグレーションをする


追加リソース

Architect Core Resources(英語)

日本語ページにも翻訳次第順次追加予定
http://jp.force.com/


直近のイベント
Customer Campany Tour
各都市ごとに開発者向けセッションもあります

4/15 ‒ 福岡 (グランドハイアット福岡)
4/17 ‒ 大阪 (ヒルトン大阪)
4/24 ‒ 名古屋 (ヒルトン名古屋)
5/21 ‒ 東京 (東京ミッドタウン)

参加無料 : http://eventjp.salesforce.com/

Webinar

2013年 - 4月28日(予定)
Visualforce & Force.com Canvas:
Salesforce.com上であなたのWebサービスを


Survey
Your feedback is crucial to the success of our webinar programs.
Thank you!

http://bit.ly/datavolumessurvey
*Look in the GoToWebinar chat
window now for a hyperlink.


Q＆A

Daisuke Kawamoto Mitsuhiro Okamoto
Customer Centric Engineer Developer Programs Manager
@DaisukeSfdc @mitsuhiro


Thank You


Salesforceでの大規模データの取り扱い

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Salesforceでの大規模データの取り扱い

Similar to Salesforceでの大規模データの取り扱い (20)

More from Salesforce Developers Japan

More from Salesforce Developers Japan (20)

Recently uploaded

Recently uploaded (8)

Salesforceでの大規模データの取り扱い