NOSQLについてざっと

はじめに　

このレポートではビッグデータを処理するために用いられているクラウドコンピューティングを支えるための、リアルタイムで逐次処理するためのデータベースの技術であるNOSQLについて簡潔にまとめる。

　ここではNOSQLだけを扱い、ビッグデータやクラウドコンピューティングに関する詳細は述べない(クラウドコンピューティングに関してはこのページを参照)。NOSQLの大まかなアーキテクチャを掲載するに留める。

　

NOSQL誕生の背景

膨大なデータを迅速に処理する技術ではスーパーコンピュータの京などが挙げられるが、商用利用を考えると開発コストが大きくかかりすぎてしまう。そのために汎用のコンピュータを何百台、何千台と並べ、それによってコストを下げつつビッグデータを処理するための技術に関心が集まっていた。

Google社のBigtableとAmazon社のDynamoの論文発表を皮切りに、ソフトウェアによる大規模分散技術は脚光を浴び、この2つを参考にしたNOSQLのソフトウェアの開発が世界中で始まった。

　NOSQLは従来のSQLを否定したわけではなく、むしろNotOnlySQLという意味で付けられた。NOSQLは今まで伝統的に用いられてきたSQLやRDBMSがビッグデータ処理に対応できなくなったことが原因である。

NOSQLが求められた背景

　ビッグデータに対処するにはVolume,Velocity,Varietyに対応することが必要となる。TwitterやFacebookなどの大規模ウェブサービスを例に上げるとわかりやすいが、ビッグデータに対応するシステムを作るには、秒単位で来る世界中からのチリも積もれば山となったビッグデータの塊をリアルタイムで素早く処理する必要が有ることと、データ同士の構造が複雑化やデータの形自体が多種多様であることに対応しなくてはいけない。まとめると「膨大で多種多様であり激しく変化するデータの塊を制限なしに保存しつつ、迅速に処理すること」である。

　従来のSQLやRDBMSではビッグデータ処理に対する処理能力は必要を満たしてはいなく、RDBMSでは複雑で多種多様なデータ構造に対応ができないために、それにとって変わる新しいシステムが求められた。

NOSQLはどのように利用されるか

　NOSQLは利用目的を絞り込んだデータベースであり、機能は「書き込み(Put)」と「読み込み(Get)」のみの動作しか行えないため、RDBMSの機能である「結合(Join)」などの演算子は利用することができなくなっている。また、RDBMSの機能である排他制御は厳密に実行されるが、NOSQLではその仕組を緩めている。速さを優先するため整合性を緩くしたことで、最終的な結果の時点で整合性がとれていればいいという結果整合性を採用している。

　また、ビッグデータのアプリケーションでは「読み出し」と「書き込み」の2つだけのシンプルな操作で充分であり、複雑な操作が必要とされていない。さらにVelocityを追求のためにRDBに求められていた正規化などの手順を省き、NOSQLではデータを構造化させていないため熟練のエンジニアの技が不要となる。

　これまでのRDB技術では十分な性能の欠如と高価なコストの問題、拡張性や柔軟性を満たしていないためにNOSQL採用が検討の必要性が出てきたが、当然のことながらNOSQLだけで複数のデータを組み合わせて複雑な分析を行うためのシステムを作り上げるのは不可能である。RDBの豊富な機能が必要とされるために、twitterやFacebookではNOSQLだけでなくRDBであるMySQLも利用されている。

NOSQLのデータモデル

• キー・バリュー型

図 1

キー・バリュー型では写真や動画などのバリューに対して識別番号としての役割でキーが一つ一つに付与される。新しいデータが追加されるごとに行が加えられていく。キーに対してのバリューの数が固定である。多くのNOSQLデータベースではキーはString又はバイト配列であり、バリューはバイナリーデータでありBLOB(Binary Large Object:ブロブ)と呼ばれる。

　拡張性の高いスケールアウトに最適であり、キーを指定するだけでバリューを探し出せるので複数のサーバにデータを用意に分割することが可能となる。

• カラム指向型

図 2

キー・バリュー型を少しだけ複雑にしたもので、GoogleのBigtableなどに使われている。キーに対してのバリューの数が固定ではなく動的に追加が可能なデータモデルである。多種多様で変化するデータ構造に柔軟に対応することに焦点を当てている。

• ドキュメント指向型

図3

JSONやXMLといったデータ記述書式で記述されたドキュメントを管理する。各ドキュメントは階層構造を持たずに相互の関係は横並びとなっている。データベースとアプリケーションからはドキュメントのいくつかの内部構造が分かるようになっているため、タグを加えたり日時を指定してドキュメントを取得するなどのクエリが利用することができる。

• グラフ型データモデル

図4

グラフ型はデータ間の繋がりを管理できるデータモデルであり、個々のデータが持つ属性に依存すること無く、「繋がり方」だけを独立した形で保持することができる。RDBとは異なりデータは固定的な関係ではなく、他のデータとの関係を持つことができる。関係性を重視しているためにグラフ化に最適化されている。

NOSQLの種類

　Eric BrewerのCAP定理において(CAP定理についての説明は省略)、3つのうち最大２つを選ぶ^*1ことでNOSQLの仕様は大きく変化する。そのためにNOSQLのデータベースの分類はCA型、CP型、AP型の3種類に分けられる。

　それぞれに短所長所があるために、これを使えば万全！というものはNOSQLにおいては存在しない。

まとめ・感想

　NOSQLは大まかに分けて3つのタイプが有りさらにデータモデルも分かれてることからそれぞれに得意不得意があり、また従来のSQLやRDBを併用することの可能性もあることから、NOSQLを利用する際には「どのようなシステムを構築し、システムの何を重視するか」を判断をミスっちゃいけなくなる。

　今はNOSQLの黎明期でまだ新しい技術のためホスティング系の会社もまだ導入とかはしていないみたいで、したとしても2,3年後にはコモディティ化しているだろうからホスティング系の会社は何を売りにして商売をやっていくのだろうか？

　まだソフトの数も100を超えてるし、手探りの状態で導入には技術者の皆さん頑張ってください(←いやお前がやるかもしれないじゃんかとセルフツッコミ　(；´Д｀))

参考文献

 本橋信也, 河野達也, 鶴見利章, 太田 洋著（2012)

『NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)』リックテレコム 256pp.  
ISBN-10: 4897978874

---

*1:厳密に言えば3つの内2つだけを選ぶという説明はミスリーディングだったらしく、操作などによって度合いを選べるらしいが、それは後ほどまとめるとする。
http://www.publickey1.jp/blog/13/capcap32.html