初期のDB設計と運用してからのDB設計 第05回 20年09月 / 最終更新：2020.09.07
システムの中で、「データ」というものは、ビジネスの観点からも運用の観点からも実装の観点からも、重要な片割れになるために。設計の中でも、比較的「上流から実装まで」幅広く関わってくるのが、DBの設計になります。
また、実装(プログラム)と比較しても、DBはより「リファクタリングがしにくい」ため、設計で失敗すると、より大きなダメージになりやすいのも特徴と言えるでしょう。
DBの設計は、まず初めに「どんなミドルウェアを使うか」という考察があり、次に「そこに格納するデータのレイアウト」や「バックアップやスケールのさせ方、監視などの運用」などが必要になってきます。
システムの規模にもよるのですが、個人的には「一端、RDB」「テーブルは"意味"を重視した設計」「バックアップ、スケール、監視などは、提供されているサービスがあったら一端それを使う」を基準にして、「それでは回らなくなってきそう」な事が予見されてから「あらかじめある程度想定している"次の手段"に移していく」ようにするのが、現実的なのではないか、と思います。
少しかみ砕いて見ていきましょう。
まずミドルウェアですが。
RDBは、歴史もそれなりにあり、どんな用途であっても「機能的には、とりあえずあまり問題なく」使う事ができます。
RDBでネックになってくるのはおおよそ「速度を含む性能」なので。「初めからかなり大きなサービスを想定している」のであれば多少考察は必要ですが、そうでなければ「一端はRDB」で間に合うシステムも多いのではないか、と思います。
また昨今、クラウドを使っているのであれば、ある程度までは「性能や速度や信頼性はお金で買える」側面もあるので、程度問題ではあるにしても、「(一時的に)お金で解決する」のも、一つの手だと思います。
システムの規模が大きくなる、ユーザ数が増えるなどして「RDBがボトルネックになってくる」タイミング、というのはあるので、いくつか例にとってみましょう。
まず「単純なログをRDBに入れる」のは、割と悪手だと思っています。
これについては、要件などにもよりますが、可能であれば「単純なテキストファイル」など、もう少し軽い所に、早めに切り出しておくほうがよいでしょう。
次に、例えばWebアプリケーションで「ユーザの様々な情報をセッションに格納している」ケースなどで、「(ロードバランシングをしているなどの理由から)セッションデータをDBに入れる」というような実装は、よくあるかと思います。
そういった「KVS的なDBで十分に間に合うもの」は、早めに考察をしておいて、適当なタイミングでKVS等に吐き出しておくと、それだけでも少し負荷が変わってきます。
また、こういった「見に行くDB先が変わる」事を見越して、ある程度「プログラムを抽象的なレイヤーで1枚ラッピングしておく」癖をつけておくとよいかと思います。
ただ一方で「事前に実装する」はYAGNIと相反する動きにもなってしまうので、その辺りのバランス感覚を身につける事も大切でしょう。
筆者は「後でこの辺をこういじるときはここを切りだそう」という大体の想定を、簡単にプログラムのコメントに残したり、空改行を多めに入れるようにしたりています。
これ以降はシステムによっても違いが大きくなってくるので一概に言いにくい所もあるのですが。
KVS、時系列DB、分散型分析エンジン、分散型メッセージキューなど、それぞれに「特定のエリアでRDBよりも強みのある」DBは、種類も実装も沢山あります。
そういったものをあらかじめ下調べしたりテストしたり実験したりしておくのは、先々の設計をより豊かにする上で、とても大切な事になるでしょう。
次回は、一端RDBにお話をもどして「テーブル設計」について色々と考察をしていきたいと思います。
サービス・ソリューション
