SQLアンチパターンNight

SQLアンチパターン
Night
VOYAGE GROUP
三浦裕典@hironomiu

About Me
VOYAGE GROUP システム本部 ERDG所属
2009年DBAとして入社（7年目）
Oracle、MySQL、Netteza(PureData)、AmazonRDS
全社、横断的なDBA
現在は技術者育成責任者として従事
内定者、若手エンジニアの育成（内定者育成支援、SQLアンチパターン読書会、etc）
エンジニアインターンの取り纏め（Treasure、Sunrise）
前職はSI業界で物流販売系のDBAをしていました（田町系）
前々職は5X億円ドブに捨てたと噂のある某PJの前身PJでDBAなどを。。。

blog、twitterで発信しています
詳しくは
検索キーワード
「VOYAGE GROUP blog」旧ブログ
「VOYAGE GROUP blog はてな」新ブログ
Twitter@tech_voyageでも情報発信しています
。

SQLアンチパターンNight
のきっかけ
「SQLアンチパターン」
良書ですよね！
（持ってない人は買いましょう！オススメです）
（販促）

のきっかけ
新卒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年目には重たすぎる本かなと思ってました。（無事すべて完走）

SQL アンチパターン読書会風景
2015/01/22 ~04/09 11Week
SQLアンチパターンメンター用資料（書籍と一緒に読んでみてください）
http://www.slideshare.net/hironorimiura/sql-34880588

のきっかけ
何が良いか？
RDBMSをアプリケーションから何となく使えてきた層に対して
RDBMSについて先人の知恵、経験や筋の良さが学び取れる書籍（腹落ち出来る書籍）
現在の技術利用の環境やコンテキストに照らした上で筋の善し悪しについて議論の出来るテーマが多々ある
技術利用の環境
基幹システム、Webサービス、オンプレミス、クラウド
コンテキスト
FirstRow、AllRows、レスポンスタイム、スループット
行指向、列指向
MySQL、Oracle、Hive、BigQuery

のきっかけ
何がよいか？（読書会を通じて）
読書会と言う活動を通じて改めて思うこと
何度も読む事でより気付きが得られる
自分はメンターとして3回読了していますが未だに新
しく気付くことが多々あります。
一人で読むより輪読向き
良書ですね！

のきっかけ
もしかすると
自分だけでなく良書だと思ってる人が
沢山いるのでは！
t_wadaさん誘ってイベントを開こう！

今日のお話
「SQLアンチパターン」中からVOYAGE
GROUPではちょっと捻った適用事例があり今
回はそのお話をさせて頂きたいと思います。（
特定のRDBMSプロダクトにフォーカス当てす
ぎないよう、少しボカシています。）

8章メタデータトリブルから
Sharding,Partitioning適用事例
8章メタデータトリブル
から

8章メタデータトリブル概要
イントロでは年ごとの営業収益のカラムの追加を例にカラム名に
データを追加する、年が進む事にカラムが増殖し続けるメタデー
タのトリブルについて言及しています。ここからカラムに留まら
ずテーブルについてもトリブルするアンチパターンについて話は
進みます。
（詳細は書籍を！）

ここから解決策で水平パーティショニングなど
の分散方式が登場します。VOYAGE GROUPで
も適用する場面は多々あります。そこでボトル
ネック解消事案の1つで水平パーティショニン
グの技法でSharding、Partitioningを用いて対応
した事例をご紹介したいと思います。

最初に言葉の定義
Sharding
元テーブルを同じ構造で一定のルールで物理的にテーブルを分ける
ハッシュ、レンジ、etc
物理的に異なるノードに同じ構造で一定のルールで配置(上とはANDの関係ではない）
横断的なデータ参照以外はノード内で完結した処理が行える
Paritioning
SQLアンチパターン本文中のシャーディングを指す
一般的なRDBMSで提供されているパーティショニング機能
RDBMSによってはテーブル、インデックス、パーティション方式もハッシュ、レンジ、グローバル、ロ
ーカル、etc

適用事例前の状況（その１）
DBサーバ全体の負荷高騰（主にロードアベレージ）、応答性能の劣化が常態化
特に挿入処理の遅延（オンライン、バッチ共に）が目立った
プロファイリング（WAITイベント監視、各種Stats情報の収集、OS稼働情報）
INDEXの特定PAGE(BLOCK)でWaitのイベントが多数（衝突しているよう）
集中しているように（特定のHot Point）見受けられた
そのテーブル（群）はピーク時にはAPPから数百/秒〜数千/秒の挿入要求
但し捌ききれていない
H/Wの限界か？（考察）買い替え？（意思決定）

適用事例前の状況（その２）
HotPointのあったテーブル（群）の特徴
トランザクションテーブル
更新(UPDATE)無し、挿入(INSERT)のみの履歴テーブル
週で億単位のレコード
ピーク時にはAPPから数百/秒〜数千/秒の挿入要求
シーケンス値をPK
INDEX leafの終端（右端）が肥大化し続ける

各種プロファイル、状況から考察（仮説）
H/Wの限界の前にRDBMS内での性能限界に達している可能性が高
い
H/Wの性能限界と現時点の処理量の乖離（主にI/O）
RDBMS内のどこがボトルネックか？
B+Tree INDEX上で何かボトルネックがあるのでは？
INSERT時の特定PAGEへの集中（HotPoint）

仮説 INSERTによる特定のHot Pointの顕在化（赤丸
）

仮説に何故辿り着いたか
ちょっとここで
B+tree INDEXの特徴（を復習その１）
RDBMSで最も使われている索引構造（最も一般的な探索手段）
Cluster(MySQL Innodb PK) テーブルデータへのLook Upが不要
Non Cluster(色々、セカンダリ）テーブルを指し示すポインタを格納（格納効率良）
ツリーで探索出来るもの（ソート可能）なら（数値、日付、文字列）
複数のカラムで構成可能（マルチカラム）
カヴァリングインデックス戦略（レコード部へのlook up排除）

B+tree INDEXの特徴（を復習その２）
ブロックデバイスに最適化されている
二分木に比べ圧倒的に空間効率が良い
大量のKeyとレコードを指す値を格納

B+tree INDEXの特徴（を復習その３）
探索の計算量は logFN * log2Fあたり
N=100,000,000(1億レコード）
F=100(100件格納）とした場合
logFN で4Page(Block)の読み込みでleafに到達する
4Pageをlog2Fの計算量で探索

B+tree INDEXの特徴（を復習その４）
leafは挿入時にソート済みで格納される
横方向へ探索する場合（範囲検索、NonUnique検索）
non leaf上のbranchに戻らずleafからleafに直進
余談ネクストルック
格納されるPAGE(もしくはBLOCK)が最大に達した場合
ソートされた状態でsplit（分裂）する
コストの高い処理

仮説 INSERTによる特定のHOT POINTの顕在化とは？
状況
ピーク時にはAPPから数百/秒〜数千/秒の挿入
B+tree INDEXの特徴（Hot PointはPK）
大量のKeyとレコードを指す値を格納
挿入時にソート済みで格納される
同一PAGE(BLOCK)に挿入する待ち行列が大量に発生

赤丸のHOT POINTが問題なのでは！（各種Stats情報の裏付け）
状況とB+tree INDEXの特徴から

赤丸のHot Pointを対策したい
具体的には
終端PAGE内の終端に対する複数の挿入の競合を解消したい
複数の挿入が競合する理由
B+treeの特徴ソート済みで格納するため
B+treeの仕様として避けれない

対策方法
メタデータへのデータが混入したテーブルの作成
メタデータトリブルだが考え方は
水平パーティショニング
Sharding
Partitioning

Sharding 同一ノードで黄色で囲った単位でテーブル分割
（例 logs_1_1000,logs_1001_2000,logs_2001_3000）

「メタデータにデータの混入した※」テーブル分割によっ
て
理論上3倍の挿入性能の向上（H/Wの性能上限に達する
まで）
どのテーブルに挿入するかについて責務がアプリケーシ
ョンに渡るトレードオフ（＋オーバーヘッドは発生）
※ここからはShardと呼びます

更に挿入性能の向上を
（水平パーティショニングの水平
パーティショニング）

INDEXそのものをPartition分割（上絵は2分割）

INDEX Partitioningによって
3つのShard、2つのPartitionで理論上6倍の挿入
性能の向上（H/Wの性能上限に達するまで）
Shardingとは違った平準化が出来る場合もある
主にHash

今回の適用事例から
Shardingと言う考え方ですと最初からShard毎のノードを作成した構成をイメージしや
すいですが同一ノード上でRDBMSレイヤのボトルネックを解消する際にもトレードオ
フを考慮しつつ適用可能な場面はあると思います
（余談ですが最初からPartitionを使えばと言う意見もあるかと思いますが有償オプシ
ョンの製品を使用していたので。）
ShardingとPartitioningは共存可能
トレードオフ（挿入性能を向上するのが目的でその他で犠牲はある）
アプリケーションにテーブル特定の責務などが生じる（非透過的）
横断的なデータ取得に工夫が必要になる

今回の適用事例から（続き）
同一ノード上の場合、メタデータトリブルである
「メタデータ」に「データ」の混入が発生してし
まいますが、アンチパターンを用いても良い例か
な？(悪手ではないかな？）と思ってます
今回のようにH/Wの性能限界に近づけるケース
があります

今回の適用事例から（続き）
余談ですがここからが様々なスケールアップ＆アウトの
スタートライン
スケールアップ時にはメタデータにデータの混入が「
テーブル」からノードに移り「ノード」、「DB」又は
「スキーマ」のメタデータにデータの混入が移行
レイヤが変わるだけ

メタデータトリブルは続くよどこまでも♩

実はこの適用事例、三浦が入社した2009年当時のものだったりし
ます
昔から大量データ、大量なトラフィックに挑戦している会社です
実際には10個のShard、4個のINDEX Partition(Hash)で40倍まで
挿入の性能向上を臨んでみました
40倍までは向上しませんでしたが飛躍的に向上しました
挿入性能を向上させる変わりに検索性能にオーバーヘッドが発
生するトレードオフは織り込んでいます

Sharding、Partitioningを用いた
挿入時のINDEXボトルネック解消のお話でした！

ちょっとだけ小話（2、3分。。）
（他にも色々SQLアンチパターンライクなネタを
考えてきたんですが。。）

DB設計今昔
計算、計算、計算
DBを設計する過程でこんな計算した経験ありませんか？
int(4byte) + datetme(8byte) ….
→ レコードSizeの算出
(PageSize(Block) − ヘッダ部 − PCTFREE) / レコードSize
→ 1Pageに収まるレコード数の算出
想定レコード数 / 1Pageに収まるレコード数
→ 必要なPage数の算出
Page数 × PageSize(2 or 8 or 16kbyte…)
→ 想定テーブルSizeの算出

DB設計今昔
計算、計算、計算
すべてのテーブル、INDEX、ソート、UNDO、
REDO、etc
それらを積み上げてDBの容量見積もりとして…
最近もこういうサイジングとかされてます？

DB設計今昔
謎の言霊「安全率」
Wikipediaより
安全率（あんぜんりつ）とは、あるシステムが破壊また
は正常に作動しなくなる最小の負荷と、予測されるシス
テムへの最大の負荷との比（前者/後者）のことである
。
。。難しい。でも気軽にDBのサイジングで出て来る単語

DB設計今昔
前述の計算式にて算出したレコードSizeについて
「それに安全率加味した？」
想定したレコート数について
算出したテーブルSizeについて
とにかく安全率

DB設計今昔
闇雲に安全率1.5（この数字も結構ありがち）倍
して、気付くと
1.5*1.5*1.5*….とんでもない数字に！

DB設計今昔
アンチパターン
Safety・Factor・Shotgun（闇雲な安全率）
不安だからドンドン掛けちゃえ :-)
意味のない見積もりに（ドンブリ化）

ご清聴ありがとうございました！

SQLアンチパターンNight

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (20)

Similar a SQLアンチパターンNight

Similar a SQLアンチパターンNight (20)

SQLアンチパターンNight