まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

CouchBase サーバーは高速なドキュメント指向(JSON)データベースです。高速・大容量のデータを得意とする一方、SQL 型と異なり、SQL select による(like 節による)全文検索は苦手です。

ただ CouchBase は Apache Lucene をベースとするオープンソースでスケーラブルな全文検索&解析エンジン ElasticSearch と連携することで、この苦手部分を補っています。単なる SQL select よりも強力な検索エンジンと組み合わせることで CouchBase サーバーは更に強力なデータベースとなります。


この CouchBase サーバー環境に ElasticSearch を導入して連携させるところまでの手順を紹介します。なお CouchBase サーバー自体の導入はこちらを参照してください。CouchBase サーバーの導入まではできているという前提で、また今回は CouchBase サーバーと同じサーバー内に ElasticSearch サーバーを導入して環境構築するという前提で以下を記述します。また以下の内容についてはこの記事を記載している 2014/06/11 時点の最新環境である CouchBase 2.5.1 / ElasticSearch 1.2.1 / Couchbase Plug-in for Elasticsearch 1.3.0 の各バージョンにて確認しています。


まず ElasticSearch の動作に必要な Java 環境(Java 6以上)を用意します。Oracle Java を導入しても構いませんが、Open Java であれば以下のコマンドで導入可能です(Java 7 の場合):
# yum install java-1.7.0-openjdk

次に検索エンジンである ElasticSearch 本体を導入します。公式サイトから最新版(2014/06/11時点では 1.2.1)のインストールモジュールをダウンロードします。インストールモジュールにはいくつかの種類はありますが、今回は rpm パッケージ版(elasticsearch-1.2.1.noarch.rpm)をダウンロードします。

ダウンロードできたら rpm コマンドでインストールして起動、および自動起動設定までを行います。ちなみにこの rpm 版をインストールした場合、ElasticSearch 本体は /usr/share/elasticsearch/ 以下に導入されます :
# rpm -ivh elasticsearch-1.2.1.noarch.rpm
# /etc/init.d/elasticsearch start
# chkconfig elasticsearch on 

これで検索エンジンの ElasticSearch 本体がインストールされました。が、実際の利用時には CouchBase サーバーのデータを ElasticSearch に複製した上で検索インデックスを作成して、CouchBase サーバーの中に入っているデータに対する検索エンジンとして使いたいのです。 というわけで、これら2つを接続するためのプラグイン(と、ElasticSearch の設定をウェブから行うためのインターフェースアプリケーション)を最後に導入します。
# cd /usr/share/elasticsearch
# bin/plugin -install transport-couchbase -url http://packages.couchbase.com.s3.amazonaws.com/releases/elastic-search-adapter/1.3.0/elasticsearch-transport-couchbase-1.3.0.zip
# echo "couchbase.password: password" >> /etc/elasticsearch/elasticsearch.yml
# echo "couchbase.username: Administrator" >> /etc/elasticsearch/elasticsearch.yml

(以下引き続き ElasticSearch Head(ウェブインターフェース)の導入) # /etc/init.d/elasticsearch stop # bin/plugin -install mobz/elasticsearch-head # /etc/init.d/elasticsearch start

Elastic Head の導入と、ElasticSearch の再起動までができたらウェブブラウザで
 http://(サーバーのIPアドレス):9200/_plugin/head/
にアクセスして、ウェブインターフェースが表示されることを確認してください:
2014061101


接続用プラグインが導入できたので、次はインデックステンプレートを導入します。今回はデフォルトのインデックステンプレートを使って、インストール時に追加した beer-sample サンプルバケットを対象に設定してみます。また ElasticSearch の導入されたホストから実行する前提で記載しているので localhost を使っていますが、ElasticSearch がリモート環境にある場合は localhost 部分を該当ホストの IP アドレスに変えて実行してください:
# cd /usr/share/elasticsearch
# curl -XPUT http://localhost:9200/_template/couchbase -d @plugins/transport-couchbase/couchbase_template.json
 →{ "acknowledged":true } が返ってくることを確認
# curl -XPUT http://localhost:9200/beer-sample
 →{ "ok":true, "acknowledged":true } が返ってくることを確認
# echo "couchbase.maxConcurrentRequests: 1024" >> /etc/elasticsearch/elasticsearch.yml
# /etc/init.d/elasticsearch restart
# curl -X POST -u Administrator:password http://localhost:8091/internalSettings -d xdcrMaxConcurrentReps=8

最後に XDCR の設定をしてデータの複製処理を定義します。
Couchbase ウェブコンソール(http://***:8091) にログインしてします:
2014061102


XDCR タブを開いて、 "Create Cluster Reference" をクリックします:
2014061103


以下を入力して "Save" します:
 Cluster Name: "ElasticSearch"
 IP: (IPアドレス):9091
 Username: Administrator
 Password: (パスワード)
2014061301



Cluster Reference が作成されたことを確認します:
2014061105


続いて "Create Replication" をクリックし、以下を入力して "Replicate" をクリックします:
 From -> Bucket: beer-sample
 To -> Cluster: ElasticSearch
 To -> Bucket: beer-sample
 Advanced -> XCDR Protocol: Version 1
2014061106

 
これで Replication が定義できました:
2014061107
 
 
この状態で改めて Elastic Search のウェブインターフェースにアクセスするとデータの複製が確認できます:
2014061108



では最後にこの環境で CouchBase サーバーに格納したデータが全文検索できることを確認してみましょう。

まずは CouchBase にいくつかのデータを格納してみます。CouchBase ウェブコンソールにログインし、Data Buckets タブを開き、上記で複製の設定を行った beer-sample バケットの右にある Documents ボタンをクリックします:
2014061302


beer-sample バケット内のデータ一覧が表示されます。が、最初の段階ではデータが入ってないので何も表示されません。ここに Document(レコード)を追加してみましょう。Create Document ボタンをクリックします:
2014061303


作成する Document の ID (ハッシュキー)を適当に指定します。ここでは doc001 と入力しています。Create ボタンで作成します:
2014061304


デフォルトの内容で Document が1つ作成されました。Document が JSON フォーマットになっていることが分かります。この画面はエディタなので、ここから Document の中身を変更することも可能です:
2014061305


こんな感じの日本語のデータに書き換えてみました:
{
 "title": "ワールドカップ",
 "body": "がんばれ、日本代表!"
}


Save で保存できます:
2014061306


Documents の一覧に戻ると作成したデータが登録されていることが確認できます。以降この手順を繰り返して Document をいくつか作成しておきます:
2014061307


検索用にいくつかのデータを適当に登録してみます。JSONフォーマットなので "title" や "body" といったフィールド名も自由に追加・変更して格納できます:
2014061308


先程複製の設定を済ませているので、ここで CouchBase サーバーに登録したデータは ElasticSearch に複製されており、全文検索ができるようになっているはずです。ではその様子を確認してみます。

今度は Elastic Head にアクセスしてみて、Browser タブを選択します。この時点では何の絞り込みもしていないので、管理用データも含めて全てのレコードが右側のペインに表示されています:
2014061309


試しに、上記の2番目に登録した、id = doc002 のデータを検索してみます。左側のペインで title と書かれた箇所をクリックして展開し、そのテキストフィールドに "タイトル" と入力すると、右側のペインに id 列が doc002 のデータが見つかるはずです。CouchBase サーバー内のデータが日本語で全文検索できるようになったことが確認できました
2014061310


検索されたレコードをダブルクリックするとこんな画面が表示されます。直接 CouchBase の中身が表示されるわけではなく、ElasticSearch 側に格納されたレコードの情報が表示されるので、実際に検索した文字列が表示されるわけではありません。その代わり「title フィールドに "タイトル" という文字が含まれているレコードの id は doc002」ということが分かりました。実際のアプリケーションではこの結果を元に再度 CouchBase サーバーに id 指定で問い合わせをして、このデータレコードの情報を取得・更新・削除する、という処理フローになります:
2014061311



高速・大規模利用を想定した CouchBase で、ネックだった全文検索(それも日本語の)もこの方法でカバーできるようになりそうです。自分もまだ詳しく理解できているわけではなくて、これから調べることも多そうだけど、これはなかなかヒットの予感。。



 

CouchBase は大規模データ処理を得意とする No-SQL なデータベースです。ベースとなった CouchDB と memcached の機能を合わせ持っていることで高速トランザクションに耐え、またウェブアプリケーションサーバーを内蔵していることで管理機能だけでなく、ウェブアプリケーションの開発もすぐに開始できる、という特徴があります。加えて REST ベースのデータ読み書き API が標準で用意されている(というか、データの読み書きには REST を使う)ので、特定言語やプラットフォームに依存しない多くの環境から利用することができる、という特徴もあります。


この CouchBase を CentOS 環境にインストールします。なお CentOS は 64bit 版の 6.5 を、CouchBase のバージョンはこのエントリ執筆現在の最新版 2.5.1 を使う前提で以下を紹介します。今回は Enterprise Edition を利用しますが、この Enterprise Edition は無償でダウンロードでき、非商用利用であればノード数無制限に、商用利用でも2ノードまでは無償で利用できます。


まずは導入用のモジュールを入手します。公式サイトから環境にあったモジュールを選択してダウンロードします。今回のケースでは 64bit Red Hat 6 の Enterprise Edition を選択します。
2014060601


処理を進めていくと、最終的にダウンロードURLの書かれたメールを受け取ることになります。記載された URL からインストールモジュールをダウンロード&インストールします:
# cd /tmp
# wget http://packages.couchbase.com/releases/2.5.1/couchbase-server-enterprise_2.5.1_x86_64.rpm
# rpm -ivh couchbase-server-enterprise_2.5.1_x86_64.rpm

これだけでインストールは完了です。ついでに CouchBase サーバーの起動も完了しています。秒殺。


では Web ベースの管理コンソールにアクセスして、初期設定まで行ってしまいましょう。ブラウザで
 http://(サーバーのIPアドレス):8091/
にアクセスします(クラウドなどでファイアウォールの設定が必要な場合は 8091 番ポートを開放しておきます)。

以下の様なセットアップ用の初期画面が表示されます。"SETUP" ボタンをクリックしてセットアップを開始します:
2014060602

最初の画面ではデータの保存ディレクトリとクラスタリングの設定を行います。保存ディレクトリは特に希望がなければデフォルトのままでも大丈夫です。次にこのサーバーのホスト目(またはIPアドレス)を入力します。クラスタ設定ではまずは1台目のサーバーになるので "Start a new cluster" を選択します。この画面の最後にこのクラスタで使用するメモリ量の指定を行いますが、とりあえずは変更せずにそのまま進めても構いません。
2014060603


次の画面ではサンプルバケットを利用するかどうかの設定を行います。CouchBase では実際のデータの入れ先のことを(データ)バケットと呼びます。そのバケットのサンプルを一緒に導入するかどうかの設定です。これがあるとすぐに動くものを確認できるようになりますが、実運用上では不要なものです。必要であればチェックを付けて次の画面に向かいます:
2014060604


次にデフォルトバケットの設定を行います。まず Backet Settings ではバケットの種類を選択します。ここではディスク永続性はないものの RAM メモリ上だけで高速に動作する memcached を選択することも可能です。一方 CouchBase は memcached の特徴に加えて、非同期/同期にディスクへの永続化を行うことも可能なデータベースになっています。 ここでは CouchBase を選ぶことにします。
Memory Size は前の画面で設定した割り当てメモリのうちの、このデフォルトバケットに割り振るメモリ量を指定します。バケットが1つだけであれば全てのメモリを割り振って構いませんし、よく分からなければ初期状態を変更せずにそのまま進めても構いません。
最後の Replication はデータの冗長性を指定する項目です。1 は「冗長数が1」、つまり2台のサーバーでデータを保持することを意味します。1台のサーバーが障害で止まっても、フェールオーバーによってデータは保たれることになります。この数が多いほど信頼性も上がりますが、それだけ多くのサーバーやリソースが必要になります。ここでは 1 を指定することにして次の項目に進みます:
2014060605


次は製品のアップデートと登録の画面です。Update Notifications にチェックを入れておくと製品がアップデートされた時に通知を受け取ることができます。また Register をしておくと最新情報が届くことに加え、緑の少ない地域に苗木を一本寄付することになるようです(お金を支払うわけではありません)。是非 Register しましょう:
2014060606


設定の最終画面です。管理者の ID(初期状態は Administrator)とパスワードを入力します。これで初期設定は完了です:
2014060607


このような管理画面が出てくれば初期設定も完了です。初期設定まで含めて考えると、CouchBase の導入手順はものすごく簡単な印象です:
2014060608



最後に、この稼働中の CouchBase サーバーに API からアクセスしてみます。今回は curl コマンドを使って、こんな感じでサーバープール情報を取得します(実際には改行なしのデータが返ってきます):
# curl 'http://(CouchBase サーバーのIPアドレス):8091/pools'
{ "pools":[ {"name":"default","uri":"/pools/default?uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","streamingUri":"/poolsStreaming/default?uuid="} ], "isAdminCreds":false, "isROAdminCreds":false, "isEnterprise":true, "settings":{ "maxParallelIndexers":"/settings/maxParallelIndexers?uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "viewUpdateDaemon":"/settings/viewUpdateDaemon?uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" }, "uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "implementationVersion":"2.5.1-1083-rel-enterprise", "componentsVersion":{ "public_key":"0.13", "asn1":"1.6.18", "lhttpc":"1.3.0", "ale":"8ca6d2a", "os_mon":"2.2.7", "couch_set_view":"1.2.0a-a425d97-git", "compiler":"4.7.5", "inets":"5.7.1", "couch":"1.2.0a-a425d97-git", "mapreduce":"1.0.0", "couch_index_merger":"1.2.0a-a425d97-git", "kernel":"2.14.5", "crypto":"2.0.4", "ssl":"4.1.6", "sasl":"2.1.10", "couch_view_parser":"1.0.0", "ns_server":"2.5.1-1083-rel-enterprise", "mochiweb":"2.4.2", "syntax_tools":"1.6.7.1", "xmerl":"1.2.10", "oauth":"7d85d3ef", "stdlib":"1.17.5" } }

これも簡単ですよね。

なお、couchBase 2.5.x の REST API 詳細についてはドキュメントを参照してください。



IBM Bluemix チャレンジでは、用意された多くのミドルウェアサービスを使ってアプリケーションを構築・開発することになると思いますが、入賞を狙おうとするとやはりなるべく IBM 製品を使ってアピールすべきではないか(苦笑)、とも思うわけです。

そんなわけで今回のエントリでは IBM DB2 が持つ特徴的な機能を紹介します。こういうことをやろうとすると DB2 の特徴を活かしてプログラミングや構築ができる、というサンプルになれば。


最近の話ではないのですが、DB2 に V9 から搭載された XML ストア機能というものがあります。

リレーショナルデータベースである DB2 に XML という型の列を定義することができます。そしてこの列には XML データをそのまま格納することができます。テーブル作成時にはこんな感じで定義します:
create table test(id int not null, data xml, updated timestamp)


他のリレーショナルデータベースでもちょっと無理をすればテキスト型の列を定義して、そこに XML を(文字列として)格納する、ということもできます、格納するだけであれば。

でも決定的な違いもあります。それは XML データを(文字列ではなく) ネイティブな XML データとして格納している、という点です。これによって以下のようなことができるようになります。

例えば上記の内容で定義した test テーブルに以下のようなレコードが格納されていると仮定します(最後のupdated列は無視します):
IDDATA
1<Response><Say language="ja" gender="woman">いい天気ですね</Say></Response>
2<Response><Say language="en" gender="man">Hello. What are you going do today?</Say></Response>
3<Response><Say language="ja" gender="man">encode と decode</Say></Response>

この状態のテーブルの DATA 列から色々な条件でレコードを検索したい時、普通の text 型データだと一般的には like 節を使った SQL の全文検索を実行することになると思います。例えば「天気」という文字を含むレコードを検索するにはこんな感じで:
> select * from test where data like '%天気%'

上記例であれば ID = 1 のレコードが検索されるはずです。text 型のデータでもこのくらいはできます。

では「<Say>要素の language 属性が "en" のものだけを検索したい」場合はどうでしょう?ケースとしては「英語で格納されているデータだけを取り出したい」ような場合です。先程の応用で SQL はこんな感じでしょうか?
> select * from test where data like '%en%'

でもこれだと ID = 2 だけでなく、(本文の中に "en" が含まれる)ID = 3 のレコードも検索されてしまいます。求めたかった結果とは違ってしまいますね。とはいえ text 型のデータに対する SQL はこの辺りはシンプルにはいかないのです。

一方、XML 型で格納した場合はどうでしょう? DB2 の XML 列に対しては XPath を使ったクエリーを実行できます。今回の例であれば、こんな具合で SQL(?) を実行します:
> select * from test where xmlexists( '$t/Response/Say[@language="en"]' passing test.data as "t" )

XPath を使って test テーブルの data 列の中身で <Reponse> 要素の下の <Say> 要素の language 属性が "en" のものを指定して検索しています。つまり単なる全文検索ではなく、XML のデータの属性値を対象に絞り込みを行っています。XML データとして扱うことができるので、もちろん「テキスト値だけを対象とした検索」や「他の属性値による絞り込み」を行うことも可能です。

この方法によって、非構造的なデータを XML の形式で保存するだけでなく、XML データとしてのテキスト検索や属性検索、といった非構造データの特性に合わせたクエリーの実行もできるようになるのでした。


・・・と、こんな具合に XML フォーマットのデータや、XML フォーマットに変換できる非構造データに関しては DB2 の XML ストア機能を使って保存することで、単なる全文検索だけでなく、そのデータの特性に合わせた検索も可能になるのでした。



 

このページのトップヘ