覚えたら書く

IT関係のデベロッパとして日々覚えたことを書き残したいです。twitter: @yyoshikaw

「失敗から学ぶRDBの正しい歩き方」

「失敗から学ぶRDBの正しい歩き方」 を読んでみました。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

内容紹介では以下のように書かれています。

失敗から学んで、MySQLとPostgreSQLの設計・運用を見直す

「データベースがよく落ちる」
「前任者が残したテーブル、SQLが読み解けない」
「RDBMSを入れ替えたら予期せぬバグが」
――MySQLやPostgreSQLといったRDBMS(リレーショナルデータベース管理システム)を使った業務システム、
Webサービスを設計・運用していると、こういった問題によく直面するのではないでしょうか。
本書はRDB(リレーショナルデータベース)の間違った使い方(=アンチパターン)を紹介しながら、
アンチパターンを生まないためのノウハウを解説します。
それぞれの章では、問題解決に必要なRDBやSQLの基礎知識も押さえるので、
最近RDBMSを触り始めた新人の方にもお勧めです。


目次以下のようになっています。

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


読み終わった感想は、

「この本をもっと早くに読みたかった(もっと早くに存在していてほしかったw)」

です。

正直、インターネット上にも同様の情報が存在していたりしていますが、
こうして書籍に整理されてまとまっていると、読みやすいですしとても理解しやすいです。


書籍の冒頭の「はじめに」というページで、以下のように書かれています。(一部抜粋)

「データベースの寿命はアプリケーションよりも長い」が筆者の持論です。
なぜならば、データベースはサービス開発当初から存在することが一般的で、
アプリケーションコードのようにリプレースされることは稀だからです。

・・・

RDBは広く使われている反面、次のような注意事項があります。
●データベースの停止はサービスの停止を伴うことが多いため、メンテナンスしにくい
●データは常に増え続け、リファクタリングしにくい
●サービスの中核を担うため、変更による影響が大きい

このように、RDBのアンチパターンはアプリケーションのアンチパターン以上にダメージが大きいのです。
そして厄介なことに、RDBの問題はある日を境に顕在化するということが多いです。
当初は良かれと思った設計が、あとになって問題を引き起こすこともままあります。
・・・

本当に、これはまさにだと思います。

昨日まで正常に動作してたのに今日になって急に問題が発生するというのは、RDBのあるあるだと思います。

筆者含めて多くのエンジニアが経験してきた(データベースの)問題をパターン集として共有化してくれています。
そして、本当はどうすべきだったのかという道しるべが書かれています。

経験済みの人は、あの時こうすればよかったのかと理解できますし、
まだ問題の状況を経験していない人も将来起こりうる問題を疑似体験させてくれます。

DBにちょっとでも触れるエンジニアは全員読んだ方がいいと思います。

そのぐらい良い本です。


RDBの設計をする上で念頭におきたいこと

RDBの設計をする上では当然のことなのかもしれませんが、
自分の中で念頭に置いておかなければならないと思った内容を書籍内から一部抜粋しました。

  • RDBは、"時間軸と直交するような設計" が大切です。ですがそれを使ったサービスとしては、
    時間軸と直交しないデータ=履歴を保存することが同じくらい重要です。
  • RDBはRelational Database(リレーショナルデータベース)の頭文字を取っています。その元となっている考え方がリレーショナルモデルで、リレーショナルモデルは集合を扱うデータモデルのことです。
    • 集合には次のような性質があります。
      • 重複がない
      • 実在する要素しかない(NULLがない)
      • 要素に順序がない
    • ソフトウェアとしてのRDBMSには重複もNULLもソートもあります。実際に必要なデータは多種多様で、リレーショナルモデルのみで表現することは難しいため、拡張されているのです。
    • RDBMSは、リレーショナルモデルよりも幅広くデータを扱えることで表現力が上がりましたが、やはりリレーショナルモデルがもとになっているため、リレーショナルモデルにない世界を扱うことは苦手です。
      ソートはリレーショナルモデルの外の世界の話ですので、パフォーンスのボトルネックになりやすいのは必然なのです。


まとめ

ちょっとコンテキストが違うかもしれませんが、
「勝ちに不思議の勝ちあり、負けに不思議の負けなし」という言葉があります。(江戸時代の大名、松浦静山の剣術書『剣談』)
勝つ時(成功した時)は偶然勝つこともあるが、負ける時は必ずその負けた理由(失敗した理由)があるという意味です。

成功や勝ちに関しては運や偶然がつきまとい、成功の原因を導き出そうとしてもただの結果論でしかない場合も少なくありません。
それに対して、失敗や負けといったものは必然性が高く、その原因分析することに意味があるケースが多くあります。
一つ一つの失敗を積み上げると法則性や対処方法が見えてくることがあります。

今回取り上げた書籍も "失敗から学ぶ..." というタイトルが付いており、まさに失敗からの法則性を導き出しているとも言えます。

この本を読んで、RDBに対して先んじて失敗してくれた人たちや事例から多くのことを学びましょう。



関連リンク