2019/08/02の勉強会で発表されたものです。

1. ギブミーパフォーマンス！
発表者：トビウオ
〜DBスキーマを変更して高速化した話〜

2. CONTENTS
1. 遅すぎるクエリを叱咤してるんだ
2. プロファイラは混沌の至宝
3. “完璧”より”実用”がいい
4. インターフェースは譲れない
5. どこでだって教訓を得られるはず

3. １. 遅すぎるクエリを叱咤してるんだ
• 次のようなWebサーバーがあった
センサー
(それぞれIDが振られている)
Webサーバー
1[ms]毎の
データN個を含む
パケットが
定期的に
送信される
REST APIで、
指定した
時間の区間の
計測データを返す
画像：いらすとや

4. １. 遅すぎるクエリを叱咤してるんだ
• 次の表のようにスキーマを組んで管理していた
• レコード数が嵩むとパフォーマンスが劇的に落ちる問題が報告された
time
タイムスタンプ(UNIXミリ秒)
device_i
d
デバイスID
data
計測データ(浮動小数点数)
1564710311123 aaa 3.14
1564710311124 aaa 15.9
1564710311125 bbb 2.65
クエリ例：SELECT time, data FROM table
WHERE time >= 1564710311000 AND time <= 1564710911000 AND device_id = “aaa”

5. ２. プロファイラは混沌の至宝
• どこにコストが掛かっているかをプロファイリングした
• プログラム：プロファイラを使用する。Javaのように、公
式がプロファイラを提供してくれていることも
• データベース：DB依存だが、EXPLAINコマンドで実行計
画や予想コスト・実際に掛かったコストを確認できる

6. ２. プロファイラは混沌の至宝
• 調査した結果、インデックスを張っていたname列について
は絞り込みが効くが、timestamp列はフルテーブルスキャ
ンに近い挙動をしていたことが判明
• Webサーバーには未取得のデータが蓄積されるため、放っ
ておくとどんどんクエリ性能が悪化することになる

7. ３. “完璧”より”実用”がいい
Before
After
センサー
(1[ms]毎のデータN個)
tim
e
device_i
d
dat
a
N行のレコード
1パケット
センサー
(1[ms]毎のデータN個)
device_i
d
start
t
en
d
dat
a
1行のレコード
1パケット

8. ３. “完璧”より”実用”がいい
device_i
d
デバイスID
start
タイムスタンプ(UNIXミリ秒)
end
タイムスタンプ(UNIXミリ秒)
data
パケット(
バイナリ)
aaa 1564710311123 1564710311172 BLOB
aaa 1564710311173 1564710311222 BLOB
bbb 1564710311223 1564710311272 BLOB
• パケットから先頭・末尾のタイムスタンプを取得し、それらとパケットをDBに記録す
る
• SELECTした後は、パケットを展開してからタイムスタンプ毎にソートする
クエリ例：SELECT device_id, start, end, data FROM table
WHERE device_id = “aaa” AND end >= 1564710311000 AND start <= 1564710911000

9. ４. インターフェースは譲れない
• かなり大胆なテーブル変更にも関わらず、データベース操作部
分以外はほぼ変更しなかった
• データベースを利用する側・直接操作する側とで同じインター
フェースを共有している(依存性逆転の原則)
DB
インターフェース
tim
e
device_i
d
dat
a
device_i
d
start
t
en
d
dat
a
DBの実装1
DBの実装2
利用側(変更なし)

10. ５. どこでだって教訓を得られるはず
• 雑なテーブル設計は深刻なパフォーマンス
劣化を招くことがある
• あえて汚い設計が必要なこともある
• 転ばぬ先の抽象化