データベース基礎 #7 - NoSQL

DevOps

Last Edited: 5/2/2025

このブログ記事では、NoSQLデータベースについて紹介します。

DevOps

これまで、私たちはリレーショナルDBMS、特にその堅牢性と豊富な機能を持つPostgreSQLの論理的および仮想的スキーマについて議論してきました。 リレーショナルDBMSとSQLの使用は多くのユースケースで最も安全なアプローチといえますが、NoSQLと呼ばれる代替データベースもあり、 これらは独自の目的を最もよく果たすために関係データモデルを使用しません。そこでこの記事では、主要なNoSQLデータベースである、 キーバリューストア、ワイドカラムデータベース、ドキュメント指向データベース、グラフデータベースなどについて簡単に説明します。

キーバリューストア

キーバリューストアは、データを単純なキーと値のペアとして保存するデータベースで、リスト、順序付きセット、 マップなどの様々なデータ構造を活用して複雑なデータを柔軟に整理します。その単純さ、柔軟性、パフォーマンスのためのインデックス作成のサポートにより、 高速応答のためにデータを一時的にメモリに保存するキャッシングや、データの永続性と高可用性・高性能を備えたインメモリデータベースとしてよく利用されます。 Redisはキーバリューストアの主要な例であり、キャッシングと永続的なインメモリデータベース機能の両方をサポートし、クラウドソリューションも提供しています。

しかし、キーバリューストアをインメモリデータベースとして使用することは、クエリ機能とサポートされる機能が限られているため、あまり好まれません。 他のデータベースへの移行も困難な場合があります。そのため、Redisは主にPostgreSQLと組み合わせてキャッシュとして使用されます。 具体的には、まずキャッシュからデータをリクエストし、キャッシュヒットの場合はキャッシュから応答し、キャッシュミスの場合はデータベースにリクエストを送信し、 応答をキャッシュに保存してユーザーに返すシステムのキャッシュ部分として使用されます。この際、キャッシュを最新かつできるだけ軽量に保つために、 有効期限を設定し、アクセス頻度が最も低いまたは最近使用されていないデータを削除するキャッシュ無効化も実行します。

ワイドカラムデータベース

ワイドカラムデータベースは、列または属性を行として保存する列指向データベースであり、 多数のエンティティから属性のサブセットをクエリすることが容易で高性能になります。 これはデータ分析に非常に強い関連のある特性です。列は行として編成されているため、 ディスク上や異なるサーバー間で個別に保存できます。このプロセスはシャーディングと呼ばれ、 分散データベースシステムを設定するための水平スケーリングが容易になります。 また、ゲームやeコマースなど、高い書き込みスループットや時系列データを必要とするアプリケーションにも適しています。

Apache Cassandraはワイドカラムデータベース用の無料でオープンソースのDBMSの主要な例であり、 Scylla DBなどの他のソリューションと共に、複数のソースからのデータを中央リポジトリに保存し、 ビジネスインテリジェンスと分析のために列に整理するデータウェアハウスとして使用できます （データレイクは生データを保存し、データウェアハウスはデータを構造化します）。 しかし、クエリ機能と機能が限られており、複雑なデータ構造と関係のためのデータモデリングが限られているため、 リレーショナルデータベースシステムの代替にはなりません。

ドキュメント指向データベース

キーバリューストアやワイドカラムデータベースは主にリレーショナルデータベースシステムの直接的な代替として設計されていませんが （Redisはプライマリデータベースとして使用できるインメモリデータベースソリューションを提供していますが）、 データをドキュメントとして保存するドキュメント指向データベースは、汎用的なデータベースシステムの直接的な代替として設計されています。 これらのドキュメントは通常、圧縮されたXML、YAML、JSONであり、これらは人間が読みやすく、 多くのクライアントアプリケーションで使用される複雑なオブジェクトをモデル化するための自然なデータ形式であるため、 ドキュメント指向データベースを使用する開発者にとってスムーズな体験を提供します。

また、スキーマを必要とせず、現代のアジャイル開発に適した柔軟性を提供し、場合によっては複雑なクエリを簡素化します。 ドキュメント指向データベースの主な例はMongoDBで、圧縮されたBSON形式を使用してJSONとして直接取得でき、 水平方向のスケーラビリティのための最適化されたシャーディングや他の様々な有用な機能（スキーマ、トランザクションなど）を備えたセルフホスティングとクラウドソリューションを提供しています。 開発者のユーザーエクスペリエンスと迅速な開発を優先する高度に抽象化されたソリューションの人気が高まっているため、MongoDBの人気も高まっています。

MongoDBや他のドキュメント指向データベースは柔軟性を提供しますが（特に初期段階で有益）、これにはトレードオフがあります。 リレーショナルデータベースの厳格なスキーマは一貫性、データの整合性を提供し、重複を減らすため、後期段階では特に重要になります。 そのため、ドキュメント指向データベースのスケーラビリティに関わらず、開発者はアプリケーションをリファクタリングしてリレーショナルデータベースに移行する必要が生じることがあり、 長期的にはコストがかかる可能性があります。したがって、ドキュメント指向データベースが適切かどうかを分析し、 ユースケースに応じてコストを比較することが重要です。（補足：PostgreSQLはJSON属性タイプをサポートしており、 部分的にドキュメント指向データベースとして使用することができます。）

グラフデータベース

リレーショナルデータモデルは複雑な関係を持つグラフデータの処理には適していません。しかし、グラフ（ソーシャルネットワーク、地理空間グラフなど）を保存する需要は、 グラフアルゴリズムとグラフ機械学習がより高度な操作と分析（レコメンダーシステム、異常検出など）を可能にするにつれて急速に高まっています。 このブログのGLシリーズをチェックして、GNNとさまざまなグラフ関連タスクでの能力を探索することができます。

この需要に応えて、ノードとエッジに基づくグラフデータモデルとクエリ言語（GQL）を備えたグラフデータベースが登場しています。 Neo4jが主な例です（Neo4jはGQL、Cypherと呼ばれるものを発明し、MATCH (p:Person)-[:LIVES_IN]->(c:City) RETURN p.first_name, c.nameのようにグラフデータを簡単にクエリできるようにしました）。 分析目的と直感的なクエリ体験という明らかなメリットに加えて、グラフデータベースはリレーショナルDBMSとは異なり、 関係を含む各クエリに対してテーブル結合を実行する必要がありません。エッジをたどるだけで（複数のホップ離れたノードでも）ノードを最小限のオーバーヘッドでクエリすることができます。

結論

この記事では、キーバリューストア、ワイドカラムデータベース、オブジェクト指向データベース、グラフデータベースの4種類のNoSQLデータベースを簡単に取り上げました。 これらはすべて異なる目的を持ち、リレーショナルデータベースと併用することができます（ドキュメント指向データベースとリレーショナルデータベースを併用することは比較的まれです）。 上記以外にも、類似性検索（レコメンダーシステムやRAGに関連）を実行するためのベクトルインデックスでデータを保存するベクトルストアなどの他のNoSQLデータベースもあります。 したがって、各ユースケースに最適なデータベースを選択するために、様々なデータベースタイプとその実装の利点と欠点を常に分析することをお勧めします。

リソース

TOPに戻る↑