NOSQLについて気になったのでちょっとやってみた
はじめに
この記事は、SLP KBIT Advent Calender2016 その2、15日目の記事になります。 今回は、NOSQLってよく聞くけど実際にはどんなものなんだ、ということで実際にどんなものがあって、実際に使ってみようというわけです。 しかし、これを書こうと決めたのが遅かったので簡単な実行確認が限界かもしれません。 まだまだ未熟者なので、何か指摘があると幸いです。
目次
- NOSQLって
- SQLデータベースとNOSQLデータベースの比較
- NOSQLのデータモデル
- キー・バリュー型
- カラム指向型
- ドキュメント指向型
- グラフ型 8.実際に使ってみよう
NOSQLって
NOSQLの言葉自体は1998年にCarlo Strozzi氏が最初に使ったそうです。 リレーショナルデータベース管理システムであるのにもかかわらずSQL構文を使わない独自開発の商品をNOSQLとしたそうです。 NOSQLは、Not Only SQLの略だそうです。 ビックデータに対応するには、SQLだけでなくという新しいデータベース技術を駆使する必要があるという主張が込められているそうです。 ここで、ビックデータに対応するための3Vというものがあります。 膨大な量=Volume、速さ=Velocity、多種多様=Varietyの3つになります。 つまり、膨大な量なデータを容易な構造で速く処理をすることがNOSQLに求められているのでしょう。
SQLデータベースとNOSQLデータベースの比較
- NOSQLの方が機能が豊富でない
NOSQLには、書き込む、読み出すというシンプルな動作をするに過ぎないものです。 関係代名詞の演算子である結合をはじめとする様々な演算子も、通常はサポートをしてないのです。
- NOSQLの方がデータの整合性が緩い
RDBMSでは、データの整合性を保つためにデータの読み書きを制限する排他制御の仕組みを備えています。 NOSQLでは、この考え方を緩めています。 つまり、結果的に整合性が取られていればいいということなのです。 データの整合性は、データが亢進された場合、次に誰がアクセスしても同じ結果が得られることを保証することです。 これを一時的に許容することで速度に重点を置いているというのが基本的なNOSQLの考えになるそうです。
NOSQLのデータモデル
この4つがよく挙げられます。
- キー・バリュー型
- カラム指向型
- ドキュメント指向型
- グラフ型
これについて簡単に見ていきます。
キー・バリュー型
このモデルは、キーとバリューの組み合わせを一塊のデータとして書き込み、キーを指定することで、そのキーに紐づくバリューを呼び出す形式である。 スケールアウトに最適である。 またデータ分割をする際に、RDBMSでは、サーバ間での関係がある。 しかし、この型では関係がありません。 キーを分割したりするのでサーバには複製したものを置いておく方法をとる。
カラム指向型
これは、キー・バリュー型を拡張したもので、行とカラムの概念を持たせたデータモデルである。 予め列が定義されているわけではなく、複数のキー・バリューを行キーという識別子でグループ化したものである。 他の特徴でひとつの行キーに複数のカラムを持つことができ、カラムの名前を固定しなくてもいい。 また、行の追加をすることが出来る。
ドキュメント指向型
このデータベースでは、ドキュメントをデータをとして管理することができます。 内容とドキュメントが紐づいている。 また、これはスキーマレスのデータベースである。 データベースとアプリケーションからはドキュメントのいくつかの内部構造が分かるようになっている。
グラフ型
これでは、複雑な関係性を持つデータを速くグラフ型に処理するために最適化されています。 キー・バリューは対になっているが、グラフ型は複数の関係を持っている。 有向グラフのイメージが非常に分かりやすいと思う。
実際に使ってみよう
今回は、キー・バリュー型のNOSQLであるTokyoCabinetをそのラッパーであるTokyoTyrantを使って実際に実行をしてみようと思います。
今回使用した環境は、Vagrantを使って仮想環境でubuntu16.04を起動して実験をしています。
Vagrantで起動して適当なディレクトリを作成してその中にインストールします。
wget http://fallabs.com/tokyocabinet/tokyocabinet-1.4.48.tar.gz
tar xvfz tokyocabinet-1.4.48.tar.gz
cd tokyocabinet-1.4.48
しかしここで問題が発生しました。
./configure
checking zlib.h usability... no
checking zlib.h presence... no
checking for zlib.h... no
configure: error: zlib.h is required
このようにでました。
は?
なんだよこれ、こんなの知らないよ。
分かんないからググって見たところ、zlib.hがないから入れろやコノヤローといわれているそうで、じゃあ入れてみよう。
apt-get install zlib1g-dev
これで入れることができました。
じゃあもう1回してみましょう。
・・・状況が同じだと・・・
騙されました。これが誤情報か…
しかし、他のサイトを読むと何やらこれだけでは足りないらしい。
環境に依存するのかもしれない。
apt-get install libbz2-dev
これでできるらしい。
じゃあ今度こそやってみよう。
上手くいった!!!!
このまま次も以降ということで
make
make install
これでインストール完了しました。
同じ手順でTokyoTyrantもインストールしましょう。
wget http://fallabs.com/tokyotyrant/tokyotyrant-1.1.41.tar.gz
tar xvfz tokyotyrant-1.1.41.tar.gz
cd ../tokyotyrant-1.1.41
./configure
make
sudo make install
準備が出来たのでTokyoTyrantを起動して動作を確認してみよう。
これで実行することができた。
じゃあ実際にtelnetで確認をしてみよう。
これがキー・バリュー型であることが確認できました。
また、キーには文字列しか使えないのでこれであってるはずです。
今度は、Rubyを使って操作をしてみようということで、それ用のAPIを準備します。
wget "http://sourceforge.jp/frs/g_redir.php?m=jaist&f=%2Ftokyocabinet%2Ftokyotyrant-ruby%2F1.5%2Ftokyotyrant-ruby-1.5.tar.gz"
wget http://tokyocabinet.sourceforge.net/rubypkg/tokyocabinet-ruby-1.29.tar.gz
これらをもってきて展開します。
しかし、ここでも問題が発生しました。
ruby extconf.rb
これをするとrubyが無いと怒られたのでインストールをして実行しました。
しかし、実行できませんでした。
はっ?
またかよ・・・。そろそろ疲れたよパト○ッシュ…
どうやらこれは、ruby.hが無いと怒られました。
sudo apt-get install ruby2.1-dev
これを実行したらうまくいくとGoogle先生に言われました。
これでどうやらruby.hが入って実行することが出来ました。
makeコマンドを使用してインストールできたと思う。
これでTokyoCabinetのRubyAPIのインストールは完了した。
続いてTokyoTyrantのRubyAPIの準備です。
sudo ruby install.rb
するとDid you mean RbConfig?
と、煽られました。
どうやらRuby2.2以降ではこれに変わったとかでこれに書き換えたらいいと書いてましたが、今度はコードに関するエラーが出ました。
もう心が折れました…。
一応TokyoCabinetとTokyoTyrantの挙動は確認できましたので、よしとしよう。(提案-即決)
おわりに
今回は、一応キー・バリュー型についてだけ実行することはできました。Rubyからの操作は出来なかったので、今後暇を見つけてやってみようと思います。出来たら追記をするかもしれません。何かこれについてこうしたらいいというのがありましたらご教授お願い致します。