sqlアンチパターンnight ライトニングトーク
TRANSCRIPT
SQL アンチパターン Nightライトニングトーク
株式会社ヴァル研究所板橋正之2015/04/10
自己紹介■ 名前
板橋 正之（いたばし まさゆき）
■ 所属株式会社ヴァル研究所JAWS-UG 中央線
■ 仕事自社広告配信サーバの開発、運用
■ 好きな RDBMSOracle Database
itabashi.masayuki
今日は SQL アンチパターン Night ということで
失敗談を持ってきました。
今から 5 年ぐらい前の案件です。
13 時間程度で終了すると思った3,500 万件弱のデータ洗い替え作業が
5 日以上掛かった
失敗談
某システムの会員情報の ID 変更
案件
テーブルイメージ
単純に UPDATE 文の羅列で古い会員コードを
一旦テンポラリコードに編集してその後、新しい会員コードに振り直す。
やったこと
会員コードは主キーの一部でインデックスが設定されているので更新時にはインデックス書き換えの
オーバーヘッドを減らすためインデックスを解除した。
検討事項
更新が多くなる分、 UNDO 表領域、 REDO ログファイルを作成されることも予想されるため、ディスクを節約したかった。
検討事項
• テスト環境でサンプルのテーブルを使ってインデックスあり、なしの時間を計測して、処理時間を見積もりました。• テーブル A： 448,251件
• テーブル B： 561,018件
• アーカイブ REDOログによるディスク使用量もテーブル Aが1,062MB/556MB、テーブル Bが 1,821MB/607MBと計測しました。
• 上記の結果からインデックスなしの方が明らかに処理時間が短いことから、インデックスなしで処理を行なう方がよいと判断しました。
処理時間見積り
操作内容 時間 合計インデックスあ
りテンポラリ会員コード更新 0:06:48
0:18:37新会員コード更新 0:11:49
インデックスなし
インデックス無効 & テンポラリ会員コード更新
0:01:090:09:23
新会員コード更新 0:07:20
インデックス再作成 0:00:54
操作内容 時間 合計インデックスあ
りテンポラリ会員コード更新 0:09:24
0:33:28新会員コード更新 0:24:04
インデックスなし
インデックス無効 & テンポラリ会員コード更新
0:01:150:09:05
新会員コード更新 0:06:48
インデックス再作成 0:01:02
• 更新対象データが 34,971,205 件• 検証データが 448,251 件で 10 分弱• 34,971,205÷448,251×10 780≒ 分
＝ 13 時間
大間違い
サンプリングが少ない。
• 2 テーブル程度のデータで信頼性のある値がだせるのか？
• 見積もりを行なったテーブルは、比較的データ件数が近い。
データ件数と処理時間の相関関係を見出していない。
本番サーバの方が性能いい？
（当時でも）もう 5 年前のサーバだよ？
思い込みと楽観視
まず、テンポラリ会員コードへの更新
テーブル データ件数
更新(秒 )
更新(分 )
1万件当たりの秒数
会員マスタ 69,322 3.063 0.1 0.4419
会員所属マスタ 61,543 14.047 0.2 2.2825
受付テーブル 159,330 26.454 0.4 1.6603
予約テーブル 159,330 16.313 0.3 1.0239
ヘッダーテーブル 159,330 13.125 0.2 0.8238
コーステーブル 159,330 73.75 1.2 4.6288
明細テーブル A 8,564,614 609.703 10.2 0.7119
明細テーブル B 454,350 23.204 0.4 0.5107
明細テーブル C 17,845,016 1721.546 28.7 0.9647
明細テーブル D 2,668,722 179.672 3.0 0.6733
明細テーブル E 1,193,156 249.61 4.2 2.0920
明細パラメータテーブル 159,329 46.453 0.8 2.9155
明細付加情報テーブル 360,250 33.515 0.6 0.9303
印刷集計管理テーブル 335,480 68.75 1.1 2.0493
印刷履歴テーブル 1,545,991 599.188 10.0 3.8757
ワークフロー履歴テーブル 910,836 188.672 3.1 2.0714
ワークフロー制御テーブル 1,285,598 826.844 13.8 6.4315
洗い替え開始
SQL> SET TRANSACTION READ WRITE;SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘X’ || 会員コード ;SQL> COMMIT;
すでに更新秒数にバラツキがっ！
続いて新しい会員コードへの更新洗い替え開始
SQL> SET TRANSACTION READ WRITE;SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘2157’SQL> WHERE ( 会員コード = ‘X1356’);SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘3952’SQL> WHERE ( 会員コード = ‘X65165’);SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘4510’SQL> WHERE ( 会員コード = ‘X2157’);SQL> ・・・SQL> COMMIT;
続いて新しい会員コードへの更新洗い替え開始
SQL> SET TRANSACTION READ WRITE;SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘2157’SQL> WHERE ( 会員コード = ‘X1356’);SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘3952’SQL> WHERE ( 会員コード = ‘X65165’);SQL> UPDATE 会員マスタ SQL> SET 会員コード = ‘4510’SQL> WHERE ( 会員コード = ‘X2157’);SQL> ・・・SQL> COMMIT;
テーブル データ件数 更新 (分 ) 1万件当たりの秒数
会員マスタ 69,322 約 7 分 60.5868
会員所属マスタ 61,543 約 10 分 97.4928
受付テーブル 159,330 約 64 分 241.0092
予約テーブル 159,330 約 140 分 527.2077
ヘッダーテーブル 159,330 約 60 分 225.9461
コーステーブル 159,330 約 65 分 244.7750
明細テーブル A 8,564,614
明細テーブル B 454,350
明細テーブル C 17,845,016
明細テーブル D 2,668,722
明細テーブル E 1,193,156
明細パラメータテーブル 159,329 約 96 分 361.5161
明細付加情報テーブル 360,250 約 900分 1498.9590
印刷集計管理テーブル 335,480 約 70 分 125.1938
印刷履歴テーブル 1,545,991
ワークフロー履歴テーブル 910,836
ワークフロー制御テーブル 1,285,598
• 金曜の夜にテンポラリ会員コードへの更新を行って、土日で新会員コードへの洗い替えをやっていて日曜日の 23:00 くらいにこんな感じでしたね。
• 直後にお詫びのメールを送って翌日朝一でお詫びの電話しました。
• この時点で更新のオーバーヘッドより、更新対象検索のオーバーヘッドが大きいと判断して、いくつかのサンプリングで確認した結果、無効にしていたインデックスを有効にして更新を行なうこととしました。
• 土日で終了しなかったので月曜日は当該年度のデータのみを更新、この時点でインデックスを復活。当然、この日はサービス停止。テーブル データ件数 更新 (分 )
1万件当たりの秒数
会員マスタ 69,322 約 7 分 60.5868
会員所属マスタ 61,543 約 10 分 97.4928
受付テーブル 159,330 約 64 分 241.0092
予約テーブル 159,330 約 140 分 527.2077
ヘッダーテーブル 159,330 約 60 分 225.9461
コーステーブル 159,330 約 65 分 244.7750
明細テーブル A 854,569 20 分 46 秒 14.5805
明細テーブル B 44,081 約 90 分 1225.0176
明細テーブル C 1,770,240 36 分 6 秒 12.2356
明細テーブル D 360,356 約 910 分 1515.1683
明細テーブル E 162,150 約 47 分 173.9130
明細パラメータテーブル 159,329 約 96 分 361.5161
明細付加情報テーブル 360,250 約 900 分 1498.9590
印刷集計管理テーブル 335,480 約 70 分 125.1938
印刷履歴テーブル 124,474 約 38 分 183.1708
ワークフロー履歴テーブル 157,888 約 92 分 349.6149
ワークフロー制御テーブル 131,976 約 48 分 218.2215
テーブル データ件数 更新 (分 ) 1万件当たりの秒
数 会員マスタ 69,322 約 7 分 60.5868
会員所属マスタ 61,543 約 10 分 97.4928
受付テーブル 159,330 約 64 分 241.0092
予約テーブル 159,330 約 140 分 527.2077
ヘッダーテーブル 159,330 約 60 分 225.9461
コーステーブル 159,330 約 65 分 244.7750
明細テーブル A854,569
7,710,04520 分 46 秒
3 時間 28 分 56 秒14.580516.2593
明細テーブル B44,081
410,269約 90 分
1 時間 39 分 14 秒1225.0176
145.1242
明細テーブル C1,770,240
16,074,77636 分 6 秒
5 時間 22 分 29 秒12.235612.0368
明細テーブル D360,356
2,308,366約 910 分
1 時間 20 分 3 秒1515.168320.8069
明細テーブル E162,150
1,031,006約 47 分
1 時間 27 分 13 秒173.913050.7562
明細パラメータテーブル 159,329 約 96 分 361.5161
明細付加情報テーブル 360,250 約 900 分 1498.9590
印刷集計管理テーブル 335,480 約 70 分 125.1938
印刷履歴テーブル 124,4741,421,517
約 38 分26 時間 20 分 5 秒
183.1708666.9283
ワークフロー履歴テーブル 157,888752,948
約 92 分11 時間 20 分 43 秒
349.6149542.4412
ワークフロー制御テーブル 131,9761,153,622
約 48 分20 時間 10 分 21 秒
218.2215629.5043
残りも更新
原因は？
エクステントの分断化？
インデックスの更新にはオーバーヘッドがかかるという思い込み
ある件数を超えるとインデックス更新のオーバーヘッドより全表検索のオー
バーヘッドが大きくなる
全表検索＋データ更新 ＜ インデックス検索＋データ更新＋インデックス更新
全表検索＋データ更新 ＞ インデックス検索＋データ更新＋インデックス更新
データの件数が一定数を超えると
インデックスの構造
年次単位での参照が多いため年月日、会員コードの順番で複合インデックスが作られていた
• 余計なアクセスパスが多い• 一部のテーブルは年月日と会員 ID の順番が逆でインデックスが生成されていており、実際そちらの方がパフォーマンスがよかった。
• 正確にいうとマルチテナントのシステムだったので年月日の上にさらにコードがあった。
UPDATE 文 1 行 1 行流すんじゃなくて変換テーブルとの JOIN で更新するよう
なUPDATE 文で更新する方法も
あったんじゃないかと。
（先にあげた原因を解決するのはもちろんとして）
今後の反省として
自然キーもいいけど疑似キーもね
最近だったらクラウド環境で停止時間を最小限に
• 例えば別のインスタンスをスナップショット等から作成して、そちらを更新後に差分を適用するなど。
• 見積もりも本番と同じ環境でできるし。• 昔と違って DB のコピーを（お金はかかり
ますが）ポコポコ立てられる時代になったので。
以上、ご清聴ありがとうございました。