Xcode5でxib(Storyboardを使わない)プロジェクトの作り方
ちょっと前に出版されたiOSアプリ入門書とか読んでるんですけど、最初のほうのサンプルアプリの作成手順で説明されているのがstoryboardを使わないでxibを使う構成だったりしてこまってました。 プロジェクトの作成画面で[Single View Application]を選択して[Use Storyboards]のチェックを外しましょう、って手順が書いてあって、[Use Storyboards]のチェックボックスねーよ! Xcode5からなくなってるよ! デフォルトで有効で外せねーってことかよ! うきー!
Storyboardを使うのが主流なんですか? でも今はまだiOSアプリ初心者だから、とにかく動くものをつくって、手順を繰り返して、コードを写経して、ツールの使い方とかObjective-Cのコードの感じとかAPIとかをちょっとずつ頭に入れたいんですよ。でもいきなりつまずいたーああああーーー。のおおおーーー!
さて、いろいろググって探した末、以下の手順でxibのプロジェクトを始めるのが良さげだったのでメモしておきます。参考のサイトはこちら、詳細は元の記事を見てください。
http://www.appcoda.com/hello-world-app-using-xcode-5-xib/
手順
- Xcodeを起動
- [Create a new Xcode project]を選択
- [iOS]の[Application]を選択[Empty Application]を選択
- 適当に[ProjectName]とかを埋めて、[Next]をクリックしてプロジェクトを作成
- Xcode上でAppDeletege.hとかのソースファイルが入っているフォルダを右クリックしてメニューから[New File...]を選択
- [iOS]の[Cocoa Touch]の[Objective-C class]を選択、[Next]をクリック
- [Class]に
**ViewController
のような名前のクラス名を入力、[Subclass of]にUIViewController
を指定。[With XIB for user interface]にチェック。[Next]をクリック
これで. xibと対応するViewControllerが作成される。最後にこのViewControllerを読み込むようにするためにAppDeletege.m
にコードをちょっと追加する。#import
とdidFinishLaunchingWithOptions
メソッドを以下のようにする。
#import "AppDelegate.h" // ここを追加 #import "ViewController.h" // ここを追加 @implementation AppDelegate - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; // Override point for customization after application launch. self.window.backgroundColor = [UIColor whiteColor]; [self.window makeKeyAndVisible]; // ここを追加 ViewController *viewController = [[ViewController alloc] initWithNibName:@"ViewController" bundle:nil]; self.window.rootViewController = viewController; // ここを追加 return YES; }
ViewController
のところは上記の手順7で実際に作成したViewControllerのクラス名に読み替えてください。
以上っす。
PHPデプロイツールのAltaxのバージョン3をリリースしました。
去年10月位にバージョン2に書き直して、今回さらにまるっと書き直しました。 タスクの記述方法などもごっそり変えてしまったので、すでに使っている人は今までの設定ファイルは使えないので注意してください。
https://github.com/kohkimakimoto/altax
ドキュメントはこちら
http://kohkimakimoto.github.io/altax/ja/
一応英語圏のひとにも使ってもらえるようにドキュメントは英語でも書いています。正直、英語苦手なので変な英語だったら誰かツッコミいれてください。
概要
PHPでタスクが記述できるCapistranoみたいなものです。
SSHでリモートサーバに対してコマンドを並列実行します。
またpharでソースを全部まとめて配布しているので、動作に必要なのはPHPとaltax.phar
だけなので手軽につかってもらえると思います。
使い方
チュートリアルを書きました。
http://kohkimakimoto.github.io/altax/ja/tutorial/
タスク定義の例をあげると、Gitからデプロイする簡単なタスクは以下のように定義します。
Server::node("web1.example.com", "web"); Server::node("web2.example.com", "web"); Task::register("deploy", function($task){ $appDir = "/path/to/app"; // Execute parallel processes for each nodes. $task->exec(function($process) use ($appDir){ // Run a command remotely and get a return code. if ($process->run("test -d $appDir")->isFailed()) { $process->run("git clone git@github.com:path/to/app.git $appDir"); } else { $process->run(array( "cd $appDir", "git pull", )); } }, array("web")); });
バージョンアップにあたって
タスクをLaravelのRouting定義ぽい記述方法にかえました。
実行コマンドのリターンコードや、出力内容を取得できるようにしました。
リモートホストに対してのファイルダウンロードやアップロードに対応しました。
プラグインでタスクを拡張できるようになりました。
プラグイン
プラグインで機能拡張をできるようにしました。 サンプルにAdminerというMySQL管理ツールをさくっと使えるようになるプラグインも同時に作って公開したので、 ご興味のあるかたはどうぞ。
http://kohkimakimoto.github.io/altax/ja/docs/plugins-introduction.html
このプラグインのしくみなんですが、元ネタというか影響をうけたのがGruntのプラグインの仕組みだったりします。 Gruntはプラグインのインストールをnpmをつかってやって、Gruntfile.jsに設定を書くという構成ですが、 AltaxはPHPのツールなのでComposerでプラグインをインストール、PHPの設定ファイルに設定を書く、という構成にしています。
個人的に今はリモートサーバにたいしてchefリポジトリをgitからcloneしてchef-soloをするという、 自動化タスクをプラグインで書いてみたりしています。
https://github.com/kohkimakimoto/altax-chef
開発とかテストの環境
最近メインPCをWindowsからMacにかえました。 だだし開発自体はVirtualBoxで構成したCentOS6上でやってます。そういうわけで、 プログラム動作は主にOSXとCentOSで検証しています。あとCIにTravisを使っています。
なおMacに入っているデフォルトのPHPだとpcntlモジュールが入っていないので、 並列処理の際にプロセスをforkする処理が動かないので、この場合は並列動作させずに、 順次実行するようになっています。
SymfonyとLaravelを比べてみての考察
SymfonyとLaravelはPHPのWebアプリケーションフレームワークで 2014年現在、モダンなPHPフレームワークとして人気があるようです。 両方ともComposerによるパッケージ管理、MVCアーキテクチャ、 開発時のPHP組み込みサーバのサポート、 バンドル(Laravelではパッケージ)などでの機能拡張性を持っています。
ここ最近、個人的な興味でこのふたつのフレームワークを触ってみていたので、 感想と比較を述べてみます。
なお、実際に触ったバージョンはSymfony2.4とLaravel4.1です。 また実際のプロダクトの開発に使用したわけではないのと、 パフォーマンス比較などは行っていないことを断っておきます。
ざっくりとした比較イメージ
細かい感想と比較を書く前に、ざっくりとイメージを述べておきます。
- Symfonyは構造がしっかりしていて重厚
- Laravelは構造がフラットで軽量
ここでの重厚とか軽量とかは、プログラミングをしているときの感触であって、 アプリケーションの動作のことではありません。 また、開発するアプリケーションの規模にそれを合わせて、 サービスが小規模だからSymfonyは適していないとか、 大規模だからLaravelはよくないという話でもありません。
基本的にアプリケーションの規模が小規模でも大規模でもどっちのフレームワークを使ってもよいと思いました。
アプリケーションの規模にフレームワークの向き不向きが全くないとは思いませんが、 それよりも開発するプログラマのやり方、好みにマッチしているかどうか が一番のポイントなんじゃないかと思っています。以下、個別にピックアップします。
ネームスペース
PHPでは5.3からネームスペースによるコードの構造化がサポートされました。
Symfonyで開発するコードはこのネームスペースで厳格に構造化する必要があります。
たとえば、Pakagistのトップページ
のコントローラはPackagist\WebBundle\Controller\WebController
というネームスペースに置かれています。
Laravelではコントローラをはじめ多くのクラスがグローバルなネームスペースを使用します。Laravelの典型的なコントローラは以下のようにnamespaceなしで定義されます。
<?php
class HomeController extends BaseController {
public function index()
{
return View::make('home.index');
}
}
ネームスペースによる構造化はクラス名の衝突を避けられ、構造の見通しをよくします。 一方でそれに合わせてディレクトリ構造が深く複雑になりがちです。
Symfonyは構造が健全であることに重きをおいて設計され、Laravelは記述のシンプルさに重きをおいて設計されている感じです。
デフォルトのテンプレートエンジン
SymfonyはTwig、LaravelはBladeというテンプレートエンジンを標準で使います。
ところで、一世代まえのPHPフレームワーク(CakePHP,Symfony1,ZF1)だと、素のPHPをテンプレートエンジンに使用するのがスタンダードでした。 でも最近はそうでもなく、Symfonyの開発者であるFabien Potencierの ブログなどで言及 されているように、素のPHPでは「最適」なテンプレートの記述が行えないということから、 専用のテンプレートエンジンを利用するようになってきています。
素のPHPがスマートに対応できない領域は、テンプレート継承や、エスケープ処理、イテレータ処理などです。 もちろん、全くできないわけではないが、インラインのphpタグでテンプレートがごちゃごちゃしてしまうのが避けられない。 このへんの問題は、前述のFabienさんのブログでも参照してください。
で、SymfonyとLaravelのテンプレートエンジンのはなし。
SymfonyのTiwgは前述のPHPテンプレートのダメな部分を完全に取り除いて 理想的なテンプレートエンジンを目指して設計されている感じです。 テンプレート継承もできるし、エスケープも自動。またfor文は以下のように書ける
{% for user in users %}
* {{ user.name }}
{% else %}
No users have been found.
{% endfor %}
このテンプレートはPHPとは基本的に別ものであり、テンプレートにPHPを書くことはできません。
LaravelのBladeも同様にテンプレート継承やエスケープ機能を提供してくれますが、 設計としてPHPと別ものではなく素のPHPテンプレートに正規表現による薄い変換処理をかぶせて、ちょっと文法を拡張した感じのものです。 なので、bladeのテンプレートにはPHPのコードも書けるのですが、Twigのfor文みたいなPHPの書式から大きく異るような機能は用意されていません。
テンプレートに素のPHPを記述できることを、害悪ととるか柔軟性ととるかは、プログラマの好みによる話だと思います。 私はPHPを記述できたほうがいいと感じるタイプです。
Symfonyはその領域において最適なコンポーネントを提供するのに対して、 Laravelは最適ではないが、PHPプログラマが慣れ親しみやすいコンポーネントを提供する。 そういう設計になっています。
設定ファイル
設定ファイルの記述に関しても設計思想の違いが感じられます。 たとえば、URLとアクションをひもづけるルーティングの定義をSymfonyはyamlかアノテーションを使います。 (PHPでも記述できるが、かなり冗長なのでこれを使うひとは多分いない)
一方、Laravelは素のPHPを使います。ただしSymfonyのPHP設定ファイルのような冗長さはなく、 グローバルネームスペースとスタティッククラスでRubyのDSLっぽい簡潔な記述を提供します。
テンプレートエンジンの話と同様なのですが、 Symfonyは設定ファイルの記述においても最適な方法(PHPは最適ではないのでyamlなどの別の手段)を提供するのに対して、 LaravelはあくまでPHPを使い(PHPプログラマのためのフレームワークだからか)、その上で記述しやすい施策をとっている印象です。
まとめ
最後に抽象的にまとめると
といったところでしょうか。
LaravelのRouteクラスがグローバル空間で呼び出せる仕組み
最近Laravelを触っています。
で、LaravelだとURLと実行するアクションを関連付けるルーティング部分を
Route::get('/', function()
{
return 'Hello World';
});
こんなふうに、RubyのSinatraっぽくかけるんですよね。ところがこのRoute
というクラス、事前にuse
で使う名前空間の指定もしていないし、実際にどのPHPクラスが使われているかよくわからない。そこでソースを追ってみました。
エイリアス
フロントコントローラのpubic/index.php
を起点に読み始めていくと、
pubic/index.php
->bootstrap/start.php
->vendor/laravel/framework/src/Illuminate/Foundation/start.php
とファイルが読み込まれて、この中で、
$aliases = $config['aliases'];
AliasLoader::getInstance($aliases)->register();
ということをやっている。でregister
メソッドで$aliasesのデータつかってspl_autoload_register
関数を呼び出してオートローディングを設定している。$aliases
の内容はメインのコンフィグファイルconfig/app.php
にかかれていて、デフォルトは以下のようになっている。
'aliases' => array(
'App' => 'Illuminate\Support\Facades\App',
'Artisan' => 'Illuminate\Support\Facades\Artisan',
'Auth' => 'Illuminate\Support\Facades\Auth',
'Blade' => 'Illuminate\Support\Facades\Blade',
'Cache' => 'Illuminate\Support\Facades\Cache',
'ClassLoader' => 'Illuminate\Support\ClassLoader',
'Config' => 'Illuminate\Support\Facades\Config',
'Controller' => 'Illuminate\Routing\Controller',
'Cookie' => 'Illuminate\Support\Facades\Cookie',
'Crypt' => 'Illuminate\Support\Facades\Crypt',
'DB' => 'Illuminate\Support\Facades\DB',
'Eloquent' => 'Illuminate\Database\Eloquent\Model',
'Event' => 'Illuminate\Support\Facades\Event',
'File' => 'Illuminate\Support\Facades\File',
'Form' => 'Illuminate\Support\Facades\Form',
'Hash' => 'Illuminate\Support\Facades\Hash',
'HTML' => 'Illuminate\Support\Facades\HTML',
'Input' => 'Illuminate\Support\Facades\Input',
'Lang' => 'Illuminate\Support\Facades\Lang',
'Log' => 'Illuminate\Support\Facades\Log',
'Mail' => 'Illuminate\Support\Facades\Mail',
'Paginator' => 'Illuminate\Support\Facades\Paginator',
'Password' => 'Illuminate\Support\Facades\Password',
'Queue' => 'Illuminate\Support\Facades\Queue',
'Redirect' => 'Illuminate\Support\Facades\Redirect',
'Redis' => 'Illuminate\Support\Facades\Redis',
'Request' => 'Illuminate\Support\Facades\Request',
'Response' => 'Illuminate\Support\Facades\Response',
'Route' => 'Illuminate\Support\Facades\Route',
'Schema' => 'Illuminate\Support\Facades\Schema',
'Seeder' => 'Illuminate\Database\Seeder',
'Session' => 'Illuminate\Support\Facades\Session',
'SSH' => 'Illuminate\Support\Facades\SSH',
'Str' => 'Illuminate\Support\Str',
'URL' => 'Illuminate\Support\Facades\URL',
'Validator' => 'Illuminate\Support\Facades\Validator',
'View' => 'Illuminate\Support\Facades\View',
),
つまりRoute
クラスの実体はIlluminate\Support\Facades\Route
ということがわかる。
Laravelは自前で設定ファイルからオートローディングの登録を行うロジックをもっていて、それをつかってグローバル空間にクラスのエイリアスを作るという機能を実装していたわけだった。
※じつはIlluminate\Support\Facades\Route
にはルーティングに使用していた上記のget
メソッドは直接定義されておらず、ここからさらにFacade
という仕組みをつかって、別のクラスに実装を移しているのだけど割愛。
PHPでDSLっぽいこと
調べてみると、どうってことはない作りでした。でもこの仕組みは、クラスの実装はネームスペースで構造化された空間に定義でき、インターフェースのみグローバル空間に公開するというのが、うまく出来てると思う。これに無名関数を組み合わせることで、LaravelのRoute定義のような、Rubyの内部DSL的な記述をPHP上に表現しているのだな、とちょっと感心したのでした。
おしまい。
epelにdockerがキタ━(゚∀゚)━!ので、CentOSにインストールした。
ローカルのVirtualBox上のCentOS6で動かしました。epelリポジトリは事前に設定してあるものとします。
インストール
# yum install --enablerepo=epel docker-io
サービスの起動
# /etc/init.d/docker start
doceker runする!
# docker run -t -i centos /bin/bash
コンテナ内でシェルが起動します。echoとか打ってみる。
bash-4.1# echo hello world!
hello world!
bash-4.1# exit
うごく~( ´∀`)♪
Dockerfileからimageつくってみる
Dockerfile
FROM centos
RUN yum clean all
RUN yum install -y openssh-server
RUN yum install -y passwd
RUN echo d0cker | passwd --stdin root
## https://github.com/dotcloud/docker/issues/1240#issuecomment-21807183
RUN echo "NETWORKING=yes" > /etc/sysconfig/network
## http://gaijin-nippon.blogspot.com/2013/07/audit-on-lxc-host.html
RUN sed -i -e '/pam_loginuid\.so/ d' /etc/pam.d/sshd
EXPOSE 22
CMD /sbin/init
docker buildする!
# docker build -t test .
Uploading context 10240 bytes
Step 1 : FROM centos
---> 539c0211cd76
Step 2 : RUN yum clean all
---> Using cache
---> f738a5199bab
Step 3 : RUN yum install -y openssh-server
---> Running in 033f90a21823
Loaded plugins: fastestmirror
Determining fastest mirrors
Error: Cannot find a valid baseurl for repo: base
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os error was
14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'"
Error build: The command [/bin/sh -c yum install -y openssh-server] returned a non-zero code: 1
おちた~(T_T)!!なんでかコンテナからインターネットに接続できん。のおおお!
2013-12-07追記
:とおもったらVirtulaBoxのVMから作りなおしたら出来た。何がわるかったかわからんす。
2013-12-10追記
:ネット接続できない問題は/etc/sysctl.conf
でnet.ipv4.ip_forward = 1
にしたら治ったのかもしれない。でもCMD /sbin/init
は結局うまく動いてくれない。Dockerで/sbin/init
を動かすのはGithubのissuseにもあがっていて、みんな試行錯誤してるようだけど、まだ解決していないっぽいですな。
ElasticsearchでCentOS上にNgram全文検索サーバを構築する - (その2)Ngramアナライザを設定する
前回に引き続きElasticsearchの設定を行います。
elasticsearch-headプラグインをインストールする
いろいろ設定を試していたりすると、設定内容やデータの確認のためにコンソールからcurlを実行してREST APIを実行するのが面倒になります。そこでElasticsearchにはWebUIからデータや設定内容を参照するための機能がプラグインで用意されているので、これを導入します。
インストールは以下のコマンドを実行するだけでOKです。
$ sudo /usr/share/elasticsearch/bin/plugin --install mobz/elasticsearch-head
あとはブラウザから
http://localhost:9200/_plugin/head/
にアクセスすればWebUIからデータの操作ができるようになります。
アナライザ
アナライザは、文字列タイプのフィールドをElasticsearchにインデックスする(データを保存する)ときや検索クエリを投げるときに行われる処理で、データを品詞分解したり、大文字小文字の入力を変換したりするテキストの解析処理のことです。インデックスするときと検索時に別々のアナライザを使うこともできます。
デフォルトでいくつかアナライザが用意されていますが、自分で定義することもできます。 今回は日本語をNgram検索をしたいのでカスタムアナライザを定義しました。なおNgramについてはググるか
http://gihyo.jp/dev/serial/01/make-findspot/0005
などの参照してください。
/etc/elasticsearch/elasticsearch.yml
に以下の定義を追加します
# default analyzer (1-gram and 2-gram)
index.analysis.analyzer.default.tokenizer: custom_ngram_tokenizer
index.analysis.analyzer.default.filter.0: lowercase
index.analysis.tokenizer.custom_ngram_tokenizer.type: nGram
index.analysis.tokenizer.custom_ngram_tokenizer.min_gram: 1
index.analysis.tokenizer.custom_ngram_tokenizer.max_gram: 2
index.analysis.tokenizer.custom_ngram_tokenizer.token_chars.0: letter
index.analysis.tokenizer.custom_ngram_tokenizer.token_chars.1: digit
# default_search analayzer(2-gram)
index.analysis.analyzer.default_search.tokenizer: custom_bigram_tokenizer
index.analysis.analyzer.default_search.filter.0: lowercase
index.analysis.tokenizer.custom_bigram_tokenizer.type: nGram
index.analysis.tokenizer.custom_bigram_tokenizer.min_gram: 2
index.analysis.tokenizer.custom_bigram_tokenizer.max_gram: 2
index.analysis.tokenizer.custom_bigram_tokenizer.token_chars.0: letter
index.analysis.tokenizer.custom_bigram_tokenizer.token_chars.1: digit
設定を反映させるため、Elasticsearchを再起動し、データを再投入します。
さて、上記のアナライザの定義ですが、2つのカスタムアナライザを定義しています。まず最初の
# default analyzer (1-gram and 2-gram)
index.analysis.analyzer.default.tokenizer: custom_ngram_tokenizer
index.analysis.analyzer.default.filter.0: lowercase
部分ですが、index.analysis.analyzer.default
というキーでデフォルトのアナライザを定義しています。index.analysis.analyzer.default.tokenizer: custom_ngram_tokenizer
はトークナイザ(品詞分解する処理)にcustom_ngram_tokenizer
を使うことを設定しています。で、このcustom_ngram_tokenizer
はその下に設定内容が書いてあります。
index.analysis.tokenizer.custom_ngram_tokenizer.type: nGram
index.analysis.tokenizer.custom_ngram_tokenizer.min_gram: 1
index.analysis.tokenizer.custom_ngram_tokenizer.max_gram: 2
index.analysis.tokenizer.custom_ngram_tokenizer.token_chars.0: letter
index.analysis.tokenizer.custom_ngram_tokenizer.token_chars.1: digit
文字を1-gramおよび2-gramで分解する設定となっています。つまり、
こんにちは
という文字は
こん, んに, にち, ちは
こ,ん,に,ち,は
というように分解されインデックスされます。さて、もう一つのアナライザですが、
# default_search analayzer(2-gram)
index.analysis.analyzer.default_search.tokenizer: custom_bigram_tokenizer
index.analysis.analyzer.default_search.filter.0: lowercase
という定義になっています。このindex.analysis.analyzer.default_search
という設定は、検索時のみに使われるアナライザのデフォルトになります。こちらのトークナイザの設定はcustom_bigram_tokenizer
で、これは
index.analysis.tokenizer.custom_bigram_tokenizer.type: nGram
index.analysis.tokenizer.custom_bigram_tokenizer.min_gram: 2
index.analysis.tokenizer.custom_bigram_tokenizer.max_gram: 2
index.analysis.tokenizer.custom_bigram_tokenizer.token_chars.0: letter
index.analysis.tokenizer.custom_bigram_tokenizer.token_chars.1: digit
となっており、2-gramで分解する設定です。こんにちは
の例ですと
こん, んに, にち, ちは
という分解を行います。 で、なんでインデックス時と検索時のアナライザを別々に定義しているのかというと、1文字による検索でも何らかの検索結果を返したいと考えて設計したからです。
2-gramのみでインデックスしてしまうと、1文字による検索に一切マッチしません。 一方、検索時は2-gramのみをおこなっていますが、このアナライザに1文字の検索クエリをなげると、
# 以下はアナライザの動作確認をおこなうリクエスト
$ curl -XGET 'http://localhost:9200/blog/_analyze?analyzer=default_search&pretty=true' -d 'a'
{
"tokens" : [ ]
}
# 検索
$ curl -XGET http://localhost:9200/blog/article/_search?pretty=true -d '{"query": {"match":{"_all":"a"}}}'
{
"took" : 10,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
},
"hits" : {
"total" : 0,
"max_score" : null,
"hits" : [ ]
}
のように、トークンが空になってしまい、そのままですとやはり検索に引っかかりません。 そこで一文字の時は、検索にアナライザを利用しないようにqueryをmatchからtermに変更して、以下のようなリクエストをなげるようにしました。
$ curl -XGET http://localhost:9200/blog/article/_search?pretty=true -d '{"query": {"term":{"_all":"a"}}}'
これで一文字のときも検索に引っかかるようになります。
マッピング
今回はまず導入ということで、フィールドに対してマッピングは行いませんでした。 マッピングは個々のフィールドに詳細な設定ができる、RDBMSでいうところのスキーマ定義に当たります。 マッピングを使えば特定のフィールド(たとえばブログのタイトル部分だけ)に特定のアナライザを適用したりとか、もっと高度で効率的な検索もできると思います。 しかし上記のデフォルトアナライザの設定だけでも、ドキュメントのテキスト部分全体に対してNgram検索がかけられて、いい感じの検索結果を得ることができています。
ElasticsearchでCentOS上にNgram全文検索サーバを構築する - (その1)インストールと基本のデータ操作
ここしばらくオープンソースの全文検索エンジン、Elasticsearchを調べてました。
今回はNgramによる検索ができるように設定したので、その時のことをインストール方法から書きます。 どうにも同じ全文検索エンジンであるApache Solrに比べて新しいせいか、ネットの情報が少ないと感じたのと、検索エンジンをまじめに導入したのが初めてだったので、結構大変でした。 なお、この記事は自分用の備忘録をかねているので、いろいろ長くなりそうです。 よって何回かにわけて書く予定です。
Elasticsearchの概要
- 全文検索エンジン(全文検索機能をもつデータベース)
- データ構造はJSON。スキーマレス。(MongoDBに似ている)
- Javaで実装されている。内部にLuceneを使用している。(solrに似ている)
- foursquare、Githubなどでの利用実績。
- HTTPのREST APIがデータ操作のインターフェース。
- AWSとは何にも関係ない。
買って参考にした書籍
ちょっと情報古いですけど情報は網羅されているし、アーキテクチャの解説もあるのでかなり参考になりました。 あとは、公式サイトのドキュメントを見ながら作業しました。
やったこと
CentOS6をプラットフォームとした自前検索サーバの構築。 検索サーバはシンプルに一台のみ。分散環境やレプリケーションはやってないです。
インストールと起動
ElasticsearchはJavaによる実装なのでyumでまずjavaを入れます。
$ yum install java-1.7.0-openjdk
その後公式サイトからRPMをダウンロードしてインストール。
$ rpm -ivh elasticsearch-0.90.7.noarch.rpm
起動
$ /etc/init.d/elasticsearch start
ポート9200をListenしてデーモンが起動します。インストールはこれだけです。
なおディレクトリ構造は以下のようになっています。
/etc/elasticsearch/
:設定ファイル/var/lib/elasticsearch/
:データディレクトリ/usr/share/elasticsearch/bin/
:実行ファイル/usr/share/elasticsearch/lib/
:ライブラリ(Javaなのでjarがある)
基本の論理構成
Elasticsearchのデータは以下のような構成要素からなります。
インデックス
RDBMSの「データベース」に相当する要素。
タイプ
RDBMSの「テーブル」に相当する要素。
ドキュメント
RDBMSの「レコード」に相当する要素。 さらにドキュメントは複数の「フィールド」からなっていて、「フィールド」はRDBMSの「カラム」に相当します。 ドキュメントのフィールドは固定の構造である必要はなく、スキーマレスな構成にできます。 ドキュメントはJSONで構造化されたデータとして保存されます。
基本のデータ操作
データの操作はHTTPのREST APIによって行います。アクセスする先のURLは
http://localhost:9200/{インデックス}/{タイプ}/{ドキュメントのid}
が基本の構造。インデックスやタイプはデータが最初に登録されたときに自動的に(動的に定義されるスキーマをともなって)構築されます。
ドキュメントの入力
PUTメソッドで入力します。
$ curl -XPUT http://localhost:9200/blog/article/1 -d '{"title": "記事のタイトル", "content": "本文テキスト"}'
pretty=trueをつけるとレスポンスが読みやすくなります。
$ curl -XPUT http://localhost:9200/blog/article/1?pretty=true -d '{"title": "記事のタイトル", "content": "本文テキスト"}'
POSTメソッドを使うとドキュメントIDを指定しない場合自動でIDが振られます。
$ curl -XPOST http://localhost:9200/blog/article/?pretty=true -d '{"title": "記事のタイトル", "content": "本文テキスト"}'
ドキュメントの検索
GETメソッド、id指定で取得します。
$ curl -XGET http://localhost:9200/blog/article/1?pretty=true
検索クエリは以下のような感じに。
$ curl -XGET http://localhost:9200/blog/article/_search?pretty=true -d '{"query": {"match":{"title":"検索文字ほげほげ"}}}'
※この時点ではアナライザ(次回以降に説明予定)が指定されていないので、デフォルトの検索アルゴリズムが適用されます。
ドキュメントの更新
データを上書き。
$ curl -XPOST http://localhost:9200/blog/article/1?pretty=true -d '{"title": "更新するタイトル", "content": "更新する本文"}'
一部のみ変更することもできます。
$ curl -XPOST http://localhost:9200/blog/article/1/_update?pretty=true -d '{"script": "ctx._source.content = \"更新する本文\""}'
ドキュメントの削除
DELETEメソッド、ドキュメントのid指定して削除。
$ curl -XDELETE http://localhost:9200/blog/article/1?pretty=true
タイプの削除。
$ curl -XDELETE http://localhost:9200/blog/article?pretty=true
インデックスの削除。
$ curl -XDELETE http://localhost:9200/blog?pretty=true
まとめ
インストールと基本操作は以上です。 ここまでで、ElasticsearchはいわゆるKVSのようなデータベースとして振る舞えることがわかります。 この後アナライザの定義を行い、ドキュメントにたいしてNgram全文検索できるようにしていきます。
そんなわけで次回に続く。。。