主にプログラミングに関して。Python, .NET Framework(C#), JavaScript, その他いくらか。
記事にあるサンプルやコードは要検証。使用に際しては責任を負いかねます

スポンサーサイト

                
tags:
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

NoSQLってなんなのさ、どうなのさ

                
 とくにWeb界隈で新たなデータストアとして出てきたNoSQLデータベース。これどう使えるの?って思ったので著名なもののなかからSQLiteやMySQLの代わりになりそうなものを見つくろっていじってみた。
Apache Cassandra
MongoDB
ここらへんでNoSQLについて包括的に言えることをまとめる。

 大筋として二つ。NoSQLとはSQLに完全に置き換われるものではない。NoSQLと言って具体的に一括りにできるものはないということ。
 NoSQLは「No SQL」ではなくて「Not only SQL」であって、データストアの選択肢はリレーショナルデータベースだけではないということを示している。言いかたを変えればリレーショナルデータベースも十分あり得る選択肢で、それらは目的次第で使い分けられるデータストアだということだ。
 よくNoSQLと一口に言われるが、これはSQLと違ってデータベースの設計や機能を一括りにできる言葉ではない。SQLがリレーショナルデータベースへ問い合わせをする言語が規格化されたもので、SQLで問い合わせを行えるデータベースは基本部分が似通ったものだ。一方でNoSQLはSQLをサポートしていないこと以外の具体的な共通点がない。オライリーから出ている『Cassandra』ではNoSQLという言葉について以下のように書かれていた。
"「NoSQL」データベースはどれ1つとして、同じ実装、目標、特徴、利点、欠点を持っていません。「NoSQL」と「リレーショナル」を比較するのは無意味なことです"


 具体的なNoSQLと呼ばれるデータストアを探ると、まったく目的の異なるいくつかの分類に出くわす。リレーショナルデータベースではパフォーマンスが限界に達していて代替として新たなデータストアを探すなら、そのNoSQLのいくつかの分類がどのようになっていて、どの分類が現在使っているデータベースの代替手段として使えるのかを考えねばならない。その分類に関して上に出てきた『Cassandra』とリックテレコムの『NOSQLの基礎知識』を見ながらちょっとまとめる。




オブジェクトデータベース
 オブジェクト指向言語にあるオブジェクトの形式でデータを保存する。利点としてORマッパーの使用を避けられるし、プログラムとデータのあいだでもデータの型が一致しているのでパフォーマンスが優れる。しかし保存データが特定の言語でしか扱えないという制限を設けることになってしまう。


XMLデータベース
 データ形式がXMLで扱われるようになっている。これによってフルテキスト検索が速いという利点があるし、そもそもXMLならば特定のプログラミング言語に依存することもない。データ操作のAPIが複数ある。これによってSQLという単一のクエリメカニズムに縛られないとされている。無理に欠点を挙げるなら、データ操作のAPIが複数あるってどうなんだろうというところ。


ドキュメント指向データベース
 ドキュメントってなにを指すかといえば、たとえばXMLがあるしJSONもそう。データベースによってどのドキュメント形式を使うかは違う。ただそういうドキュメントを使ってレコードにあたるものを表現してデータとして扱う。とくにポピュラーなMongoDBについて言うならデータがJSONであるからそう難しいものではない。JavaScriptではオブジェクト、PythonやC#では辞書型と基本的な書き方は変わらない。herokuのアドオンとしてMongoDB系が3つもあることを考えると、MongoDBはWebに特に親和性が高いのかもしれない。


キーバリューストア
 保存したい一つのデータに一つのキーを与えてキーバリューのペアを作って保存。キーを使ってデータ呼び出し。一つの巨大な辞書(ハッシュテーブル)を扱うようなもので、クエリでフィルタだのオーダーだのってやりたいのに使うものではない。


カラム(列)指向データベース
 この言葉はちと難しい。『Cassandra』では"カラムナ(または「カラム指向」)データベースは"というようにカラムナの言い換えがカラム指向となっている。一方で『NOSQLの基礎知識』ではカラムナ≠カラム指向となっている。
 とりあえず『Cassandra』ではカラム指向もカラムナも等しくデータが列によってグルーピングされるもので、列の大規模な集計処理に適しているとされている(P302)。またCassandra自体について「各行はまったく同じ列を持つ必要がないからカラム指向またはカラムナと呼ぶのは間違いではない(P24)」と説明している文を読むと、リレーショナルデータベースと違い、同一テーブル内の行が持つ列が一貫している必要はないことが特徴のように書かれている。
 『NOSQLの基礎知識』ではカラム指向の意味をリレーショナルデータベースと違って、同一テーブル内の行が持つ列が一貫している必要はないことのみに絞っている。カラムナについては列対象の集計が速いもので、『Cassandra』で説明されている列グルーピングによって与えられる特徴のことが書いてある。
 同一テーブル内の行が持つ列が一貫している必要がないという特徴を「スパース」、あるいは「スキーマフリー」と呼ぶ。
 まとめるとたぶん下記のように。
『Cassandra』 カラム指向=カラムナ:スパース、列データの集計処理向き
『NOSQLの基礎知識』 カラム指向:スパース; カラムナ:列データの集計処理向き

 なんだか気持ち悪いので「Column Oriented」について英語のWikipediaと論文に軽くあたってみた。まずWikipediaの概略部分では行ベースでなく列ベースでデータを保存することで、列の値を使う処理のパフォーマンスが上がることを述べ、スパースについては概略に入ってないものの一つの特徴として書かれている。またカラム指向のベースになったであろう論文『C-Store: A Column-oriented DBMS』ではアブストラクトでこれまでデータベースって行ベースだったけど、列処理したいなら列ベースでデータ並べてみたらどうかって考えが書かれている。
 手元には先に挙げた二冊以外に日本語書籍がないので参考になりそうなWeb媒体を探したところ、Gihyoに記事があり、そこでも「列指向は列単位でデータを書き込むので、列単位でのデータの読み込みが得意(参考)」と書かれていたので、カラム指向がスパース性のみを示すとは考えられない。
 以上からカラム指向データベースという単語を考えると、膨大な列処理のパフォーマンスを高めるために列ベースでデータを並べるデータストアだと言える。そしてパフォーマンス向上の手段としてスパース性も持っている。



 Paasとして有名なGoogleAppEngineではとくに何とも命名されていないデータストアが使えるが、これはNoSQLである。しかも近年になってMemcachedとブロブストアも追加されており、初めから使えたデータストアと組み合わせて使えるようになっている。無名のデータストアでリレーショナルデータベースの代替としてフィルタやオーダーの必要なデータの読み書き。Memcachedで永続させる必要のないデータのキーバリューでの読み書き。ブロブストアで画像や音楽など容量の大きいデータのキーバリューでの読み書き。これらを目的にそって組み合わせて使えるようになっている。この3つはすべてNoSQLという括りには入れられるが違う目的で使われている。NoSQLというのはなにかを最適化したいときに使い、場合によってはほかのデータストアと組み合わせて使う必要がある。そのぐらいに個々のNoSQLデータベースは異なるものになっている。
            

コメントの投稿

非公開コメント

プロフィール

hMatoba

Author:hMatoba
Github

最新記事
リンク
作ったものなど
月別アーカイブ
カテゴリ
タグリスト

検索フォーム
Amazon
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。