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

スポンサーサイト

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

MySQLのデータ型にJSON型が加わっていた

                
tags: MySQL
 RSSに入ってくるソフトウェアの更新情報を追っていたらMySQLがデータ型にいつの間にやらJSON型を追加していた。SQLもNoSQLの特徴を取り入れて双方は近づいていくという話どおりのことであるが、ちと試しておく。

 JSON型とはいわゆるJSONドキュメントのことだが、つまりはスキーマレスなデータ型を保存できるというのが大きな特徴。従来のリレーショナルデータベースではサイズが不定になるようなデータは型として基本的になかった、MySQLにはENUMやSETがあったがまあ例外。 JSON型ということは配列だけでなく辞書型のようなものまでデータとして使えるということになる。

 Ubuntu14.04を動かして試してみた。まだデフォルトのリポジトリには最新版が来てなかったので、下記を参考にインストールした。
http://www.devopsservice.com/installation-of-mysql-server-5-7-on-ubuntu-14-04/

 基本的なことはドキュメント参照。
http://dev.mysql.com/doc/refman/5.7/en/json.html
 とりあえず適当なテーブルを作ってみる。テーブルにはフルーツや野菜などの作物を登録することにする。カラムとしてnameに作物の名前を、tagというカラムにJSON型で適当に特徴を記録する。
CREATE TABLE foo (
tag JSON,
name nchar(30)
);


INSERT INTO foo VALUES('["red", "vegetable"]', 'tomato');
INSERT INTO foo VALUES('["green", "vegetable", "long"]', 'cucumber');
INSERT INTO foo VALUES('["yellow", "fruit", "long"]', 'banana');
INSERT INTO foo VALUES('["red", "fruit", "small"]', 'strawberry');
INSERT INTO foo VALUES('["orange", "fruit"]', 'orange');
INSERT INTO foo VALUES('["omg"]', 'durian');


 フルーツを選ぶ。
SELECT * FROM foo WHERE JSON_CONTAINS(tag, '"fruit"');
1510212014248.jpg

 赤いものを選ぶ。
SELECT * FROM foo WHERE JSON_CONTAINS(tag, '"red"');
1510212014505.jpg

 複数条件にしたければ下記のようなクエリも。
SELECT * FROM foo WHERE JSON_CONTAINS(tag, '["red", "small"]');
 赤くない作物とかも。
SELECT * FROM foo WHERE NOT JSON_CONTAINS(tag, '"red"');

 JSON型を導入することで一対多、多対多の導入が中間テーブルなしでできるようになったりする。便利で有効な使い方を考えていきたい。
スポンサーサイト

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は双方を見習っていいところを取り込む改良が施されている。長いスパンで見れば、差異が埋まっていくことが考えられる。

MongoDB: インジェクションを考える

                
 データベースを扱う上で付いて回るのがインジェクションというセキュリティの問題である。データベースにあるデータ(些末なものからIDやパスワードまで)を見境なくぶっこぬかれたり、認証に使っている場合は認証を偽装されたりと対策をしない理由はない。MongoDBを使う場合、どういうことを気にすればいいかを@ITの記事を参考に検証する。このブログではPythonを主に扱っているので、PyMongoでMongoDBへ接続するときの諸々を検証する。


 まず前提としてアプリケーションでデータベースを使いたければ、信頼できるところが作っているドライバを使うこと。PythonとMongoDBの組み合わせならPyMongoがある。MongoDBはJavaScriptを書くことでデータの挿入、更新、削除などができる。PyMongoはこれをPythonでできるようにするものだが、基本的な部分ではJavaScriptとPythonの文法の差は現れない。JavaScriptで書いていたものをほぼそのままPythonで書くだけで使える。

 下準備としてMongoDBを立ち上げ、PyMongoを使って接続する。インジェクションで認証偽装を試みるので、sessionコレクションに、インジェクションが成功したらドキュメントが得られるように一件挿入しておく。
import pymongo

db = pymongo.MongoClient("localhost", 27017).test_db
if not db.session.find_one():
db.session.insert({"session":"session_id_str"})


とりあえず下記のコードを実行してみる。sessionコレクションから、sessionキーが文字列”x”のドキュメントを探し、件数を返す命令だ。
print db.session.find({"session":"x"}).count()

sessionキーが文字列”x”のドキュメントはないから、インタープリタには0が表示される。この条件では該当ドキュメントがsessionコレクションにはないから、認証はとおらないということ。で、正規の方法で認証をとおしたければ正規のキーを入れればいい。
print db.session.find({"session":"session_id_str"}).count()


1.演算子のインジェクション
参考:http://www.atmarkit.co.jp/ait/articles/1305/23/news004.html
PHPなどの言語には、配列/連想配列と解釈できる形式で書かれたリクエストパラメータを、プログラム内で配列/連想配列に展開する機能があります
Pythonの基本機能にはそんなことをするものはない。なのでそういう機能を暗黙のうちに提供する可能性があるのはフレームワークのほうなので、フレームワークがクライアントからPOSTされたりしたパラメータを暗黙のうちに文字列から辞書型などに変換して返すような仕様がないか確認しておく。例えばwebapp2の場合、以下のように書いておけばOK.
s_id = self.request.get("s_id")
db.session.find({"session":s_id})



2.クライアントから送られたJSONをそのまま辞書型にして使うのは避ける
 問題ない使いかた。データベースから文字列”session_id_xxx”に一致するセッションIDを持つドキュメントを探す。
s_id = "x"
print db.session.find({"session":s_id}).count()

 json.loadsを使えば、JSON形式で書かれた文字列から辞書型を作れる。使いかたによっては手っ取り早くなる。
json_str = """{"session":"x"}""" # クライアントからJSON形式で左記のデータが送られてきたとする
obj = json.loads(json_str)
print db.session.find(obj).count()

 だけど上記のように書くのはまずい。悪用されると、ドキュメント検索の条件を様々に変えることができるようになり、インジェクションのきっかけに。下記では非等価を示す演算子を使って、文字列”x”に一致しないセッションIDを持つドキュメントを検索するようになる。
injection_json = """{"session":{"$ne":"x"}}"""
obj = json.loads(injection_json)
print db.session.find(obj).count()

場合によっては変数部分はどの型が来るか管理する。クライアントから送られたJSONを辞書型に変換してそのまま使わない。
obj = json.loads(injection_json)
isinstance(obj["session"], str)
db.session.find({"session":obj["session"]})



3.サーバサイドでJavaScriptを使わないようにする
参考:http://www.atmarkit.co.jp/ait/articles/1305/23/news004_2.html
 MongoDBではJavaScriptが使える。PyMongoから使う場合でも、JavaScriptコードを埋め込むことができる。だがそれは任意のコードを埋め込むチャンスになるので使用を避ける。たとえば参考記事ではパラメータを大文字化して部分一致検索をかけているが、それはPyMongoでJavaScriptを埋め込まなくても可能。
foo = {"$regex":"foo".upper()}
print db.session.find({"foo":foo}).count()

 JavaScriptの実行を不許可にしておくのも手。
http://docs.mongodb.org/manual/reference/configuration-options/#security.javascriptEnabled



 SQLでは文の構成に文字列置換を使って問題になることがある。開発者が書いた文を手玉にとりつつ、勝手なSQL文を書かせてしまうなど。
SELECT * FROM users WHERE name = '(入力値)';

SELECT * FROM users WHERE name = 't' OR 't' = 't';
上記はWikipediaから部分的に抜粋した。
 PyMongoを使って適切に書けば上記のようなことは起こりづらい。
db.users.find({"name":input_value})
ただやっぱり油断していると付け入るところはあるようで、evalやexecはそもそも使わないものとして、json.loadsもちょっと使用を差し控えたほうが無難だと考えられる。使いたければ型チェックなどの厳重に設計されたバリデーションを経ること。あとデフォルトではJavaScriptが動くようになっているので、それは切ってしまうのが手っ取り早い。

MongoDB: TTLをPymongoやMotorで使う上で

                
tags: mongoDB
 MongoDBの各ドキュメントにはいわゆる寿命と呼べるTTL(Time To Live)を設定できる。これは任意の時間を指定するもので、その時間が経過するとドキュメントは自動で削除される。MongoDBのJavaScriptコマンドラインから使うにはまず以下のようにインデクスを作る。
db.foo.ensureIndex({createdAt:1}, {expireAfterSeconds:15})


 続いてTTLを設定したいドキュメントに"createdAt"キーで現在時刻を入れる(上でcreatedAtキーでインデクスを作っているので)。"createdAt"キーを入れなければ、TTLは設定されない。
db.foo.insert({createdAt:new Date(), foo:"foo"})


 で、expireAfterSecondsで指定時間したが経過すればドキュメントは自動で消える。
 この機能はcreatedAtに入れられた時間とコンピュータの時計から時間差を出して、それが指定時間を超えるなら削除するようになっている。経過時間をカウントするタイマーのようになっているわけではない。他言語からドライバを使ってTTLを指定する場合、そこらを留意しなければならない。Pythonでもう一度これまでの手順を踏んでみる。ドライバはPymongoを使って適当に。

 まずインデクスを作る。
db.session.ensure_index("createdAt", expireAfterSeconds = 15)


 続いてドキュメントをインサート。
#db.foo.insert({"createdAt":datetime.datetime.now(), "foo":"foo"})
db.foo.insert({"createdAt":datetime.datetime.utcnow(), "foo":"foo"}) # Use UTC TIME!

 上のインサートはまずくて下のインサートはOK。上だとTTLが狙いどおりに働かない。コンピュータの時間とcreatedAtキーに入れられた時間を比較して消去の判断がされると書いた。んでMongoDB側は時差を抜いた標準時を使う。pythonのdatetimeオブジェクトのnowメソッドは時差ありの現地時間を返す。なのでnowメソッドでなくutcnowメソッドで標準時にそろえておかなければならない。

 というわけでMongoDBにドライバを使って他言語から使う場合、TTLのためには標準時で時間を提供しなければならないということ。ちなみにMotorでもPymongoとほぼ同じように使える。

http://api.mongodb.org/python/current/api/pymongo/collection.html#pymongo.collection.Collection.ensure_index

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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。