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.

SQLアンチパターンNight

1,824 views

Published on

SQLアンチパターンNightでの発表資料

Published in: Engineering
  • Be the first to comment

SQLアンチパターンNight

  1. 1. SQLアンチパターン Night VOYAGE GROUP 三浦 裕典@hironomiu
  2. 2. About Me VOYAGE GROUP システム本部 ERDG所属 2009年DBAとして入社(7年目) Oracle、MySQL、Netteza(PureData)、AmazonRDS 全社、横断的なDBA 現在は技術者育成責任者として従事 内定者、若手エンジニアの育成(内定者育成支援、SQLアンチパターン読書会、etc) エンジニアインターンの取り纏め(Treasure、Sunrise) 前職はSI業界で物流販売系のDBAをしていました(田町系) 前々職は5X億円ドブに捨てたと噂のある某PJの前身PJでDBAなどを。。。
  3. 3. MyJob 内定者育成
  4. 4. MyJob 2014 Treasure
  5. 5. blog、twitterで発信しています 詳しくは 検索キーワード 「VOYAGE GROUP blog」旧ブログ 「VOYAGE GROUP blog はてな」新ブログ Twitter@tech_voyageでも情報発信しています 。
  6. 6. SQLアンチパターンNight のきっかけ 「SQLアンチパターン」 良書ですよね! (持ってない人は買いましょう!オススメです) (販促)
  7. 7. SQLアンチパターンNight のきっかけ 新卒1年目向けに2012年からRDBMSの理解のために「現場で使えるMySQL」を用いて実施 発売日から1年遅れですが、そうした若手向けの応用編としてSQLアンチパターンで 2014年1月末から新卒1年目、2年目を中心に第1期社内読書会開始(週1回1時間) 11週間で25章+付録まで読了 第2期を2014年3月末から始める [旧ブログエントリー](http://tech.voyagegroup.com/archives/7759653.html) 2015年1月末から1年目エンジニアを中心に第3期を開始 2015/04/09に25章+付録まで読了 正直な話をすると当初は1年目、2年目には重たすぎる本かなと思ってました。(無事すべて完走)
  8. 8. SQL アンチパターン読書会風景 2015/01/22 ~04/09 11Week SQLアンチパターン メンター用資料(書籍と一緒に読んでみてください) http://www.slideshare.net/hironorimiura/sql-34880588
  9. 9. SQLアンチパターンNight のきっかけ 何が良いか? RDBMSをアプリケーションから何となく使えてきた層に対して RDBMSについて先人の知恵、経験や筋の良さが学び取れる書籍(腹落ち出来る書籍) 現在の技術利用の環境やコンテキストに照らした上で筋の善し悪しについて議論の出来るテーマが多々ある 技術利用の環境 基幹システム、Webサービス、オンプレミス、クラウド コンテキスト FirstRow、AllRows、レスポンスタイム、スループット 行指向、列指向 MySQL、Oracle、Hive、BigQuery
  10. 10. SQLアンチパターンNight のきっかけ 何がよいか?(読書会を通じて) 読書会と言う活動を通じて改めて思うこと 何度も読む事でより気付きが得られる 自分はメンターとして3回読了していますが未だに新 しく気付くことが多々あります。 一人で読むより輪読向き 良書ですね!
  11. 11. SQLアンチパターンNight のきっかけ もしかすると 自分だけでなく良書だと思ってる人が 沢山いるのでは! t_wadaさん誘ってイベントを開こう!
  12. 12. 今日のお話 「SQLアンチパターン」中からVOYAGE GROUPではちょっと捻った適用事例があり今 回はそのお話をさせて頂きたいと思います。( 特定のRDBMSプロダクトにフォーカス当てす ぎないよう、少しボカシています。)
  13. 13. 8章メタデータトリブルから Sharding,Partitioning適用事例 SQLアンチパターン 8章メタデータトリブル から
  14. 14. 8章メタデータトリブルから Sharding,Partitioning適用事例 8章メタデータトリブル概要 イントロでは年ごとの営業収益のカラムの追加を例にカラム名に データを追加する、年が進む事にカラムが増殖し続けるメタデー タのトリブルについて言及しています。ここからカラムに留まら ずテーブルについてもトリブルするアンチパターンについて話は 進みます。 (詳細は書籍を!)
  15. 15. 8章メタデータトリブルから Sharding,Partitioning適用事例 ここから解決策で水平パーティショニングなど の分散方式が登場します。VOYAGE GROUPで も適用する場面は多々あります。そこでボトル ネック解消事案の1つで水平パーティショニン グの技法でSharding、Partitioningを用いて対応 した事例をご紹介したいと思います。
  16. 16. 8章メタデータトリブルから Sharding,Partitioning適用事例 最初に言葉の定義 Sharding 元テーブルを同じ構造で一定のルールで物理的にテーブルを分ける ハッシュ、レンジ、etc 物理的に異なるノードに同じ構造で一定のルールで配置(上とはANDの関係ではない) 横断的なデータ参照以外はノード内で完結した処理が行える Paritioning SQLアンチパターン本文中のシャーディングを指す 一般的なRDBMSで提供されているパーティショニング機能 RDBMSによってはテーブル、インデックス、パーティション方式もハッシュ、レンジ、グローバル、ロ ーカル、etc
  17. 17. 8章メタデータトリブルから Sharding,Partitioning適用事例 適用事例前の状況(その1) DBサーバ全体の負荷高騰(主にロードアベレージ)、応答性能の劣化が常態化 特に挿入処理の遅延(オンライン、バッチ共に)が目立った プロファイリング(WAITイベント監視、各種Stats情報の収集、OS稼働情報) INDEXの特定PAGE(BLOCK)でWaitのイベントが多数(衝突しているよう) 集中しているように(特定のHot Point)見受けられた そのテーブル(群)はピーク時にはAPPから数百/秒〜数千/秒の挿入要求 但し捌ききれていない H/Wの限界か?(考察)買い替え?(意思決定)
  18. 18. 8章メタデータトリブルから Sharding,Partitioning適用事例 適用事例前の状況(その2) HotPointのあったテーブル(群)の特徴 トランザクションテーブル 更新(UPDATE)無し、挿入(INSERT)のみの履歴テーブル 週で億単位のレコード ピーク時にはAPPから数百/秒〜数千/秒の挿入要求 シーケンス値をPK INDEX leafの終端(右端)が肥大化し続ける
  19. 19. 8章メタデータトリブルから Sharding,Partitioning適用事例 各種プロファイル、状況から考察(仮説) H/Wの限界の前にRDBMS内での性能限界に達している可能性が高 い H/Wの性能限界と現時点の処理量の乖離(主にI/O) RDBMS内のどこがボトルネックか? B+Tree INDEX上で何かボトルネックがあるのでは? INSERT時の特定PAGEへの集中(HotPoint)
  20. 20. 8章メタデータトリブルから Sharding,Partitioning適用事例 仮説 INSERTによる特定のHot Pointの顕在化(赤丸 )
  21. 21. 8章メタデータトリブルから Sharding,Partitioning適用事例 仮説に何故辿り着いたか ちょっとここで B+tree INDEXの特徴(を復習その1) RDBMSで最も使われている索引構造(最も一般的な探索手段) Cluster(MySQL Innodb PK) テーブルデータへのLook Upが不要 Non Cluster(色々、セカンダリ)テーブルを指し示すポインタを格納(格納効率良) ツリーで探索出来るもの(ソート可能)なら(数値、日付、文字列) 複数のカラムで構成可能(マルチカラム) カヴァリングインデックス戦略(レコード部へのlook up排除)
  22. 22. 8章メタデータトリブルから Sharding,Partitioning適用事例 B+tree INDEXの特徴(を復習その2) ブロックデバイスに最適化されている 二分木に比べ圧倒的に空間効率が良い 大量のKeyとレコードを指す値を格納
  23. 23. 8章メタデータトリブルから Sharding,Partitioning適用事例 B+tree INDEXの特徴(を復習その3) 探索の計算量は logFN * log2Fあたり N=100,000,000(1億レコード) F=100(100件格納)とした場合 logFN で4Page(Block)の読み込みでleafに到達する 4Pageをlog2Fの計算量で探索
  24. 24. 8章メタデータトリブルから Sharding,Partitioning適用事例
  25. 25. 8章メタデータトリブルから Sharding,Partitioning適用事例 B+tree INDEXの特徴(を復習その4) leafは挿入時にソート済みで格納される 横方向へ探索する場合(範囲検索、NonUnique検索) non leaf上のbranchに戻らずleafからleafに直進 余談ネクストルック 格納されるPAGE(もしくはBLOCK)が最大に達した場合 ソートされた状態でsplit(分裂)する コストの高い処理
  26. 26. 8章メタデータトリブルから Sharding,Partitioning適用事例 仮説 INSERTによる特定のHOT POINTの顕在化とは? 状況 ピーク時にはAPPから数百/秒〜数千/秒の挿入 B+tree INDEXの特徴(Hot PointはPK) 大量のKeyとレコードを指す値を格納 挿入時にソート済みで格納される 同一PAGE(BLOCK)に挿入する待ち行列が大量に発生
  27. 27. 8章メタデータトリブルから Sharding,Partitioning適用事例 赤丸のHOT POINTが問題なのでは!(各種Stats情報の裏付け) 状況とB+tree INDEXの特徴から
  28. 28. 8章メタデータトリブルから Sharding,Partitioning適用事例 赤丸のHot Pointを対策したい 具体的には 終端PAGE内の終端に対する複数の挿入の競合を解消したい 複数の挿入が競合する理由 B+treeの特徴 ソート済みで格納するため B+treeの仕様として避けれない
  29. 29. 8章メタデータトリブルから Sharding,Partitioning適用事例 対策方法 メタデータへのデータが混入したテーブルの作成 メタデータトリブルだが考え方は 水平パーティショニング Sharding Partitioning
  30. 30. 8章メタデータトリブルから Sharding,Partitioning適用事例 Sharding 同一ノードで黄色で囲った単位でテーブル分割 (例 logs_1_1000,logs_1001_2000,logs_2001_3000)
  31. 31. 8章メタデータトリブルから Sharding,Partitioning適用事例 「メタデータにデータの混入した※」テーブル分割によっ て 理論上3倍の挿入性能の向上(H/Wの性能上限に達する まで) どのテーブルに挿入するかについて責務がアプリケーシ ョンに渡るトレードオフ(+オーバーヘッドは発生) ※ここからはShardと呼びます
  32. 32. 8章メタデータトリブルから Sharding,Partitioning適用事例 更に挿入性能の向上を (水平パーティショニングの水平 パーティショニング)
  33. 33. 8章メタデータトリブルから Sharding,Partitioning適用事例 INDEXそのものをPartition分割(上絵は2分割)
  34. 34. 8章メタデータトリブルから Sharding,Partitioning適用事例 INDEX Partitioningによって 3つのShard、2つのPartitionで理論上6倍の挿入 性能の向上(H/Wの性能上限に達するまで) Shardingとは違った平準化が出来る場合もある 主にHash
  35. 35. 8章メタデータトリブルから Sharding,Partitioning適用事例 今回の適用事例から Shardingと言う考え方ですと最初からShard毎のノードを作成した構成をイメージしや すいですが同一ノード上でRDBMSレイヤのボトルネックを解消する際にもトレードオ フを考慮しつつ適用可能な場面はあると思います (余談ですが最初からPartitionを使えばと言う意見もあるかと思いますが有償オプシ ョンの製品を使用していたので。) ShardingとPartitioningは共存可能 トレードオフ(挿入性能を向上するのが目的でその他で犠牲はある) アプリケーションにテーブル特定の責務などが生じる(非透過的) 横断的なデータ取得に工夫が必要になる
  36. 36. 8章メタデータトリブルから Sharding,Partitioning適用事例 今回の適用事例から(続き) 同一ノード上の場合、メタデータトリブルである 「メタデータ」に「データ」の混入が発生してし まいますが、アンチパターンを用いても良い例か な?(悪手ではないかな?)と思ってます 今回のようにH/Wの性能限界に近づけるケース があります
  37. 37. 8章メタデータトリブルから Sharding,Partitioning適用事例 今回の適用事例から(続き) 余談ですがここからが様々なスケールアップ&アウトの スタートライン スケールアップ時にはメタデータにデータの混入が「 テーブル」からノードに移り「ノード」、「DB」又は 「スキーマ」のメタデータにデータの混入が移行 レイヤが変わるだけ
  38. 38. 8章メタデータトリブルから Sharding,Partitioning適用事例 メタデータトリブルは続くよどこまでも♩
  39. 39. 8章メタデータトリブルから Sharding,Partitioning適用事例 実はこの適用事例、三浦が入社した2009年当時のものだったりし ます 昔から大量データ、大量なトラフィックに挑戦している会社です 実際には10個のShard、4個のINDEX Partition(Hash)で40倍まで 挿入の性能向上を臨んでみました 40倍までは向上しませんでしたが飛躍的に向上しました 挿入性能を向上させる変わりに検索性能にオーバーヘッドが発 生するトレードオフは織り込んでいます
  40. 40. 8章メタデータトリブルから Sharding,Partitioning適用事例 SQLアンチパターン 8章メタデータトリブルから Sharding、Partitioningを用いた 挿入時のINDEXボトルネック解消のお話でした!
  41. 41. SQLアンチパターンNight ちょっとだけ小話(2、3分。。) (他にも色々SQLアンチパターンライクなネタを 考えてきたんですが。。)
  42. 42. DB設計今昔 計算、計算、計算 DBを設計する過程でこんな計算した経験ありませんか? int(4byte) + datetme(8byte) …. → レコードSizeの算出 (PageSize(Block) − ヘッダ部 − PCTFREE) / レコードSize → 1Pageに収まるレコード数の算出 想定レコード数 / 1Pageに収まるレコード数 → 必要なPage数の算出 Page数 × PageSize(2 or 8 or 16kbyte…) → 想定テーブルSizeの算出
  43. 43. DB設計今昔 計算、計算、計算 すべてのテーブル、INDEX、ソート、UNDO、 REDO、etc それらを積み上げてDBの容量見積もりとして… 最近もこういうサイジングとかされてます?
  44. 44. DB設計今昔 謎の言霊「安全率」 Wikipediaより 安全率(あんぜんりつ)とは、あるシステムが破壊また は正常に作動しなくなる最小の負荷と、予測されるシス テムへの最大の負荷との比(前者/後者)のことである 。 。。難しい。でも気軽にDBのサイジングで出て来る単語
  45. 45. DB設計今昔 謎の言霊「安全率」 前述の計算式にて算出したレコードSizeについて 「それに安全率加味した?」 想定したレコート数について 「それに安全率加味した?」 算出したテーブルSizeについて 「それに安全率加味した?」 とにかく安全率
  46. 46. DB設計今昔 謎の言霊「安全率」 闇雲に安全率1.5(この数字も結構ありがち)倍 して、気付くと 1.5*1.5*1.5*….とんでもない数字に!
  47. 47. DB設計今昔 謎の言霊「安全率」 アンチパターン Safety・Factor・Shotgun(闇雲な安全率) 不安だからドンドン掛けちゃえ :-) 意味のない見積もりに(ドンブリ化)
  48. 48. SQLアンチパターンNight ご清聴ありがとうございました!

×