4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

日本情報クリエイト Engineer'sAdvent Calendar 2017

Day 7

さあ、何でもDBに持っていくのやめよ

Last updated at Posted at 2017-12-05

はじめに

どうも。1年経ってもMacに慣れない@Ntdoyです:relaxed:
今日は若手エンジニア向けにシステム設計のお話でも。

みなさん、パフォーマンスを意識した設計はされてますか?
ボトルネックは昔から変わりません。そう、データベースです!!

なぜデータベースがボトルネックになるのか

クエリがイケてない?クエリ投げすぎ?インデックスが効いてない?
そもそもテーブル設計が…うん、あるある。でもそれは作りの話。
根本的な問題はDBは負荷分散がしにくいということ。
DBはその強固なデータ一貫性を維持するために関連するデータを1箇所で持つ必要があるからね。
アプリケーションサーバーはPaaSの発展によりスケールアウトが容易になりました。
ただしDBだけはスケールアウト(出来るけど)出来ないと思っていた方がよいです。
(より上を目指す方は「クラスタリング」とか「パーティション」とか「シャーディング」で調べてみてください。)

じゃあどうする

本当にそのデータがDBに存在する必要があるかどうか見極めることが重要
下記の条件に当てはまるような場合はRDBが向いていると言えるでしょう。
・柔軟に検索条件を指定出来るような検索処理が必要である
・データの集計、並び替えが必要である
・データの更新、削除が頻繁に発生する
・データの一貫性が重要である(一時的にもデータの不整合(ダーティリードと呼びます)が許されない)
特に「データの一貫性が重要である」は本当に?と自問自答してみてください。
実は少々遅れても構わないケース結構あります。

上記に当てはまらない場合は積極的にDBから逃しましょう。ファイルでもNoSQLでも何でもいいです。
DBを捨てれなくても部分的に逃がすだけでも効果はあります。DBは貴重な資源と心得ること!

最後に

なーんて、こんなこと書いといて昔DBに持つ必要のないデータをDBに持ってしまって苦労した私でした:wink:
まぁそれでこれ書こうと思ったのですけど。では、また来年お会いしましょう。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?