第5回elasticsearch勉強会にいってきました
静岡からの参戦。 しかし遠いなぁ、定時即でぎりぎり。 もう少し近ければいいのに。 例のごとく道に迷いながら時間ギリギリでたどり着きました。
Elasticsearchトレーニングに参加している先輩２人と合流してお勉強会スタート。
@yusukeさん、同時翻訳ありがとうございました！！
もう英語力がなさすぎてちんぷんかんぷん。 基本的に同時翻訳をごりごりメモらせていただきました。 ちゃんとまとめきれていない、個人めも程度です。ごめんちゃい。
タイムテーブル１
Honza Kral / @honzakral さん Elasticsearchのpythonクライアント作っている人とのこと。 なかなか渋い色のElasticsearchTシャツを着ていた。
1.0の新機能であるaggreagationについて。
このスライド、後で読む
- aggreagationはネストできるfacetらしい。
- aggreagationの中にさらにaggreagationを記述できる。
- デモでは１つのクエリでドキュメントのヒット数、トップコメント、コメンタのスコアなどを取得できた。
- キーのstringがとれるようになった(?)
あとpythonクライアントの話。 クエリとかフィルターがメソッドチェーンで簡単にかけるらすぃ。けどpython使ってなかったのでふむふむ、とした感じ。 んー、でも簡単なツールならこっち使った方が簡単かも。
aggreagationは結構目玉機能な感じ。 必要なときに必要なものしか調べない（悪い癖）からこういうのについていけていない。。。 ちょっとさわってみて、今度まとめてみたいと思う。
タイムテーブル2
Igor Motov / @imotov さん Elasticsearchの開発者。snapshotとか作っているらしい。 基本的なところからluceneや内部の動きについて。
※追記 資料が上がっております。
- file descriptors 32k -> 64k この辺りの設定とか重要
- 言葉の意識合わせ
- master node
- cluster state
クラスタ構成中のみ存在する情報（永続化されていないという意味？？いや永続化されている？？？） - data
- データはproximity(近さ)によっていろんなレベルで保管される
- elasticsearch.ymlや--path.data on command lineでデータディレクトリを指定できる
- １つのdataディレクトリを複数のノードで共有することも可能
data_dir内のサブディレクトリにノード別に保管しているので (data/elasticsearch/nodes/0 みたいな感じで確かにべつものになる。) - state
デフォルトでesはjsonフォーマットで保管している
ymlファイル見るとformatとしてのjsonが指定されている（なんと、気づいてなかった） →んー、ローカルのやつはとてもjsonではない。設定もどこで指定するか見当たらない。。。 - node.lockというファイルがあり、競合がおこらないようになっている
- クラスタの_stateというディレクトリにはメタデータが保管されている
（cluster setting apiのやつとかだっけ？） - インデックス内のstateにはaliases mapping setting など インデックスのメタデータ
0 / 1 / 2 インデックスがシャードとして保管されている。
ここにもstate(メタデータ) これはシャードメタデータ
- transaction log
lucene segments
- every 30min 200mb or 500 operation
lucene indexについて
stored fields
- デフォルトで格納している
内部の動き
- クラスタの状態を確認しシャードがどのノードにあるか確認する
- シャード１つないで何が行われているか
シャード内では各セグメントをなめていきます。１つずつ。
１つのセグメント内では転置インデックスを確認してdistributedはdoc1にあることがわかる。
つづいて日付でソート field dataより - top 10 document correct for each shard -> grobal top 10 doucment
masterがマージしている。 - シャード内ではノードで指定したドキュメントが格納されているセグメントから
ドキュメントのテキストをひっぱってきてノードがシャードからかえってくる情報をマージしてレスポンスを返す。
QA time
フェーズを２つに分けてる理由は？
ドキュメントIDを割り出し（クエリフェーズ？）、フェーズ２で詳細情報を取得すると(fetchフェーズ？)
stored filedの情報が必要ない場合、フェーズ２はいらないんじゃないか？
シャードが返すidはドキュメントのidではなくてセグメントのidと位置。 クエリフェーズで実行した場合luceneのidをかえす （内部的にはluceneの転置インデックスから内部のidをかえす） パフォーマンスが早いのでこのタイミングでフィールドは見に行かない 先にトップ１０ドキュメントを洗い出してよりコストの高い処理をフェーズ２で行う ユーザが指定したdoc id を全シャードで調べて返すと重いよ countだけつかうならばsearch-typeでフェーズ２をスキップできるよ
transaction log
検索パフォーマンスには影響しない（transaction log） fsyncはディスクに書き込まれていることを確認/ensureする作業 そしてfsyncされた情報からセグメントを生成する esのrefreshを行うと発生する→transaction log の書き込み つまりtransaction logを生成したタイミングでは検索できない
apacheのアクセスログ解析に使っている人、多分Elasticsearchに入れたらログ消してもいいかな？的な？
jsonドキュメントをesに渡したらデフォルトではjsonまるまるesに格納されている esにすべての情報が格納されているという前提でよいか
多くのユーザーはデータリソースを別に持っていて簡単に再ビルドできるようにしている プライマリにはまだ使わないでほしい。別のとこにデータのこしておいて。
なぜクラスタstateの情報をnodeのレベルで持っているの？
クラスタは論理的なあつまりで、ノードの集合に名前が付けられたもの クラスタはつまりノードが動いている間しか存在しない クラスタが消えた場合ノードでも動けるように個別に持っている
Shay Banon登場
なんでFDを設定する必要がある？
luceneインデックスは複数のセグメントで構成されている どんどんたくさんのインデックスを作っていくと、セグメントができまくって１つ１つのセグメントを検索する必要が出てくる たくさんセグメントができるとあるタイミングでマージする必要がでてくる 効率的に検索するための最適なセグメント数がある
インデックスは複数のシャードで構成されていて、シャードは複数のセグメントで構成されていて セグメントは複数のファイルで構成されている。ので。FDの設定が大事。 内部通信用にも使ったりするしね。
kibana
aggreagtionはkibanaのため。facetでは十分な情報がとれなかった kibana4が作られている。そっちをお楽しみに。 １つのhistogramに異なるフィールドを出すこともできるようになる！！！ これは期待！！
なんでesをつくったか
すげー暇だったからw icookという奥さんのためのレシピ検索を作りはじめたのがきっかけ。 検索ボックスが１つあって何でもそこから検索できるような。 そこからいろいろなものを使ってみたけどイマイチしっくりこない感じでー。
スナップショット機能を使っていて、現状２０００スナップショットあるんだけど性能でない！
POSTがめちゃくちゃ遅い。数が大杉？
スナップショットはインクリメンタル。 過去分をみて保存できていないものを保存する仕組みなので、過去のスナップショット数が多くなると遅くなる。
定期的にあたらしくつくったほうがいいのか？
想定していない使い方かもしれないけど、それが必要があってやっているなら教えてください。なおしますよ。
relevanceあたりのドキュメントがちょっとわかりにくいかも？
まず、ドキュメンテーションは現在頑張ってます。 無料のebookがあるので読んでみてください。 MVELからgroovyベースに移行している
githubにも情報があるよ。 日本O'Reilly本でるらすぃ。
今後のビジョン
aggregationは今後に向けて、アナリティクスのプラットフォームとして躍進するのに重要な機能 ツイートが何百万もあって検索した場合ヒットが多すぎて一つ一つ追うのは無理。 aggregationがあれば検索結果から全体を俯瞰できる。 次のバージョンではaggregationがよりメモリ利用効率の高い形で実現できる。 さらにfiled-collapsionも実装予定（？）
resiliency?にも投資している luceneはハッシュの確認とかしないからデータの破損とか検出しづらい。 まずluceneにチェックサム検証機能を実装した、既にマージされている。 次のesではチェックサムを様々なステージで確認する。 シャードのマイグレーションとか。スプリットブレインとか。 より分散デプロイメントが安定するはず。
ペタバイトデータを持っている人が再インデキシングするとすごい時間がかかってしまうけど改善したい。
esのデベロッパはイノベーションに費やす時間を十分設けている 俺すごいの考えちゃった！なんてデベロッパがいればよしやれー見たいな風土にしている
