NoSQLとは?~大量データに対応したデータベースたち~
どうもkoheiです。
スマブラが楽しみです。
今日は前回に引き続きデータベースの話を
前回は構造化されたデータを扱うリレーショナルデータベース(RDB)について、書きましたが、今回は非構造なデータを扱うNoSQLについて触れたいと思います。
データベースって?リレーショナルデータベースとは?という方はこちら
NoSQLの誕生
前回のおさらいになりますが、表形式になる構造化データに対しては、RDBMSを利用することで、データの検索は管理が容易になります。
一方、世の中の多くのデータが表形式にはなりません。
頑張って表形式に合わせようとしても、なかなか構造的にうまくいかないものが出てきます。
昨今の爆発的なデータ増に対して、こうした大量で、非構造なデータを高速に、かつ容易に扱えるかが課題になっています。
そこで登場したのがNotOnlySQL(NoSQL)です。
NoSQLの仕組みと種類
wikipediaでNoSQLを見てみます。
NoSQL(一般に "Not only SQL" と解釈される)とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。
ここで触れられている通り、NoSQLというのは「これまでのRDBMSで使ってきたものとは違う方式でデータを管理するもの」を指す言葉です。
この曖昧な定義のため、NoSQLデータベースには様々な種類があり、それぞれ方式もバラバラです。よくあるタイプとしては下記の3点があげられます。
1. Key-Value型
NoSQLの考え方で最も使われているのがこのKey-Value型です。
文字通りKey- valueの組み合わせでデータを管理します。
シンプルなつくりなので高速なデータ読み書きが期待されます。
また、複数のサーバでデータを分散して配置して置いても、Key情報をどのサーバが持っているかを管理出来れば、Valueを探索できます。つまり、スケールアウト(複数台のサーバに情報持たせて処理を分散させる)ことが容易です。
一つのKeyに対して、複数のvalueを持たせるKey-Value型もあり、カラム指向型と呼ばれることもあるそうです。
Key-Value型NoSQLの例:
Redis
2009年にイタリアのSalvatore Sanfilippo氏が開発しオープンソースソフトウェア(OSS)として公開。Key-Value型でデータを管理し、データをメモリ上で保持するためデータの読み書き性能が非常に高い。
AWSで提供しているKey Value型のNoSQL。Key-value型のシンプルな構成を活かした、高速なデータ読み書きと、データ容量に応じたスケールアウトが特徴。
複数ノードにデータをコピーして保持するため、単一障害点(ここが故障すると全体に影響を及ぼすポイント)がない。
Apache HBase
HadoopのHDFS上に構築するOSSのNoSQLデータベース。
Googleの大規模分散処理基盤「BigTable」を基にしている。maserサーバでデータがどう保存されているかを管理し、Regionサーバでデータを保持するので、Regionを増やせば簡単にスケールアウト可能。
Hadoopってなに?という方はこちらも参考に
2. ドキュメント指向型
データをドキュメント(主にjson形式)で保持し、管理します。ドキュメントという塊でデータを管理するので、各データ項目を定義しなくてもいいのが特徴です。
ドキュメント指向型NoSQLの例:
mongoDB
mongoは「hu"mongo"us」が由来らしい。OSSのNoSQLでは圧倒的なマーケットシェアを誇る。RDBMSのようなデータ検索クエリが使えて、豊富な言語サポートが特徴。
3. グラフ型
データそのものより、データ間の関係に注力しているのがグラフ型です。RDBMSでは大規模で複雑なデータ群に対する探索、集計は不得意ですが、グラフ型ではそうしたデータに対する検索機能などで効果を発揮します。
グラフ型NoSQLの例:
neo4j
洗練されたUIでSQLライクな言語(Cypher)でデータ処理機能を利用できる。
まとめ
NoSQLデータベースについてまとめてみました。
今日取り上げたものの中にも、様々なデータベースソフトが誕生しており、今回あげたジャンルだけには収まらないものも多数あります。
いずれもデータの急増に伴い、大量のデータを、素早く、柔軟に取り扱いたい、という要望から生まれています。
しかし、これらのニーズを一つの方法ですべて網羅はできないので、それぞれ得意分野を持った特殊なソフトがNoSQLとして出てきているように感じます。
このため、何でもかんでもNoSQL最高!と思って使うのは危険です。
(NoSQL導入して失敗した記事もよく見ます。)
使いどころを誤ると、本来の性能が発揮できなくなるなど、使いどころの見極めが大事になります。その製品の特長が何で、どこで使うのがよいのかを考えながら、NoSQLに触れていきたいですね。
ではでは