NoSQLデータベースは、リレーショナルモデルとは異なるデータモデルを採用したデータベース群の総称です。「Not Only SQL」と読み替えることもあり、SQLを否定するというより「SQLだけでは捌ききれないユースケースに別の道具を用意する」という発想で生まれました。Web2.0時代の大規模化、IoTのストリームデータ、ソーシャルグラフ等、従来のRDBMSが苦手だった領域の救世主として2000年代後半から急速に広まりました。
この記事の目次
- NoSQLの主な4タイプ
- NoSQLが必要になる典型場面
- CAP定理という前提
- RDBMSとNoSQLの近年の融合
- まとめ
NoSQLの主な4タイプ
NoSQLはひとまとめにされがちですが、内部のデータモデルで4種類に大別されます。Key-Valueストア（Redis、DynamoDB、Memcached）、ドキュメント型（MongoDB、Couchbase）、ワイドカラム型（Cassandra、HBase、Bigtable）、グラフ型（Neo4j）の4つです。それぞれ得意な検索パターンが違い、ひとつのNoSQLが万能ということはありません。
Key-Valueはもっとも単純で、ハッシュテーブルを巨大スケールに広げたイメージ。ドキュメント型はJSONを保存するイメージでスキーマレスに使え、ワイドカラム型は超大量の時系列データやログ、グラフ型は人脈のような関係性の検索に向きます。
NoSQLが必要になる典型場面
NoSQLが選ばれる場面は「RDBMSでやろうとすると無理が出る」典型的な領域です。セッション情報やキャッシュのように高速読み書きが要るならRedis、ユーザの書き込みが世界中から秒間数万件届くソーシャル系ならCassandra、IoTセンサーの時系列ログならInfluxDBやTimescaleDB、という具合に道具が分化しています。
重要なのは「整合性 vs 可用性 vs 性能」のバランスを意識すること。RDBMSは整合性を最優先する設計（ACID）に対し、多くのNoSQLは可用性・スケールを優先（BASE）します。金額のずれが許されない決済処理にNoSQLを直接使うのは難しく、ここはRDBMSの領分のままです。
CAP定理という前提
NoSQLを語る上で外せないのがCAP定理です。分散環境ではConsistency（整合性）、Availability（可用性）、Partition tolerance（分断耐性）の3つを同時に満たすことはできず、ネットワーク分断が起きた際にCを取るかAを取るかの選択を迫られる、というものです。
MongoDBやCassandraは元々A優先（落ちずに応答する）寄りで設計されており、DynamoDBは設定でCに寄せられます。「なぜそのNoSQLは整合性が緩いのか」を理解するうえで、CAPの考え方を押さえると製品選定の解像度が大きく上がります。
RDBMSとNoSQLの近年の融合
「RDBMS vs NoSQL」という二項対立は近年薄れつつあります。RDBMS側はJSON型・水平分散・NewSQL（CockroachDB、Spanner、TiDBなど）でNoSQL寄りのスケーラビリティを獲得し、NoSQL側は逆にトランザクションやスキーマ検証を取り込んでRDBMS的な使いやすさを目指しています。
結果として、現代のシステムでは「メインはRDBMS、キャッシュはRedis、ログはElasticsearch、検索はOpenSearch」のように複数のDBを役割分担させる構成が当たり前になりました。ひとつの正解ではなく組み合わせで設計するのが、これからのデータ基盤の常識です。
まとめ
NoSQLはSQLの代替ではなく、RDBMSでは届かない領域を埋める補完技術と捉えるのが現代の正しい理解です。用途を見極めて適切なNoSQLを選ぶスキルは、Webサービスの設計やインフラ運用で大きな差を生みます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント