弊社のアドベントカレンダー専門テックブロガーのthorikiです。
来年でバックエンドエンジニア歴20年になるので、入社当時の状況も振り返りつつ、データストアの選択肢について書こうと思います。
データストアのむかし
RDBMSといえばOracle一択の時代
入社した当時（2005年くらい）は「データベースと言えばRDBMS」っていう暗黙の了解がありました。
ほぼ一択状態で、商用DBMSなら「とりあえずOracle使っとけ」みたいな風潮でした。企業で採用するのも自然とOracle。もちろん、ライセンス料は高かったんですけど、それに見合う信頼性がありましたし、選択肢が少ないから逆に悩む必要もありませんでした。
一方で、MySQLやPostgreSQLみたいなオープンソースのRDBMSもちらほら登場していました。ただ、当時の印象としては「無料だし試してみてもいいけど、まあ本番で使うならやっぱりOracleだよね？」っていう感じでしたよね。安定性とかスケーラビリティがまだ未知数でしたし、OSSを本番運用するなんて少し勇気が必要だった時代です。
NoSQL？そんなのあったっけ？
NoSQLって言葉が出てきたのが2000年代後半で、Redisの初版が登場したのは2009年。つまり、15年前はNoSQL自体がまだ産声を上げていない頃です。
当時、キー・バリュー型ストアやドキュメントDBのようなデータストアは、一般的なエンジニアの視界には入っていませんでした。「データベース＝テーブル構造」「整合性が命」というのが当たり前の感覚で、分散データベースなんて夢物語。データ量が増えると「スケールアウト」とか言い出すのではなく、「頑張ってチューニングする」が唯一の選択肢でした。
今振り返ると…
昔は「選択肢が少なくて楽だった」とも言えますが、それだけ制約も多かったわけです。スケーラビリティや柔軟性を犠牲にしてでも「安定して動くもの」が求められていました。
データストアのいま
さて、現代に話を戻しましょう。20年前と比べると、データストアの世界はもう別次元ですよね。選択肢が増えすぎて、「何を選べばいいのか逆にわからない！」なんて状態ですね。
RDBMSも進化してる！クラウド込みで選び放題
RDBMSは相変わらず重要な選択肢のひとつですが、昔の「Oracleか、安く済ませてMySQLか」みたいな時代とは全然違います。
AWSのRDSやGoogle Cloud SQLみたいにクラウドがデフォルトになりました。
さらに、Azure SQLやAuroraなんて選択肢もあって、機能面でもスケーラビリティでも進化が止まりません。「オンプレで頑張る」とか言ってたあの頃が懐かしくなるくらい、今は簡単に高機能なRDBMSが使える時代になりました。
NoSQL：とりあえず何でも揃ってる！
一方で、NoSQLもすごい勢いで選択肢が増えました。昔は「NoSQLって何それ美味しいの？」状態だったのに、今ではKey-ValueストアからドキュメントDB、グラフDB、カラム指向DB、時間系列DBと、用途に応じて選び放題です。
- Key-Valueストア: RedisやDynamoDBは、速度重視のアプリケーションで大活躍。キャッシュ用途に最適。
- ドキュメントDB: MongoDBなど、柔軟なスキーマが必要なケースにフィット。
- グラフDB: Neo4jやAmazon Neptuneが、複雑なリレーションを扱うのに最高。SNSや推薦システムで威力を発揮。
- 時間系列DB: InfluxDBやTimescaleDBが、IoTやログデータの分析で重宝します。
これだけ選択肢があると、「とりあえずRDBMSで」って選ぶのが逆に時代遅れに見えてきました。
自分の認識の変化
当然ですが２０年で自分の認識も変化しました。
昔の認識：CRUDのためのデータモデル整形がアプリケーションの役割
昔の自分の認識では、アプリケーションの大きな役割のひとつが「データをDBの形式に合わせる」ことでした。データの保存と取り出しを効率化するために、RDBMSのテーブル設計を軸にしてアプリケーションのデータ構造を決めていたんです。
具体的には、「リレーショナルモデルに合わないデータ構造？ じゃあアプリ側で分解して保存しよう」みたいな感じですね。コアなデータは完全にRDBMSに依存していて、それが正義だと思っていました。
実際、テーブルの構造に合わせておけば、処理に問題はあってもデータ自体の整合性みたいなものを保てるよね？だからOKみたいな認識でした。
そういう意味でバックエンドサーバーアプリケーションの設計の第一歩目はTBL設計（ER図）の作成から始めてました。
今の認識：データストアのデータモデルはドメインモデルじゃない
ここが大きく変わったポイントです。「データストアのデータモデル＝ドメインモデル」ではありません。むしろ、データストアのデータモデルはアプリケーションのドメインに寄り添いすぎるべきではないんです。
なぜなら、データストアの役割はあくまで永続化すること。データを効率よく保存し、必要に応じて速やかに取り出せるようにするのが目的です。ドメインモデルそのものを忠実に再現するのは、データストアの仕事ではなく、アプリケーションの仕事です。
例えば、RDBMSで「ドメインモデルにピッタリ合う！」と喜んでそのままテーブル設計をしてしまうと、後で「クエリが複雑になりすぎる」「インデックスが効率的に機能しない」「スケーラビリティが限界を迎える」なんてことが起きかねません。RDBMSは効率よく動かすために正規化や非正規化、インデックス設計など、用途に応じた最適化を考慮するべきです。
データのグラデーション：データの価値は同一ではない
保存するデータを一律に扱うべきではありません。なぜなら、保存するデータには重要度や用途に応じたグラデーションが存在するからです。このグラデーションを理解して適切なデータストアを選択することが、システム設計の鍵となります。
データのグラデーション：コアバリューの高いデータ - 低いデータ
保存するデータは大きく分けて以下の2つに分類できます。
- コアバリューの高いデータ
これは、業務の中心となるデータで、ビジネスロジックや意思決定に直結する重要なデータです。顧客情報、注文履歴、財務データなどがこれに該当します。このデータは、正確性や整合性が非常に重要で、一貫性を欠くと業務そのものが崩壊するリスクがあります。 - コアバリューの低いデータ
一方で、業務の中心ではないものの、運用や分析、エクスペリエンス向上のために必要なデータも存在します。ログデータ、キャッシュ、ユーザーの操作履歴などがこれに該当します。この種のデータは、一部の欠損や不整合が業務に致命的な影響を与えることは少なく、スケーラビリティや柔軟性が求められるケースが多いです。
グラデーションに応じてデータストアを選択する
コアバリューの高いデータ：RDBMSが活躍する領域
コアバリューの高いデータは、トランザクションの正確性やデータ整合性が最優先事項です。このため、RDBMSが最適な選択肢になります。
- 理由1: ACID特性
RDBMSは、トランザクション処理でACID特性（原子性、一貫性、分離性、持続性）を満たしており、データの正確性を保証します。 - 理由2: スキーマによる一貫性
厳密なスキーマが設定されているため、データの構造が強制され、予期しない不整合が発生しにくい。
コアバリューの低いデータ：NoSQLで柔軟に対応
コアバリューの低いデータには、柔軟性やスケーラビリティが求められます。この領域ではNoSQLの特徴が生きてきます。ただし、検索の方法や利用シナリオによって、適したデータストアが異なるのがポイントです。
- キー・バリュー型（例: Redis, DynamoDB）
高速アクセスが求められるキャッシュやセッション情報に最適。 - ドキュメント型（例: MongoDB, Couchbase）
柔軟なスキーマが必要なアプリケーションや、JSON形式のデータをそのまま保存したい場合に向いている。 - グラフ型（例: Neo4j, Amazon Neptune）
ソーシャルネットワークや推薦システムなど、複雑なリレーションを持つデータに適している。 - 時間系列型（例: InfluxDB, TimescaleDB）
IoTデータやログデータのように、時系列分析が必要な場合に最適。
データストアの設計：もはやER図ファーストな世界ではない
ER図の限界：NoSQLには厳密な反映が難しい
RDBMSでは、データ設計の基本としてER図を作成し、その設計をもとにテーブルを構築するのが一般的です。データの関係性が明確に図示されるため、設計の段階で構造をしっかり考えることができます。
しかし、NoSQLの場合、データがJSONやドキュメント形式で保存されるため、ER図をそのまま厳密に反映するのは現実的ではありません。NoSQLはスキーマが柔軟であることがメリットのひとつであり、データ構造が固定化される設計方法にはそぐわない場合が多いです。
ER図そのままのフローは選択肢を狭める
ER図をそのままデータストアに反映するような設計フローは、RDBMSには適していますが、NoSQLを選択肢に入れるときには避けた方が良いでしょう。これを続けると、NoSQLの柔軟性やスケーラビリティといった特性を無視することになり、結果的に設計の自由度が失われます。
むしろ、概念設計の段階で「データ同士の関係性をざっくり把握する」程度に留めるのが現実的です。詳細設計はデータストアの特性に合わせて柔軟に対応するべきであり、「ER図どおり」にこだわらない設計が求められます。
データの重要度で考える：柔軟な選択肢を持つために
ER図に頼りすぎるのではなく、保存するデータを「重要なデータ」と「そうでないデータ」に分けることが、設計をシンプルにすることにつながるかと。この分類に基づいてデータストアを選択すれば、RDBMSだけでなく、NoSQLも自然と選択肢に浮かび上がります。