大量データを扱う際のクイックTips インデックス&スキニーテーブル編-

6,685
-1

Published on

大量データを扱う際のクイックTips インデックス&スキニーテーブル編-

  1. 1. 大量データを扱う際のクイックTips - カスタムインデックス & スキニーテーブル編 - 2014/1/15 株式会社セールスフォース・ドットコム
  2. 2. Safe Harbor Statement 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  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. breach  of  our  security  measures;  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;  risks  associated   with  new  releases  of  our  service;  and  risks  associated   with  selling  to  larger  enterprise  customers.  Further   information  on  potential  factors  that  could  affect  the   financial  results  of  salesforce.com,  inc.  are  included  in   our  registration  statement  (on  Form  S-‐‑‒1)  and  in  other   filings  with  the  Securities  and  Exchange  Commission.   These  documents  are  available  on  the  SEC  Filings   section  of  this  Web  site.   Salesforce.com,  inc.  assumes  no  obligation  and  does   not  intend  to  update  these  forward-‐‑‒looking  statements.   Any  unreleased  services  or  features  referenced  in  this   or  other  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. The  risks  and  uncertainties  referred  to  above  include  -‐‑‒   but  are  not  limited  to  -‐‑‒  risks  associated  with  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;   2
  3. 3. はじめに •  本ドキュメントは、大量(100万件以上)のレコードを Force.com上で扱う際に有用になりうる施策につい てまとめています。 •  実際のチューニングはワークフロー・トリガの有無 、データの分布等、複合的な要因に依存しますので 、あくまで参考としてご利用下さい。 •  パフォーマンスチューニングに限らず、その他開発 者向けの質問は、ディスカッションボードをご利用 下さい。 Discussion Forums日本語 https://developer.salesforce.com/forums/?communityId=09aF00000004HT8IAM 3
  4. 4. カスタムインデックス
  5. 5. Salesforceのインデックス •  クエリー(リストビュー、レポート、SOQL)の処理性能を向上させ るためのインデックスが使用できる場合がある •  標準インデックス •  次の項目に自動的に作成される Id Name OwnerId RecordTypeId CreatedDate Systemmodstamp (LastModifiedDate) Division Email (取引先責任者とリード) 参照関係項目と主従関係項目 •  カスタムインデックス •  標準インデックス対象外の任意の項目に、必要に応じて作成する •  ただし次に挙げるデータ型の項目には作成できない 複数選択リスト ロングテキストエリア 非決定性の数式 (詳細は後述) 5 リッチテキストエリア 暗号化テキスト
  6. 6. 2つのカスタムインデックスの作成方法 1.  項目を「外部ID」または「ユニーク」として定義 •  外部ID項目とユニーク項目には自動的にカスタムインデックスが作成される •  外部ID指定が可能なデータ型 •  自動採番、メール、数値、テキスト •  ユニーク指定が可能なデータ型 •  メール、数値、テキスト 2.  Salesforceテクニカルサポートに作成をリクエスト •  オブジェクト定義、データ分布、クエリーの条件等を元に、インデックスの有効性がチ ェックされる •  インデックスの作成オプションを指定する必要がある場合がある •  Null値もインデックスに含めるかどうか •  “Field__c = NULL”という条件のクエリーがあり、かつ、NULL値が少数 の場合に有効 •  チェックボックス項目の場合、True(チェック)とFalse(非チェック)のどちらをイ ンデックスに含めるか •  少数(通常は10%以下、少なくとも20%以下)しか存在しないほうの値のみを インデックス化する 6
  7. 7. 2カラムカスタムインデックス •  インデックスは単一の項目だけでなく、2つの項目の組合せに対しても作成 することができる •  2つの項目に対する組合せで絞り込み条件が指定される場合や、1つ目の項 目で絞り込み(WHERE句)、2つ目の項目でソート(ORDER BY)する場合に有 用 •  2カラムカスタムインデックスは、先頭項目のみの単一項目インデックスと しても利用できる •  Field1__c(選択リスト)とField2__c(数値)の2カラムカスタムインデックス が有効な例 •  •  •  SELECT … FROM MyObject__c WHERE Field1__c IN (‘Foo’, ‘Baa’) AND Field2__c > 0 SELECT … FROM MyObject__c WHERE Field1__c IN (‘Foo’, ‘Baa’) ORDER BY Field2__c SELECT … FROM MyObject__c WHERE Field1__c = ‘Foo’ 7
  8. 8. 数式に対するインデックス (1/2) •  数式項目にインデックスを作成するには、「決定性の」数式である必要がある •  以下のいずれかに当てはまる数式は「非決定性」と見なされ、インデックス は作成できない •  •  •  •  •  •  直接、間接に他オブジェクトの項目を参照している 常に同じ値を返すとは限らない関数 (TODAY や NOW など) を使用している 所有者、自動採番、ディビジョン、監査項目 (CreatedDateとCreatedByID以外)を 参照している インデックス付けできない項目(複数選択リストなど)を参照している マルチ通貨組織における通貨項目を使用している 特殊な機能を持つ以下の標準項目を参照している •  商談 : Amount、TotalOpportunityQuantity、ExpectedRevenue、IsClosed、 IsWon •  ケース : ClosedDate、IsClosed •  商品 : ProductFamily、IsActive、IsArchived •  ソリューション : Status •  リード : Status •  活動 : Subject、TaskStatus、TaskPriority 8
  9. 9. 数式に対するインデックス (2/2) •  非決定性の数式での絞り込みが効果的な場合の回避策 •  非数式のカスタム項目を定義し、インデックスを作成 •  トリガーなどを使って、数式の結果の値をその項目にコピーする •  3つ以上の項目に対する条件の組合せで効率的に絞り込める場合 の応用例 •  元のクエリーの検索条件 : WHERE Field1__c = ‘A’ AND Field2__c = ‘B’ AND Field3__c = ‘C' •  3つの条件は単独ではそれぞれ3分の1ずつしか絞り込めないとする •  どの2項目の組合せで2カラムカスタムインデックスを作成しても、9分の1に しか絞り込めない •  解決策 : 数式による実質的な「3カラムカスタムインデックス」 •  Field1__c + ‘|’ + Field2__c + ‘|’ + Field3__c のような数式項目 Formula__cを定義し、カスタムインデックスを作成 •  クエリーの条件を “WHERE Formula__c = ‘A|B|C’ に書き換える 9
  10. 10. インデックスが使用されない条件 •  インデックスによる選択性が低い •  •  詳細は次ページ 比較方法が「一致しない」「!=」「NOT IN」 •  可能なら結果が変わらないように比較方法を逆転させる •  Checkbox__c != FALSE → Checkbox__c = TRUE •  チェックボックス項目の例 •  Picklist__c NOT IN (‘A’, ‘B’) → Picklist__c IN (‘C’, ‘D’) •  •  A, B, C, Dの4つのオプションを持つ選択リストの例 データにNullが含まれる場合は結果が変わりうる点に注意 •  Nullを含まないインデックスが作成された項目で、比較方法が「= NULL」 •  中間一致/後方一致検索 •  •  •  中間一致: 「次の文字列を含む」, Text__c LIKE ‘%Foo%’ 後方一致: Text__c LIKE ‘%Foo’ 数値、日付、日付/時間以外の項目での範囲検索 10
  11. 11. インデックスの選択性(1/2) •  標準インデックス •  条件を満たすレコードが以下のしきい値以下の場合に「選択性が高い」 •  レコード全体のうち、最初の100万件までは30% •  レコード全体のうち、100万件を超える分の15% •  最大で100万件 •  しきい値の算出例 •  総計50万件 → 50万件 × 30% = 15万件 •  総計250万件 → 100万件 × 30% + 150万件 × 15% = 52万5000件 •  総計600万件 → 100万件 × 30% + 500万件 × 15% = 105万件 → 100万件 •  カスタムインデックス •  条件を満たすレコードが以下のしきい値以下の場合に「選択性が高い」 •  レコード全体のうち、最初の100万件までは10% •  レコード全体のうち、100万件を超える分の5% •  最大で333,333件 •  しきい値の算出例 •  総計50万件 → 50万件 × 10% = 5万件 •  総計250万件 → 100万件 × 10% + 150万件 × 5% = 17万5000件 •  総計600万件 → 100万件 × 10% + 500万件 × 5% = 35万件 → 333,333件 11
  12. 12. インデックスの選択性 (2/2) •  AND結合 •  •  •  インデックス化項目に対する2つ以上の条件がAND結合されている 各インデックスを2倍のしきい値で選択性の高低判定 選択性の高い全てのインデックスの「積」を満たすレコード数がしきい値以下なら、そ れら全てのインデックスが使用される •  全てが標準インデックスなら、標準インデックスのしきい値 •  1つでもカスタムインデックスが含まれるなら、カスタムインデックスのしきい値 •  OR結合 •  インデックス化項目に対する2つ以上の条件がOR結合されている •  例: WHERE Field1__c = ‘Foo’ OR Field2__c = ‘Baa’ •  全ての条件項目に選択性が高いインデックスが存在し、かつ、各条件を満たすレコード の「和」がしきい値以下なら、それら全てのインデックスが使用される •  全てが標準インデックスなら、標準インデックスのしきい値 •  1つでもカスタムインデックスが含まれるなら、カスタムインデックスのしきい値 •  AND結合も含まれるような複雑なクエリーの場合、Salesforceテクニカルサポートを 通じてインデックスの有効性を確認する必要がある 12
  13. 13. インデックスに関するその他の注意事項 •  インデックスが増えるにつれ、レコードの更新性能は劣化する •  カスタムインデックスの作成は必要最小限にとどめる •  本番組織で定義したカスタムインデックスは、サンドボックス にもコピーされる •  ただし、インデックス作成時点で既に存在するサンドボックスについて はリフレッシュが必要 •  リフレッシュしない場合や、サンドボックス→本番、サンドボックス→ サンドボックスの場合、組織別にカスタムインデックスの作成をリクエ ストする •  スキニーテーブルを使用している場合 •  ベースオブジェクトのインデックスをスキニーテーブルにもコピーする かどうかは、スキニーテーブル作成依頼時にサポートへリクエスト •  スキニーテーブル作成後に、ベースオブジェクトにカスタムインデックスを 追加作成する場合も同様 13
  14. 14. 参考資料 •  大量のデータを使用するリリースのベストプラクティス •  http://wiki.developerforce.com/page/JP:Documentation •  Maximizing the Performance of Force.com SOQL, Reports, and List Views •  http://blogs.developerforce.com/engineering/2013/07/ maximizing-the-performance-of-force-com-soql-reports-andlist-views.html •  Force.com SOQL Best Practices: Nulls and Formula Fields •  http://blogs.developerforce.com/engineering/2013/02/forcecom-soql-best-practices-nulls-and-formula-fields.html •  Webinar: Inside the Force.com Query Optimizer •  http://wiki.developerforce.com/page/ Webinar:_Inside_the_Force.com_Query_Optimizer_(2013-Apr) 14
  15. 15. スキニーテーブル
  16. 16. スキニーテーブルとは (1/3) •  特定オブジェクトの一部の項目のみでコンパクトに 構成されたデータベーステーブル •  一部の標準オブジェクト(取引先、取引先責任者、商談、リー ド、ケース)と、カスタムオブジェクトに対して作成可能 •  ベーステーブルの一部の項目と全てのレコードを持つ •  ベーステーブルとスキニーテーブルのデータは常に同期される •  ベーステーブルにある論理削除レコード(「ごみ箱」内のレコー ド)は含まれない •  主に大量のレコードを含むオブジェクトに対するク エリー(レポート、リストビュー、SOQL)の性能を向 上させるために利用される 16
  17. 17. スキニーテーブルとは (2/3) •  クエリー実行時にスキニーテーブルにアクセスするかどう かは、Salesforceのクエリーオプティマイザーが決定する •  スキニーテーブルを機能させるには、少なくとも、クエリーが 参照する全ての項目がスキニーテーブルに含まれる必要がある •  対象オブジェクトの持つ項目のうち、100項目までをスキ ニーテーブルに含められる •  数式項目は不可 •  ただしクエリーに含まれる数式項目が参照する項目が、全てスキニ ーテーブルに含まれれば、スキニーテーブルを使用することは可能 •  他オブジェクトの項目も不可 •  主従関係項目、参照関係項目を含めることは可能 •  この場合、参照先オブジェクトにもスキニーテーブルが存在すれば 、スキニーテーブル同士のジョインとなる可能性もある •  項目数は少ないほうが性能が得られやすい 17
  18. 18. スキニーテーブルとは (3/3) •  インデックス •  ベーステーブルのインデックスをスキニーテーブルにもコピ ーするかどうかは、スキニーテーブル作成依頼時にサポート へ依頼 •  スキニーテーブル作成後に、ベースオブジェクトにカスタムイ ンデックスを追加作成する場合も同様 •  通常のSalesforceユーザーからは一切見えない •  Salesforceテクニカルサポートが依頼を受けて設定 •  有効性が認められる場合のみ作成される •  通常ユーザーはスキニーテーブルの定義も存在自体も確認す ることはできない •  ソーステーブルとのデータ同期も自動的に行われる 18
  19. 19. クエリー性能が悪化する理由 •  ベーステーブルの内部データ構造 •  標準オブジェクト •  •  カスタムオブジェクト •  •  オブジェクト毎に標準項目用とカスタム項目用の2つのテーブル(組織IDでハッシュパーティショニング)が あり、全てのユーザー組織のデータは同じテーブルに保持される 全てのユーザー組織の全てのカスタム オブジェクトのデータは、組織IDで ハッシュパーティショニングされた 単一のテーブルに保持される 性能向上を妨げる要素 •  •  標準オブジェクトの場合、標準項目とカスタム項目の両方を参照するクエリーでは、SQLレベ ルでテーブルジョインが発生する カスタム項目が多いとレコード長が長くなりストレージ効率が悪くなる •  •  •  大量レコードに効率アクセスには工夫が必要 •  •  •  1回のブロックリードで取得できるレコード数が少ない、さらには1レコード取得するのに複数回のブロッ クリードが必要となる場合もある アクセスの少ない項目がキャッシュされるため、キャッシュヒット率が低くなる オブジェクトのレコードへは必ずインデックスアクセス(組織IDとオブジェクトID)が必要(注1) 膨大なアクセスレコード数のためフルスキャンは非現実的 論理削除レコードも含まれる 注1 : 全てのテーブルへの直接アクセスはいかなる場合も不可となっており、セキュリティが担保されたインタフェースを介してのみ アクセスが許可され、組織毎のデータの安全性が確保されている 19
  20. 20. スキニーテーブルでクエリー性能が向上する理由 •  スキニーテーブルのデータ構造 •  •  •  1つのスキニーテーブルには、特定組織の特定オブジェクトのデータのみが保持される 標準項目とカスタム項目の区別はなく、スキニーテーブル作成時に指定された項目に対応する 列のみで構成される 性能が向上する理由 •  テーブルジョインが減る •  •  標準オブジェクトの標準項目とカスタム項目の両方にジョインなしでアクセス可 ストレージ効率が良い •  レコードがコンパクトなので、1ブロックに含まれるレコード数が多くなる •  •  •  インデックスもコンパクト •  •  •  •  •  1回のブロックリードでより多くのレコードを取得できる 同量の消費メモリで、より多くのレコードをキャッシュできる テーブルは特定オブジェクトのデータしか保持しないので総レコード数が少ない 組織IDとオブジェクトIDを含まないのでキーが短く、ブロック当たりキー数が増える その結果Bツリーインデックスの高さが低く抑えられ、インデックスアクセス時のI/Oが減る 論理削除レコードを含まない テーブルフルスキャンができる •  •  自社組織以外のレコードが含まれないので、クエリーでインデックスが利用できない場合には、フルスキ ャンが効率的になる フルスキャンはシーケンシャルリードなので、大量データの読み取りに向いている 20
  21. 21. スキニーテーブルの注意事項 •  新規作成したカスタム項目をスキニーテーブルにも追加す るには、Salesforceサポートに再作成を依頼する必要があ る •  スキニーテーブル項目の定義を変更すると、スキニーテー ブルが無効化されるので、Salesforceサポートに再作成 を依頼する必要がある •  サンドボックスにはコピーされない •  必要に応じてSalesforceサポートに別途リクエストする 21
  22. 22. 参考資料 •  大量のデータを使用するリリースのベストプラ クティス •  http://wiki.developerforce.com/page/JP:Documentation •  Long- and Short-Term Approaches for Tuning Force.com Performance •  http://blogs.developerforce.com/engineering/2013/03/longand-short-term-approaches-for-tuning-force-comperformance.html •  Force.com のマルチテナントアーキテクチャ •  http://wiki.developerforce.com/page/ JP_Multi_Tenant_Architecture •  Webinar: Inside the Force.com Query Optimizer •  http://wiki.developerforce.com/page/ Webinar:_Inside_the_Force.com_Query_Optimizer_(2013-Apr) 22
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×