本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「業務でRDBと付き合い始めたので久々に読む「失敗から学ぶRDBの正しい歩き方」書評」を再編集したものです。
はじめに
データベース（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の甘い罠
第9章 強過ぎる制約
第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周りをいじっていて面白いことを見つけたらまた何か書きます。
■Amazon.co.jpで購入
FIXER Inc. 南條 祐輝(a.k.a.なむゆ)
Fintech事業部のバックエンド担当ですがフロントエンドの仕事もしたいです。
本の虫。
面白い本を教えてもらうと喜びます。
Azure、AWS、GCP、データベース、セキュリティー、アーキテクチャなどいろいろ書いていきたいです。
AWS associateに完全勝利しました。
春のIPAはDBS受けます。
