Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所 情報・通信システム社 白木晶子

1,096 views

Published on

インデックスを張ったから大丈夫なんです、のはずが…なんで性能が出ないの?!動きが何だか変わっちゃったんだけど?!よく相談される話です。国産DBMS開発者である子育て経験豊富なDBママが、インデックスの内部のからくりから、言うことをきかないワガママなインデックスのしつけ方を伝授します。

Published in: Technology
  • Be the first to comment

[db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所 情報・通信システム社 白木晶子

  1. 1. © Hitachi, Ltd. 2015. All rights reserved. 株式会社 日立製作所 情報・通信システム社 ITプラットフォーム事業本部 DB部 2015/09/10 白木 晶子 DBママが教える インデックスのしつけかた
  2. 2. © Hitachi, Ltd. 2015. All rights reserved. 1. こんな経験ありませんか? 2. インデックスの正体 3. インデックスのしつけかた Contents 1 4. まとめ
  3. 3. © Hitachi, Ltd. 2015. All rights reserved. 1. こんな経験ありませんか? 2
  4. 4. © Hitachi, Ltd. 2015. All rights reserved. インデックスを張ったから大丈夫、 のはずが… 1-1 こんな経験ありませんか? 3 なんで性能が出ないの?! 動きがなんだか変わったんだけど?! 設計した通りに言うことを 聞いてくれなくて困るんだよ!
  5. 5. © Hitachi, Ltd. 2015. All rights reserved. 1-2 どうして困ったの? 4 インデックスの正体、 構造に触れながら、 困った原因をしつけていきます 表名列1 列2 データ1 1 データ2 2 データ3 3
  6. 6. © Hitachi, Ltd. 2015. All rights reserved. 2. インデックスの正体 5
  7. 7. © Hitachi, Ltd. 2015. All rights reserved. 2-1 インデックスはRDBに必須? 6 父 母 第1子 第2子 第3子 会社員 会社員 小学生 小学生 小学生 父 母 第1子 第2子 第3子 茶髪 黒髪 赤髪 栗金髪 栗金髪 T_MEMBER T_FEATURE RDBはテーブル(リレーション)を扱うシステムのこと 数行程度のテーブルを扱うだけなら、 インデックスは必須ではない
  8. 8. © Hitachi, Ltd. 2015. All rights reserved. 2-2 インデックスはRDBに必須? 7 昨今のシステムでは テーブルの格納行数は数百万行~数億行超も T_MEMBER T_FEATURE 数百万行 数億行 ~ インデックスは必須ではない RDBに必要なオブジェクト
  9. 9. © Hitachi, Ltd. 2015. All rights reserved. 2-3 主キーとインデックスの違いは? 8 T_MEMBERCREATE TABLE T_MEMBER( ID_NO CHAR(10), NAME VARCHAR(50), JOB VARCHAR(100), … PRIMARY KEY(ID_NO) …) … NAMEID_NO テーブルの行を一意に特定できるように、 テーブル自体に付けられる制約のこと 実体は ユニークインデックスで実装 (ただし、一意制約のため、NULLを許さない)
  10. 10. © Hitachi, Ltd. 2015. All rights reserved. 2-4 インデックスのおさらい① 9 高速に処理できる メリット 表のデータに応じて容量が増える 更新速度が遅くなる デメリット
  11. 11. © Hitachi, Ltd. 2015. All rights reserved. ベーシックなB 木インデックス すべてのリーフノードの深さが同じになるようにメンテナンス 2-5 インデックスのおさらい② 10 ユニークインデックス(プライマリ、セカンダリ) 非ユニークインデックス 単一列からなるインデックス 複数列からなるインデックス +
  12. 12. © Hitachi, Ltd. 2015. All rights reserved. 2-6 インデックスの構造① 11 キー値:ROWID ルートノード(R) ブランチ ノード(B) リーフノード(L) ルートノード ブランチ内の最大キー値 ブランチへのポインタ ブランチノード リーフ内の最大キー値 リーフへのポインタ リーフノード キー値 ROWID(表データへのポインタ) 表名列1 列2 データ1 1 データ2 2 データ3 3
  13. 13. © Hitachi, Ltd. 2015. All rights reserved. インデックスを用いて キー値を絞りこんだ場合① 2-7 インデックスの構造② 12 (L) (B) (R) キー値:ROWID 表名列1 列2 データ1 1 データ2 2 データ3 3 SELECT NAME, AGE FROM T_MEMBER WHERE AGE=5
  14. 14. © Hitachi, Ltd. 2015. All rights reserved. インデックスを用いて キー値を絞りこんだ場合② 2-8 インデックスの構造③ 13 (R) (B) (L) キー値:ROWID キー値:ROWID 範囲となる述語には LIKE述語(前方一致)、比較述語(<)など 表名列1 列2 データ1 1 データ2 2 データ3 3 SELECT NAME, AGE FROM T_MEMBER WHERE AGE BETWEEN 5 AND 10
  15. 15. © Hitachi, Ltd. 2015. All rights reserved. インデックスを用いて表のデータを参照する場合 2-9 インデックスの構造④ 14 AGE=4 (L) R#100 R#500 R#200 AGE=5 R#400 R#10 R#300 R#50 #10 #50 : : #300 #400 : : R#410 #410 AGE=6 T_MEMBER表 AGE=3 R#230 R#240 R#70 SELECT NAME, AGE FROM T_MEMBER WHERE AGE=5 表にはランダムにアクセス ポイント
  16. 16. © Hitachi, Ltd. 2015. All rights reserved. 3. インデックスのしつけかた 15
  17. 17. © Hitachi, Ltd. 2015. All rights reserved. 2つの理想のインデックスについて 実例を交えながらしつけていきましょう 3-1 目指すインデックス像は?① 16 目指すインデックス像 スリムでも骨太なインデックス 俊敏なインデックス しつけ方針 ダメなところは直す 良いところを引き出す
  18. 18. © Hitachi, Ltd. 2015. All rights reserved. データ更新するとブクブク太りがちなリーフノード 中身がスカスカでも、新規ノードを割り当てることも キー値とROWIDがぎっしり詰まったインデックスが理想 3-2 目指すインデックス像は?② 17 AGE=29 (L) R#100 R#200 AGE=30 R#400 R#10 R#300 R#50 R#410 AGE=31 削除された部分 AGE=32 AGE=33 AGE=34 R#150 R#90 R#500 追加された部分 R#320 R#60 R#440 R#250 R#280 R#30 AGE=35 R#20R#500 R#650 目指すインデックス像 スリムでも骨太なインデックス
  19. 19. © Hitachi, Ltd. 2015. All rights reserved. 多重度が上がっても、どんなキー値の検索がやってきても、 検索性能が良いインデックスが理想 3-3 目指すインデックス像は?③ 18 キー値:ROWID キー値:ROWID (R) (B) (L) キー値:ROWID キー値:ROWID キー値:ROWID 目指すインデックス像 俊敏なインデックス
  20. 20. © Hitachi, Ltd. 2015. All rights reserved. No.1501070025 3-4 しつけ1:スリムなインデックス(学籍番号①) 19 15 01 07 0025 入学年度 学部 学科 シーケンス(SEQ) 特徴 ①入学時に増える ②キー値の変更はない ③ほとんど増えない(たまに編入あり) 学籍番号は 複数の意味のある値から成り立ち、全体で一意を表す
  21. 21. © Hitachi, Ltd. 2015. All rights reserved. 3-5 しつけ1:スリムなインデックス(学籍番号②) 20 1501010001 (L) R#001 1501010002 R#002 1501010003 : : : : R#003 : : 1501010100 R#100 ・・・ : : : : : : 空き領域 ※空き領域とは、 キー値更新時のノード移動抑止 ROWID追加で新規割当て抑止 を目的に設計する領域 学籍番号に張るべきはプライマリキー ポイント キー値とROWIDの長さからエントリ数を見積もり、 空き領域(※)の比率を小さくして肥満防止! 編入者のキー値分+α のノード数を確保
  22. 22. © Hitachi, Ltd. 2015. All rights reserved. No.0000003501 3-6 しつけ2:スリムなインデックス(ファンクラブ会員①) 21 3501 左0 SEQ1 000000 特徴 ①随時増加、減少を繰り返す ②常に最大キー値が増える ③キー値の変更はない ファンクラブの会員No.は 一つのシーケンスで一意を表す
  23. 23. © Hitachi, Ltd. 2015. All rights reserved. 3-7 しつけ2:スリムなインデックス(ファンクラブ会員②) 22 3501 (L) R#001 3502 R#002 R#100 ・・・ : : :3503 R#003 : : : : : : : : : 3600 新規会員が増えるのみ、 キー値更新はないので、 空き領域はなくてよい ノード数も増加数を見越して 見積もり、その後は自動増分 ファンクラブの会員No.に張るべきはプライマリキー ポイント キー値とROWIDの長さからエントリ数を見積もり、 空き領域の比率を0にして肥満防止! キー値を数値にしてキー長を短くし、さらにスリムに!
  24. 24. © Hitachi, Ltd. 2015. All rights reserved. No.0201070025 3-8 しつけ3:スリムなインデックス(ショップ会員①) 23 02 01 07 0025 ブランドNo. ショップNo. SEQ1 SEQ2 特徴 ①随時増加、減少を繰り返す ②シーケンスが複数あり、ランダムなキー値が増える ③キー値の変更はない ショップの会員No.は 複数のシーケンスを組み合わせ、全体で一意を表す
  25. 25. © Hitachi, Ltd. 2015. All rights reserved. シーケンスごとにばらせば、中は単調増加で単純になる 3-9 しつけ3:スリムなインデックス(ショップ会員②) 24 0201070025 (L) R#011 0201070026 R#032 0201070027 : : : R#003 : : R#100 ・・・ : : : : : : 0201080001 (L) R#052 0201080002 R#102 0201080003 : : : 0201080100 R#020 ・・・ : : : : : : 0201070100: R#103 : : : ショップの会員No.に張るべきはプライマリキー ポイント 複数の列からなるプライマリキーを定義し、 シーケンスの値でパーティショニングして肥満防止!
  26. 26. © Hitachi, Ltd. 2015. All rights reserved. 3-10 しつけ4:骨太なインデックス(ショップ会員③) 25 0201070025 (L) R#011 0201070026 R#032 0201070027 0201070028 0201070029 0201070030 R#157 R#003 R#024 R#224 0201070100 R#100 ・・・ : : : : : : 0201070025 (L) R#011 0201070027 R#003 0201070100 : : : : 再編成 R#100 特徴 ①随時増加、減少を繰り返す ②一度消えたキー値の復活はない ポイント インデックスの再編成でスカスカ防止! 空きエントリを再利用してスカスカ防止!
  27. 27. © Hitachi, Ltd. 2015. All rights reserved. 01072015061213300025060073 3-11 しつけ5:俊敏なインデックス(時系列データ①) 26 2015/06/12 13:30.002501 07 0073 取引種別 コード 時刻印 SEQ1 特徴 ①常に最大キー値となるデータを追加する ⇒最終ノードにアクセスが集中する ②短時間に大量にデータが増加する ⇒最終ノードが満杯になるとノードを拡張する 時系列データは 時刻印などを含み複数のデータで一意を表す
  28. 28. © Hitachi, Ltd. 2015. All rights reserved. 3-12 しつけ6:俊敏なインデックス(時系列データ②) 27 01072015061213300025060073 (L) R#011 01072015061213304042000025 R#032 01072015061213301025060073 R#050 (L) 02042015061213300025060074 R#012 02042015061213304042000025 R#031 02042015061213301025060075 R#052 : : : : : : : : 時系列データに張るべきはセカンダリインデックス ポイント パーティショニングして負荷分散し肥満防止! シーケンスを用いてユニーク担保し、 ユニークチェックをしないことで高速化! 時刻印とは別の列で パーティショニング
  29. 29. © Hitachi, Ltd. 2015. All rights reserved. 3-13 しつけ7:俊敏なインデックス(時系列データ③) 28 (L) 2015/ 06/08 ~ 2015/ 06/14 2015/ 06/15 ~ 2015/ 06/21 2015/ 06/22 ~ 2015/ 06/28 2015/ 06/22 ~ 2015/ 06/28 特徴 ①新しいデータのみ使用、古いデータは使用しない ②パーティショニングしてもメンテが大変 ポイント 複数の分割を組み合わせて高速化! 時刻印はレンジ分割、 その他は ハッシュ分割すると 均等に
  30. 30. © Hitachi, Ltd. 2015. All rights reserved. 3-14 しつけ8:俊敏なインデックス(ステータス①) 29 01 受付 02 処理A受付 03 処理中 ワークフロー系業務 … 特徴 ①キー値の種類が少ない ②カーディナリティが低い ③キー値の変更が頻繁に発生する ステータスは、 業務の進行状況などのステータスを表す ポイント インデックスを定義しない潔さも必要
  31. 31. © Hitachi, Ltd. 2015. All rights reserved. 3-15 しつけ9:俊敏なインデックス(ステータス②) 30 (L) NULL:ROWID キー値:ROWID 頻繁に更新 キー値:ROWID ステータスに張るべきは、 ほかの列と一緒にセカンダリインデックス ポイント 初期値にNULLを入れない!直接値を入れる ⇒更新量を抑える、NULLのノードの負荷を下げる 再編成を行いスカスカ防止! 更新後は利用されず 無駄な領域が増大
  32. 32. © Hitachi, Ltd. 2015. All rights reserved. 3-16 しつけ10:俊敏なインデックス(ステータス③) 31 20150612 01075 20150612 02076 20150612 01077 20150612 01078 20150612 03079 (L) ポイント 頻繁にステータスを取得するなら、 ほかの射影列と複数列で一つのインデックス を定義し高速化! ステータスを 最後にすると、 キー値の移動が 少ない
  33. 33. © Hitachi, Ltd. 2015. All rights reserved. 3-17 しつけ11:俊敏なインデックス(オプティマイザ①) 32 (R) (B) (L) NULL:ROWID MAX値:ROWIDMIN値:ROWID ポイント MIN/MAX、COUNTは インデックスの管理情報を活用して高速化! インデックスの 管理情報を有効 活用するSQL
  34. 34. © Hitachi, Ltd. 2015. All rights reserved. 3-18 しつけ12:俊敏なインデックス(オプティマイザ②) 33 AGE列のインデックス 20 30 R#002 R#005 R#011 R#018 NAME列のインデックス SATO SATP R#018 R#015 R#013 R#005 R#005 R#018 ポイント 既存のインデックスを複数組み合わせて高速化! 新規インデックスを定義すると更新速度が遅くなる SELECT * FROM T_MEMBER WHERE AGE BETWEEN 20 AND 29 AND NAME LIKE ‘SATO%’ 表名列1 列2
  35. 35. © Hitachi, Ltd. 2015. All rights reserved. 3-19 しつけ13:俊敏なインデックス(オプティマイザ③) 34 20 30 R#002 R#055 R#011 R#018 AGE列のインデックス T_MEMBER表(全?件) ポイント コスト情報(統計情報)を正しく活用して高速化! 表/インデックスの実体と、コスト情報の合致が大前提 行数、キー値の分布に応じて、インデックスのスキャン、 テーブルのスキャンを使い分ける 表名列1 列2 インデックスを引き、 ランダムアクセス するコストと テーブルを全部ス キャンするコストの バランスを利用
  36. 36. © Hitachi, Ltd. 2015. All rights reserved. 3-20 しつけ14:俊敏なインデックス(オプティマイザ④) 35 20150612 01075 20150612 02076 20150612 01077 20150612 01078 20150612 03079 (L) R#0025 R#0612 R#0003 R#1507 R#0864 ポイント 使用する列をすべて含むインデックスを定義し 高速化! インデックス数が多くなりすぎるなら、 正規化して高速化! 表名列1 列2 使用する列が全て 含むキー値なら、 表データを見ない
  37. 37. © Hitachi, Ltd. 2015. All rights reserved. 4. まとめ 36
  38. 38. © Hitachi, Ltd. 2015. All rights reserved. 4-1 まとめ① 37 スリムなインデックスのしつけ方 ①エントリ数の見積もり、ノード数の確保 ②空き領域比率の見積もり ③パーティショニング 骨太なインデックスのしつけ方 ①再編成 ②空きエントリの再利用
  39. 39. © Hitachi, Ltd. 2015. All rights reserved. 4-2 まとめ② 38 俊敏なインデックスのしつけ方 ①パーティショニング ②初期値にNULLを指定しない ③インデックスの管理情報の活用 ④コスト情報(統計情報)の活用 ⑤複数列からなるインデックス ⑥正規化
  40. 40. © Hitachi, Ltd. 2015. All rights reserved. 4-3 まとめ③ 39 どんなインデックスにするか どうやって育てるか 悩んで 手塩にかけて育てたインデックス 最高のパフォーマンスで 親孝行をしてくれることを期待して
  41. 41. © Hitachi, Ltd. 2015. All rights reserved. 株式会社 日立製作所 情報・通信システム社 ITプラットフォーム事業本部 DB部 DBママが教える インデックスのしつけ方 2015/09/10 白木 晶子 END 40
  42. 42. © Hitachi, Ltd. 2015. All rights reserved. 他社固有名称等に対する表示 41 ・本資料に記載の製品の内容・仕様は、 改良のために予告なく変更する場合があります。 ・本資料に記載の会社名、製品名は、 それぞれの会社の商標もしくは登録商標です。

×