「NoSQL」が存在する理由と、無視できない“欠点”とは？

RDBMSではないDBMS「NoSQL」は、高いスケーラビリティが特徴だ。NoSQLの基本的な仕組みと、NoSQLが抱える課題を解説する。

公開 2020年12月16日 05時04分

更新 2020年12月16日 06時10分

著者

Chris Foot

[TechTarget]

印刷する連載新着通知を受け取る

　リレーショナルデータベース管理システム（RDBMS）と、それ以外のデータベース管理システム（DBMS）である「NoSQL」両方のメリットを生かしたDBMSとして「NewSQL」が台頭しつつある。その特性は、前編「いまさら聞けない『ACID特性』『オンライントランザクション処理』（OLTP）の基礎」で解説した通りだ。中編はNewSQLの土台となるNoSQLを取り上げ、そのメリットとデメリットを説明する。

併せて読みたいお薦め記事

データベースの課題を考える

DBMS活用事例

NoSQLの存在意義と“無視できない課題”

　NoSQL誕生の背景には、スケーラビリティと可用性を維持し、データを分散化させ、非構造化データを格納することが可能なDBMSを求める声があった。初期のNoSQL製品は、こうしたニーズを満すように設計されていた。

　DBMSを拡張する従来手法は、DBMSを稼働させているサーバの筐体を開いてCPU、メモリ、ストレージといったリソースを追加するか、より多くのリソースを備えたサーバにDBMSを移行させることだ。一方NoSQLはサーバをクラスタリングし、クラスタにサーバを追加することで拡張できる仕組みを持つ。

　NoSQLでスケーラビリティを実現するために使われる仕組みが、データを複数のストレージに分散させる「シャーディング」だ。NoSQLにおけるシャーディングは管理者が定義した、あるいはシステムが生成したシャードキー（データの識別情報）に基づいてデータをグループ化し、ストレージをさまざまなノードに割り当てる。

データの一貫性に関する問題

　DBMSを拡張する際にはデータの一貫性が大きな問題になる。NoSQLのメリットはスケーリングが容易なことだが、それと引き換えにデータの一貫性が犠牲になることが少なくない。

　NoSQLはデータの書き込み時に、クラスタ内の全てのサーバにデータを複製（レプリケート）する。それらのデータの一貫性は必ずしも保証しない。この問題はネットワーク障害によってクラスタ内のサーバ同士が通信できなくなった場合に生じる。全てのサーバにアクセスできても、ネットワーク障害によってデータの更新が全てのサーバに適用できなければ、各サーバ内のデータに一貫性がなくなるためだ。

　全てのサーバでデータの一貫性が保証できないとしても、DBMS全体としては最新のデータを提供できる。これを許容できる用途もあるが、金融取引などデータの厳密な一貫性が求められる用途には最適な選択肢とは言えない。