読者です 読者をやめる 読者になる 読者になる

はやさがたりない。

へっぽこぷろぐらまのメモログ

第5回elasticsearch勉強会にいってきました

静岡からの参戦。 しかし遠いなぁ、定時即でぎりぎり。 もう少し近ければいいのに。 例のごとく道に迷いながら時間ギリギリでたどり着きました。

Elasticsearchトレーニングに参加している先輩2人と合流してお勉強会スタート。

@yusukeさん、同時翻訳ありがとうございました!!

もう英語力がなさすぎてちんぷんかんぷん。 基本的に同時翻訳をごりごりメモらせていただきました。 ちゃんとまとめきれていない、個人めも程度です。ごめんちゃい。

タイムテーブル1

Honza Kral / @honzakral さん Elasticsearchのpythonクライアント作っている人とのこと。 なかなか渋い色のElasticsearchTシャツを着ていた。

1.0の新機能であるaggreagationについて。

このスライド、後で読む

  • aggreagationはネストできるfacetらしい。
  • aggreagationの中にさらにaggreagationを記述できる。
  • デモでは1つのクエリでドキュメントのヒット数、トップコメント、コメンタのスコアなどを取得できた。
  • キーのstringがとれるようになった(?)

あとpythonクライアントの話。 クエリとかフィルターがメソッドチェーンで簡単にかけるらすぃ。けどpython使ってなかったのでふむふむ、とした感じ。 んー、でも簡単なツールならこっち使った方が簡単かも。

aggreagationは結構目玉機能な感じ。 必要なときに必要なものしか調べない(悪い癖)からこういうのについていけていない。。。 ちょっとさわってみて、今度まとめてみたいと思う。

タイムテーブル2

Igor Motov / @imotov さん Elasticsearchの開発者。snapshotとか作っているらしい。 基本的なところからluceneや内部の動きについて。

※追記 資料が上がっております。

  • file descriptors 32k -> 64k この辺りの設定とか重要
  • 言葉の意識合わせ
    • nodeはJVMのプレセス単位
    • 複数あるとお互いが認識し合ってクラスタをくむ
    • indexが生成されるとshard(luceneのインデックス)にして保管される
      ドキュメントIDのハッシュ値をもとにどこにルーティングするを決める
      shardをまとめてindexとして管理する
  • master node
    • nodeがクラスタとして構成されるとmasterノードが決定される
      クラスタのステートはノードのリストやアドレスなど、インデックスのメタデータ
      シャードのルーティングテーブルなどで構成される
  • cluster state
    クラスタ構成中のみ存在する情報(永続化されていないという意味??いや永続化されている???)
  • data
    • データはproximity(近さ)によっていろんなレベルで保管される
    • elasticsearch.ymlや--path.data on command lineでデータディレクトリを指定できる
    • 1つの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のバッファに送られ、バッファをフラッシュするタイミングでluceneのインデックス二反映される(MySQLのbin-logみたいな操作ログかな?)
    • これは時間がかかるのでいくらか、ためてから定期的に実行する(refreshのことか?)
    • transaction logにはアクションを時系列に記録していく
    • デフォルトでは5秒毎に反映される
    • transaction log がいっぱいになるとluceneセグメントに反映される
    • 落ちた場合はtransaction logを確認して復旧する
  • lucene segments

    • every 30min 200mb or 500 operation
  • lucene indexについて

    • lucene indexにはいろんな情報が格納されている
      転置インデックスの説明、わかりやすい。
    • セグメント化されている 例えばフィールドデータとしてドキュメント1にどんなトークン格納されているか、 doc2にどんなトークンが格納されているかといった情報
  • stored fields

    • デフォルトで格納している
  • 内部の動き

    • クラスタの状態を確認しシャードがどのノードにあるか確認する
    • シャード1つないで何が行われているか
      シャード内では各セグメントをなめていきます。1つずつ。
      1つのセグメント内では転置インデックスを確認してdistributedはdoc1にあることがわかる。
      つづいて日付でソート field dataより
    • top 10 document correct for each shard -> grobal top 10 doucment
      masterがマージしている。
    • シャード内ではノードで指定したドキュメントが格納されているセグメントから
      ドキュメントのテキストをひっぱってきてノードがシャードからかえってくる情報をマージしてレスポンスを返す。

QA time

フェーズを2つに分けてる理由は?

ドキュメントIDを割り出し(クエリフェーズ?)、フェーズ2で詳細情報を取得すると(fetchフェーズ?)
stored filedの情報が必要ない場合、フェーズ2はいらないんじゃないか?

シャードが返すidはドキュメントのidではなくてセグメントのidと位置。 クエリフェーズで実行した場合luceneのidをかえす (内部的にはlucene転置インデックスから内部のidをかえす) パフォーマンスが早いのでこのタイミングでフィールドは見に行かない 先にトップ10ドキュメントを洗い出してよりコストの高い処理をフェーズ2で行う ユーザが指定したdoc id を全シャードで調べて返すと重いよ countだけつかうならばsearch-typeでフェーズ2をスキップできるよ

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インデックスは複数のセグメントで構成されている どんどんたくさんのインデックスを作っていくと、セグメントができまくって1つ1つのセグメントを検索する必要が出てくる たくさんセグメントができるとあるタイミングでマージする必要がでてくる 効率的に検索するための最適なセグメント数がある

インデックスは複数のシャードで構成されていて、シャードは複数のセグメントで構成されていて セグメントは複数のファイルで構成されている。ので。FDの設定が大事。 内部通信用にも使ったりするしね。

kibana

aggreagtionはkibanaのため。facetでは十分な情報がとれなかった kibana4が作られている。そっちをお楽しみに。 1つのhistogramに異なるフィールドを出すこともできるようになる!!! これは期待!!

なんでesをつくったか

すげー暇だったからw icookという奥さんのためのレシピ検索を作りはじめたのがきっかけ。 検索ボックスが1つあって何でもそこから検索できるような。 そこからいろいろなものを使ってみたけどイマイチしっくりこない感じでー。

スナップショット機能を使っていて、現状2000スナップショットあるんだけど性能でない!

POSTがめちゃくちゃ遅い。数が大杉?

スナップショットはインクリメンタル。 過去分をみて保存できていないものを保存する仕組みなので、過去のスナップショット数が多くなると遅くなる。

定期的にあたらしくつくったほうがいいのか?

想定していない使い方かもしれないけど、それが必要があってやっているなら教えてください。なおしますよ。

relevanceあたりのドキュメントがちょっとわかりにくいかも?

まず、ドキュメンテーションは現在頑張ってます。 無料のebookがあるので読んでみてください。 MVELからgroovyベースに移行している

githubにも情報があるよ。 日本O'Reilly本でるらすぃ。

今後のビジョン

aggregationは今後に向けて、アナリティクスのプラットフォームとして躍進するのに重要な機能 ツイートが何百万もあって検索した場合ヒットが多すぎて一つ一つ追うのは無理。 aggregationがあれば検索結果から全体を俯瞰できる。 次のバージョンではaggregationがよりメモリ利用効率の高い形で実現できる。 さらにfiled-collapsionも実装予定(?)

resiliency?にも投資している luceneはハッシュの確認とかしないからデータの破損とか検出しづらい。 まずluceneチェックサム検証機能を実装した、既にマージされている。 次のesではチェックサムを様々なステージで確認する。 シャードのマイグレーションとか。スプリットブレインとか。 より分散デプロイメントが安定するはず。

ペタバイトデータを持っている人が再インデキシングするとすごい時間がかかってしまうけど改善したい。

esのデベロッパイノベーションに費やす時間を十分設けている 俺すごいの考えちゃった!なんてデベロッパがいればよしやれー見たいな風土にしている