【実践技術書】失敗から学ぶ RDBの正しい歩き方

「失敗から学ぶ」というタイトルの通りで、RDBの設計・構築の際のアンチパターンの紹介と解説になっています。

データベースはアプリケーションよりも寿命が長く、長い付き合いになるがゆえの特有の問題も発生します。 作者がこれまでに経験してきたアンチパターンを理解することで、設計や構築の際に予め問題を回避できるような心がけが出来ます。

まえがきにも描いてあるのですが、大きく以下の注意事項があります。

• データベースの停止はサービス停止を伴うことが多いため、メンテナンスしにくい
• データは常に増え続けるため、リファクタリングしにくい
• サービスの中核を担うため、変更の影響が大きい

他にも、複数のサービスから参照されることもあるので、サービスが終了してもデータベースだけ残されて運用することもあります。

RDBの問題はある日を境に顕在化することが多く、しかもサービスを停止させるような大きな障害を引き起こします。設計や実装・日々の運用の中で、障害が発生しない・影響の少ない・すぐに検知できるといった、いざといったときの備えをできるようになっておきたいです。

とりあえず削除フラグ

これはシステムで良く見ると思います。会員の削除とか、データの削除とかで作りがちなカラムです。

できるのであれば削除フラグは作らない方が良いです。事実のみを保存することを意識して、物理削除した上で削除済みテーブルに移動する設計が望ましいです。すでにカラムがある場合は必要なデータをViewで定義しておくような対応を検討しましょう。

削除フラグを設計することの問題として以下のことが考えられます。

• 削除済みデータが増えることでパフォーマンスが低下
  削除済みと未削除の2つの状態しか無いのであれば、カーディナリティが低いためインデックスの効果も薄いです。
• いろんなテーブルの削除フラグのチェックが必要
  ユーザーのみでなく、チームや記事やカテゴリーなど、すべての関連テーブルをJoinして削除フラグをチェックすることになるかもしれません。

意味を含んだID

IDに「先頭の文字が1ならユーザー・9なら管理者」などの意味をもたせることは避けましょう。

テーブルを分けて設計しましょう。データの属性によって入る値が変わるカラムやNULLが入るカラムが発生しないか確認しましょう。複数の目的でテーブルを使いまわさないように気をつけます。

この状態では以下の問題が考えられます。

• 一見しただけでは本来の状態を読み取れない
• アプリ側では判断出来ないため不正なデータが登録されてしまう
• 1桁のみで表現出来なくなるかもしれない その場合は大掛かりな修正が必要になるでしょう。

バックアップ

バックアップはちゃんと取ろうということです。

正しく取得できているか、それを確認しているか。障害が発生したときの復元はできるか、ドキュメントはあるか、定期的に練習を行っているかなど、考えるべきことはたくさんあります。いざ、なにか発生したときは心に余裕もありません。そんな状況で素早く的確に作業を行うためにも、日々の準備は大切です。

プロジェクトやチームでの文化づくりも重要ですし、作業や知識が属人化しないためのドキュメント化なども重要です。

非正規化

非正規化は基本的に行わず、必要になったタイミングでは設計に問題がないか、他の代替手段はないかを検討しましょう。多くのケースでは他の解決方法があるはずです。

以下のタイミングで非正規化を行いたくなるそうです。なんとなく覚えがあるものもあります。えいやっで非正規化に手を出さず、落ち着いて他の解決方法がないか検討しましょう。

• テーブルを作って正規化するのがめんどくさい
• 外部キー制約によるデッドロックなどが発生している時
• Joinコストが高まりパフォーマンスに影響がある

おわりに

RDBで設計する上でありがちなアンチパターンが共有されており、とても役に立つ知識でした。確かに実務の上で良くあることばかりかなと思います。

この本では、ありそうな依頼内容や開発者の気持ちなどが書かれており、「あるある」となるようなエピソードばかりです。技術的負債となって未来の自分が苦しい思いをしなくて済むように、しっかり意識して設計・運用に取り組めるようになりましょう。

一人で開発していると、なかなかアンチパターンに気づかないこともあります。複数人でレビューするなど仕組みの面でも防げるような取り組みができるといいですね。