KVS(Key-Value Store)は、既存のRDBと比べてシンプルな機能しかない代わりに、データを分割して多数のサーバーで分散処理できるスケーラビリティーの高さが特徴である。その代表例として、米Facebookが開発し、オープンソースソフトウエアとして公開されている「Cassandra」がある。

 KVSは従来にはなかった膨大なアクセスをさばくため、大手のWebサービス事業者などが続々と開発している。米Googleの「Bigtable」と米Amazon.comの「Dynamo」がその先駆であり、Cassandraは両者の設計思想を受け継いだものだ。

 Facebookは同社のSNS(Social Networking Service)において、ユーザー間で交換するメッセージの保存や検索などを行うデータベースとしてCassandraを開発し、最大150台程度のサーバーで運用した実績がある。最近ではほかにも多様な特性を持ったデータベースが開発されており、それらはSQLとは別の選択肢という意味で「NoSQL(Not only SQL)」と総称される。

スケーラビリティーと一貫性を検証

 NoSQLに共通した特徴は、サーバーの台数を増やせば性能(スループット)が向上するというスケーラビリティーの高さにある。今回その実力を、代表格であるCassandraを使って検証することにした(検証1)。

 またNoSQLは一般に、一部のサーバーが故障しても処理を続けられるように、データのコピーを複数のサーバーに保持する機能を持っている。コピーの一貫性をどこまで求めるかは、NoSQLによって異なるが、Cassandraではそれをアプリケーション側で制御できる。高い一貫性を求めるほど、性能は落ちると考えられる。そこで今回はCassandraが持つ、主要な三つの一貫性レベルのモードを試し、どれだけ性能が変わるのかを調べた(検証2)。

図1●Cassandraの検証環境の概要とスケーラビリティーの検証結果
ショッピングサイトにおいて、ユーザーが最近閲覧した商品を一覧表示するというアプリケーションを試作して、性能を検証した。データの書き込み、読み出し処理のスケーラビリティーを調べると、4ノードのときのスループットは2ノードの1.4倍、6ノードのときは同2.1~2.3倍になった
[画像のクリックで拡大表示]

 検証結果をまずまとめると、サーバー数を2台から、4台、6台へと増やしたとき、Cassandraのスループットはそれぞれ1.4倍、2.1~2.3倍に向上した(図1)。一貫性について三つのモードを比べると、最大2.2倍のスループットの差があった。

 検証用のアプリケーションとして、ショッピングサイトを想定し、そのサイトで「最近閲覧した商品一覧」をブラウザーに表示するというモジュールを試作した。それを使って、閲覧された商品名をユーザーID(キー)とともに連続して書き込んだときの性能と、連続して読み出したときの性能をそれぞれ調べた。

出典:日経SYSTEMS 2011年7月号 pp.52-53
記事は執筆時の情報に基づいており、現在では異なる場合があります。