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

スポンサーサイト

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

Dive into NoSQL

                
tags: NoSQL
 データベースのデファクトスタンダードはおそらくMySQLだろう。ほかに同様のPostgreやSQLiteなどのリレーショナルデータベース(RDB)があって、近年になってNoSQLというその他のデータベースが勃興してきた。
 ぼくが初めてまともにデータベースを触ったのはGoogleAppEngineでのことで、これはNoSQLだった。のちにRDBと比べてみて機能が絞られていることを知ったが、使っていて困ることもそれほどなかった。

 これまでにNoSQLデータベースで有名なMongoDBとCassandraをこのブログで扱い、NoSQLとはどんなものかと学んでみた(Neo4jもいじってみようとドキュメントを読んだが、良いサンプルがすぐには浮かばずにサスペンドしている)。その前後でいろいろなところのいろいろな文書を読んでいて、NoSQLを理解するために抑えておくべき点でボチボチ具体化してきたところがあるので今一度「NoSQLとはなんぞ?」ということをまとめてみる。


なぜNoSQLを選ぶのか
 データベースのデファクトスタンダードはおそらくRDB。RDBにはCRUDとまとめて呼ばれるような基本的機能から、データを結合したり集計を出したりと機能がリッチにそろっている。だから業務システムに使われたり、Webアプリにも使われたりと幅広い。
 Webアプリでも一般的なブログを考えてみる。基本機能のCRUDは欲しい。結合や集計はなくても作れる。ブログがヒットしてアクセスが増えた場合にはパフォーマンスが欲しくなる。そんなわけでなんらかRDBにあった機能を絞り、代わりに秒間何アクセスに対応させるようなパフォーマンスが欲しい。そんな要求に対応するために出てきたのが一般的なNoSQL。
 NoSQLはAmazonからDynamo、FacebookからCassandra、GoogleからBigTableが出たようにこぞってWeb界隈の企業から出てきた。つまり主としてWeb界隈で価値を見出されるものであって、その他の領域では必要性が薄いこともある。あくまでデータベースの選択肢の一つであって、どこでもRDBに丸々取って代われるとかってことはない。主としてパフォーマンスを要求されるWeb界隈では価値を見出されているというところ。

NoSQLの分類
 NoSQLはNot Only SQLの略だと言われる。この一文がNoSQLと呼ばれるデータベースの特徴をよく暗示している。SQLを実装したRDBだけがデータベースじゃないよ、とはうまく言ったもので、NoSQLにはいろいろなタイプがある。
 一番シンプルなのはキーバリューストアと呼ばれるもので、ある値に一つのキーを紐づけて呼び出せるようにしたものだ。プログラミング言語によっては実装されている辞書型のようなもの。これは値による条件検索などを備えてないので、なにかデータを永続化させたいだけのときのようなシンプルなデータストアが必要な場合に使われる。ごくシンプルなので読み込みや書き込みのパフォーマンスは高い。
 NoSQLでも比較的に名が知れているCassandraはキーバリューストアとされることもあるが、もっと注視される特徴を持っている。その特徴を持つものをカラム(列)指向型と呼ぶ。これはRDBのようにテーブルや行、列(のようなもの)があり、シンプルなキーバリューストアよりずっとRDBライクに使える。ただしデータの保存のされかたとしてRDBではレコードが一件ごとに連続で保存されるのに対し、カラム指向では異なるレコードの列データが連続で保存される。これが列に着目したデータ操作の時のパフォーマンスの優位性を生む。たとえばあるテーブルのある列の値の平均を出したいときとか。反対に列に着目したデータ操作をしないなら、優位性は薄い。Twitterでこれに全面的に移行するという話が持ち上がったが、現在は部分的な使用に落ち着いた。
 データがなんらかのドキュメント形式(JSONやXMLなど)で扱われるデータベースはドキュメントストアと呼ばれる。とくにJSONとよく似たBSONを採用しているMongoDBは扱いやすので人気が高く、調査によってはiOSやAndroid以上に開発スキルとして雇用の際に望まれたという結果もある。なにが扱いやすいかというと、JSONライクなデータを扱うためにSQLでなくJavaScriptをベースにした書き方でデータベースへの問い合わせ(CRUDやデータの検索など)を行える点である。もちろんJavaScript以外にもさまざまな言語で扱えるようにドライバがそれぞれで用意されていて、とくに難しいこともない。たとえばPythonから著者がカミュの本をデータベースから探したい場合、ドライバを使ってdb.books.find({"author":"Camus"}) と書くだけである。もちろん条件追加や並び替えもできる。
 その他特徴的なものではNeo4jが著名なグラフデータベースもある。NoSQLではとくにここまで挙げたものが著名だが、他にもいくつかある。

スキーマレスという特徴
 RDBではテーブル内のレコードは共通の名前の列を持っている、ある面ではエクセルの画面に例えられることがあるように、特段入れるデータがなくてもとりあえず場所は確保しておかなければならない。一つの列に一つの値。
 NoSQLではCassandraやMongoDBでスキーマレスという特徴がアピールされる。一つのテーブル内でも、レコードごとに共通した名前の列を持つ必要はないということだ。これによって不必要なデータスペースを作らなくて済んだり、柔軟にテーブルを扱えたり。ただぼくが思うにスキーマレスがもたらす開発にとってうれしい点は、列の値としてリストを入れられることだと思う。
 MySQLなど著名なRDBを調べてみたが、一向に列の値としてリストを導入できる兆候やうわさを聞かない。CassandraやMongoDBでは列の値としてリストなどのコレクションをつかえる。これによってRDBでは中間テーブルを用いて実装していた多対多の関係が、中間テーブルを省いて楽に記述できるようになる。たとえばブログでタグを実装したければ、列にリスト化したタグの文字列データを入れるだけで済む。これに対してタグ検索をかけてレコードを引っ張り出すことも簡単にできる。スキーマレスなので一つの列に一つの値でなく複数の値が入ったリストを入れられる。NoSQLではそんなことができるものもある。

NoSQLの弱点はどこか
 NoSQLはRDBのACID特性にあった一貫性の部分をゆるめていたりする。その結果完全なACID特性を保持していないものもあるが、そのあたりはNoSQLでも実際のデータベースそれぞれによってどうなっているか異なる。ドキュメントストアであるRavenDBではWebページトップにでかでかとACIDと書かれているが、同じくドキュメントストアであるMongoDBは少なくとも厳格なACID特性は持ち合わせていない。このあたりは作ろうとしているアプリケーションでデータの整合性が厳格であるべきか否かを考え、よくデータベースのドキュメントを読んで導入可否を検討すべきだろう。たとえばブログを作るならMongoDBでも問題はあまりなかろうが、なにか金に絡むものの記録をするならよろしくないことになるかもしれない。このあたりのACID特性がどうなっているかということは、NoSQLで分類が同じデータベースでも特徴としてそれぞれで異なっている。
 また前述のスキーマレスという特徴はMongoDBで弱点も生んでいる。MongoDBではテーブル内のレコードの列構造が共通である必要はない。それでもどこかで列の名前を管理する必要があるが、MongoDBではそれを一件一件のレコードが管理することになっている。一件のレコードあたりのデータ量がそれによって増加することになり、ビッグデータを扱う場合においてはその総量がパフォーマンスや保存スペースのコストになってくる。利用者の声として、MongoDBを選んで正解ではあったが、列の名前を可読性を犠牲にしてごく短い名前を与えるようにしたというケースがあった。
 Cassandraにも先に書いたように適した使い道があって、それ以外の場合に適しているかというと微妙なところだ。とりあえずMySQLでやろうとしていることをCassandraでやってみるかと言って悲鳴が上がったようなケースがある。そのあたりは簡単なアプリケーションを組んでみるとわかると思うが、端的に言えばRDBほど柔軟に使えるわけではない。たとえば本のデータベースを作って、レコードにタイトル、著者、発売日、価格、評価を列として持たせて、発売日順、価格順、評価順、著者で絞って発売日順、著者で絞って価格順、などのクエリを実行しようとしてみればわかる。あとは価格順のレコードの11件目から20件目を取得とかしようとしてみたり。CassandraにはJOINがないだけではない。このへんでなにかしたければCassandraに頼らずアプリケーション側で処理を書かねばならない。
 NoSQLというのはいろいろな形式のデータストアの集まりで、それぞれがそれぞれの問題に対処するために設計された。だから弱点はなにかっていって共通のものを探すのは難しい。ドキュメントを読みながら、実際の使い方と同じことをするサンプルアプリケーションを作ってみるのが確実な選定方法。TwitterがメインデータストアをCassandraにする計画を発表しながらも、結局部分的な使用に落ち着いているのは覚えておきたい。

黎明期を超えたあとで
 もうNoSQLのデータベースは実験段階を超えて実際に使われている。RDBより優れた点をもって出てきたので(もちろん劣った点も持っているが)、その優れた点がRDBに吸収されていたり(MySQLにMemcachedプラグインが加わった)、NoSQLでもRDBに近づいたりと(ACID特性を持ったRavenDBや、SQLライクなクエリを導入したCassandraなど)、既存のRDBとNoSQLは双方を見習っていいところを取り込む改良が施されている。長いスパンで見れば、差異が埋まっていくことが考えられる。
            

コメントの投稿

非公開コメント

プロフィール

hMatoba

Author:hMatoba
Github

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

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