NoSQLの話
久しぶりに仕事に関わるような内容を書こうと思ったEPLUのタキヤマです。
とりあえずDBの関連の記事を書くつもりではいましたが、
前回予告していた通り、チューニングを実践するには、準備時間が足りないので･･･
今回は最近話題の big data や Deep Leaning でも使われるこちらに軽く触れようと思います。
NoSQL
まずNoSQLとはなんでしょう？ということになりますが、これはデータベースの製品名ではなく、データ表現の分類の一種となります。
DBを扱ったことがある方にとっては、DBといえば
RDBMS(リレーショナルデータベースマネジメントシステム)
のようなところもあるかもしれませんが、これとは別形式のDBということになります。
イメージとしては図のようになります。
枠で囲っているのが分類、中に書かれているのが製品名になります。
※製品やNoSQLの分類は一部代表的なもののみを記載しています。
RDBMS
これは前出の通り、列と行からなる表と表内のデータ間を関連付けるおなじみのものかと思うので、今回は特に触れません。よくあるこういうやつですね。
RDBMSとNoSQLの違いについて
主な違いに以下のようなものがあります。
◆スキーマレス
RDBMSはデータを格納する前にスキーマを定義する必要がありますが、NoSQLはスキーマ定義なしでデータを格納することができる。
これにより、構造の変更等が容易になる。
※スキーマ定義が必須の製品もあります
◆リレーションがない
リレーションによる結合が速度やスケーラビリティに悪影響を与えるため、
速度やスケーラビリティに重点を置いているNoSQLでは基本的にはリレーションを持たない。
◆トランザクションをサポートしない
NoSQLの大半は、トランザクションをサポートしていない。
常に整合性を保つ(参照整合性/一貫性)RDBMSと違い、最終的に整合性が保たれれば良い(結果整合性)という考えで、
アプリケーション側で整合性を維持する必要がある。
◆スケールアウトが容易
NoSQLではデータ構造が単純であることが多いため、スケールアウトが容易になる。
大量のデータを複数のサーバーで分散して高速に処理することが可能。
NoSQLの形式
代表的なものとして以下のようなものがあります。
KeyValueStore
・KeyとValueを組み合わせる単純な構造からなるデータストア
・Keyを指定して読み取り/削除
・Valueにはリスト等で複数の値を持つことも出来る
・高速な読み書きが出来るが、複雑な検索には向かない
最近流行の Deep Learning フレームワーク の1つである「Caffe」でもこの KVS 形式のNoSQLが利用されています。
製品としては LevelDB または LMDB のどちらかを選択することになります。
Caffeでは"画像のLabel"とその"画像のpath"をkey-valueとしてもつDBを用意してからそれらのデータを扱います。
それぞれの特徴は以下のようになります。
◆LevelDB
・アクセス頻度の高いデータ毎で階層的に分けおり、アクセス効率が良い
・一つのプロセスからアクセスされると他のプロセスからはアクセスできないロックがかかるため、複数プロセスを同時に実行するような利用には向かない
◆LMDB
・LevelDBと近い構造をしているが、アクセスロックがかからないため、複数プロセスで同じデータセットを使用できる
・mdb_statコマンドでDBの詳細情報を見ることができる
ColumnStore
・Row(行)単位で処理を行うRDBMSに対して、Column(列)単位で処理をする
・行を取り出すのではなく、列を取り出す形
・列単位でまとまった処理があるシステムでは、RDBMSよりも高速に処理できる
・列単位で集計する処理が多い情報分析システムなどで活用される
・ビッグデータ分析用のミドルウェアと併用されることが多い
DocumentStore
・RDBMSではスキーマ定義が複雑になりがちな、JSONやXMLなどのドキュメントをシンプルに格納することができる
・作成時にドキュメント全体を格納し、読み取り／更新／削除をドキュメントの一部もしくは全体に対して行うことができる
GraphDatabase
・グラフ理論を基に、相互に結びついた要素で構成される
・それぞれの間に任意の数の結びつきのあるデータ同士の関係をグラフとして表すのが適切なデータを対象とする
・Facebook等のSNSのユーザー同士の繋がり等、ネットワーク状のデータを格納するのに適している
・データ間の関連(リレーション)に重点を置いているため、RDBMSとは異なるもののNoSQLとしては特殊な立ち位置
ここまでNoSQLについて紹介してきましたが、NoSQLが全てにおいてRDBMSに勝っている訳ではなく、置き換えられるようなものではありません。
高速な処理や、DeepLeaningのような分析、構造が変化する柔軟なデータを扱うような場合にはNoSQLが向いていますし、データ形式の定義や、トランザクションによるデータの一貫性が重要になってくる業務アプリ等にはRDBMSの方が向いています。
最近ではPostgreSQLやMySQLがスキーマレスなJSON格納に対応する等、RDBMSが非リレーショナルなデータを扱えるようになるケースや
Oracle NoSQLのようなOracleDatabaseと連携してSQLでNoSQLのデータに透過的にアクセスできるようになるケースもあり
SQL準拠のインターフェースを持ちながらも、非リレーショナルなデータも格納できる製品が登場していたりします。
NoSQLの影響もあり、RDBMSも新しい進化をしている最中ですが、それぞれに得意不得意があるので、特徴を生かした製品選びが大切ですね。
