落とし穴に立て札を立てるが如く

ハマりどころの解決が少しでも早くなることを願って書いていきます

業務でDBと付き合い始めたので久々に読む「失敗から学ぶRDBの正しい歩き方」書評

f:id:nam_yu_sql:20200331072906j:plain この記事はcloud.config tech blogにマルチポストされる予定です。

はじめに

DB、いいですよね。
個人的に以前からDBに興味があって、各種DBの最適化の方法を学んだり、去年は春のIPA試験でデータベーススペシャリストの試験を受けたり(落ちたり)、今年もまた受けようとしたりしています。
そんな中で去年と今とで変わった点が一つあって、それは自分がRDBを実務で弄り始めたことです。
.Net Coreを用いてアプリケーションを作る中で、ORMであるEntityFrameworkを用いてSQLServerにアクセスする部分を何度か実装し、そのアクセスする先のテーブルのスキーマ設計もいくらか経験してきました。
そこでそろそろデータベース周りのノウハウ系の本を読んでみようかという気になり、久々に読んだのが今回書評する本、「失敗から学ぶRDBの正しい歩き方」です。

どんな本なの?

この本の著者さんは2017年と2018年にData Platformの分野でMicrosoft MVPを受賞したデータベース分野でのスペシャリストで、ブログや登壇などを通してRDB、特にPostgreSQLのノウハウを共有しています。
特に、RDBのリファクタリングRDBアンチパターン対策について詳しく、れらに関する過去の登壇や記事などで触れられた内容が凝縮して纏められたような本です。
目次を見ると各章のタイトルはアンチパターンの内容となっており、それらの問題点とそれを起こさないようにする対策が章ごとに纏められています。
各章の繋がりはそこまで強くないので、気になったトピックから読み始められます。
テーマとして大雑把に分けると、見た感じ9章までがテーブル設計上の問題、10章以降が運用上で起きる問題について扱っている印象です。
現在設計、実装寄りのタスクをしている方は前半部、運用を行っている方は後半部が気になるのではないでしょうか。

目次

第1章 データベースの迷宮
第2章 失われた事実
第3章 やり過ぎたJOIN
第4章 効かないINDEX
第5章 フラグの闇
第6章 ソートの依存
第7章 隠された状態
第8章 JSONの甘い罠
DB9章 強過ぎる制約
第10章 転んだ後のバックアップ
第11章 見られないエラーログ
第12章 監視されないデータベース
第13章 知らないロック
第14章 ロックの功罪
第15章 簡単過ぎる不整合
第16章 キャッシュ中毒
第17章 複雑なクエリ
第18章 ノーチェンジ・コンフィグ
第19章 塩漬けのバージョン
第20章 フレームワーク依存症

気になったトピック

データベースというもの自体の性質の話

「データベースの寿命はアプリケーションより長い」という言葉がこの書籍の中で頻繁に出てきます。
この言葉は書籍内だけでなく著者のブログやスライドにおいても頻繁に出てくる言葉なのですが、データベースリファクタリングを考えるときの最も根底にあると個人的には考えている言葉です。
例えば、何かしらアプリケーションを作る際にはそのアプリケーションで扱うデータの保存先としてデータベースを使用するわけですが、そのアプリケーションがサービス終了するとして、そこで利用していたデータの全てをアプリケーションのシャットダウンと同時に削除するわけではないはずです。
既存のデータに価値を見出し、他のサービスでも利用しようと考えるのではないでしょうか。
そうした際、データベースの設計に問題がありパフォーマンスや拡張性に影響があったとしたら、その影響は新しいアプリケーションにまで及びます。
さらに、そんな問題を解決しようとすれば大抵の場合サービスを停止させて直す必要が出てくるので、顧客満足にまで悪影響が出ます。
なので、データベースを設計する際には後々のことまで考えて問題が起きないようにしようねという文脈ではこの言葉が頻繁に出てきます。

MENTORの原則の一つ、理論より計測の話

INDEXをどのように設定していくかという話の中で、MENTORの原則という言葉が出てきます。
これは、それぞれ"Measure"、"Explain"、"Nominate"、"Test"、"Optimize"、"Rebuid"の頭文字をとったもので、INDEX作成時の対応の考え方をまとめたものです。
"M"以外のものは各々調べていただくとして、この中のMeasureは読んでいて特に重要なのではないかと感じました。
というのも、理屈の上では「ちゃんと利用できる箇所でINDEXを張るとクエリが速くなる」ということを理屈では知っていますが、結局はそれを基にして本当にクエリが速くなったか確認する必要があるからです。
「このINDEXを張れば理屈の上では速くなるはず!」と考えていても実際にINDEXを張る前後で比べて変化がなければ、そのINDEXは意味がなかったことになります。
無駄なINDEXは容量を圧迫するだけなので作らないでおくべきという考えからするとこのINDEXは作らない方がよかったという結論になります。
その上で実際に有効なINDEXはどのようなものなのか実行計画を確認しながら考えて本当に有効なINDEXを張り直すということを通してクエリを速くできるので、まず最初にはその対応で本当にクエリが速くなるのか、計測して確かめることが重要であるといえます。

おわりに

・・・などと記事を書いていたら今年の春のIPA試験はコロナの影響で中止になったようです。
外に出るのも憚られるこのご時世なので、休日は家に籠ってDBを動かしてみるのもいいかもしれません。
DB周りをいじっていて面白いことを見つけたらまた何か書きます。