- 日時: 2014-09-16 19:30~
- 場所: グラントウキョウサウスタワー 41F リクルートテクノロジーズ
- イベント詳細 http://elasticsearch.doorkeeper.jp/events/13917
Elasticsearch Inc. Jun Ohtaniさん @johtani この間のefk本の勉強会の発表からaggs関連詳しくしたような感じかな
- Aggregation機能はver 1.0から
- Facetはdprecated!
- 2.x系でなくなる予定
- SQLでいうところの
select count(color)
from table
group by color
color
ごとにBucketに入って、MetricでBucket内のドキュメントのデータをいろいろ計算できる- Metric
- count
- 文字数の平均
- 最大値
- 処理時間最大値、パーセンタイル
- Facetだと1段しかできないところをAggsなら複数段(ツリー構造)でできる
- 普段のQuery
- 全てのShardにQueryを投げて、結果をマージして返す
- Aggs
- 同様に各ShardでAggregationの処理を行う
- Aggregationは検索のクエリフェーズで、Shard毎に実行される
- post_filterを適用する前にaggsが走る(影響を受けない)
- termsは近似値
- significant terms
- 異常検知、レコメンドなどに利用(Uncommonly common)
- 参考文献:あとで
- range
- date range, ipv4 range, geo
- histogram
- Bar Chart向け
- min/max/sum/avg/sum
- stats:上記4つ
- cardinality
- SQLのDISTINCT
- 近似値(HyperLogLog++)
- 最大40000まで指定可能(precision_threshold * 8byteのメモリが必要)
- parcentiles
- compressionでメモリ使用料を調整可能
- top-hits
- グルーピングされた検索結果(Field Collapsing)
- Googleでいうと、検索結果がドメインでまとめられたりするやつ
- メモリ食うよ
- グルーピングされた検索結果(Field Collapsing)
- scripted metrics
- 1.4.0から
- scriptによるMetrics
株式会社サイバーエージェント 山田直行さん @satully Smalgo(DSP)の人
RTBの説明は本業なので割愛
- MySQL、Redis、Fluentd、S3、ElasticSearch
- bidは数十台
- SSPは十数社
- Markサーバー→配信とは直接関係ないけどその他行動履歴等のタグ?
- 秒間3万程度、月間4-500億bidリクエスト
- 当初はRedshift検討してたがやめた
- 柔軟なスキーマ、スケールアウトが容易、リアルタイムとバッチでの両方の分析/集計ができること
- 目標月間2000億リクエスト
- kibanaが便利すぎた
- ちょうど流行始めた時期
- 柔軟なスキーマ、スケールアウトが容易、リアルタイムとバッチでの両方の分析/集計ができること
- Search Nodes
- master:false
- data:false
- 2nodes
- r3.large
- このサーバーについてはあまりたてる意味がなかった?
- Coordinate Nodes
- master:true, 2node, r3.large
- Data Nodes
- master:false
- data:true
- 28nodes
- 12shard, 1repl
- r3.xlarge/1GB SSD
- バッチサーバー、kibana、RESTクライアント
- bid, imp, click, convはそれぞれ紐付く
- 1docにまとめてる(すげーな)
- データ更新ごとにbid idをひいてそこにimp、click、convのkeyをupdate
- kibanaのクエリが時々えぐい
- ピークに書き込みがすげー遅延する
- 別DBのバッチと数値が合わなくて苦労
- シャードの再配置がピークに被ると死ぬ
- bidしたログとbidしてないログのindexを分けるのが負荷分散にすごく効いた
- 1日のindexが750GBくらい
- productionに入れないとわからないことも多い
- だよねー
- アップデートでパフォーマンス向上した
- SSDにしたら超改善した
- 検索処理のキャッシュ
- とはいえ最近はESと他のプロダクト?の棲み分けもはじめたっぽい
- head, bigdesk, HQ, Zabbix
- zabbixは全般的な死活監視とFluentdの監視
- elasticsearch.ymlの設定変更はあんましパフォーマンスに効かなかった
- アップグレードは新しいインスタンスを台数分用意した
- ローリングアップグレードできるきがするけど?
johtaniさんより、中の人のindexingのパフォーマンスチューニングについての記事があるよとのこと。→これ
- logstash使ってる人→いない…
- Winで動くかも(jrubyとgolang(forwarder)つかってる)
- kibanaはもうしばらくするとaggsに対応すると思う
ナレッジワークス株式会社 木戸国彦さん @9215 メモるのむずいからスライドの降臨を希望
- スキーマレスがESの強みである
- が、マッピング定義があるよね
- フィールド毎に考えることが多い
- 状況によって変化する目的
- それによってマッピング定義も変化する
- 多言語対応はデフォルトのアナライザーを利用
- language keyをみて各言語に対応したアナライザーを利用できる?
- 性格に絞り込みたいときはrawフィールド、検索漏れを少なくしたいときはsubstringを使うとかを共有
- dynamic template
- フィールド名のパターン、マッチング方式、JSONフォーマットタイプ、マッピング定義
- 最初にパターンにマッチしたマッピングが定義される
- index template
- indexパターン毎に定義できる
- config/templates以下に保存する
- ノードの再起動は必要ない
- 新規で作成したインデックスのみに適用される
アンケートこたえよう→これ
@furandon_pig さん
-
スライドもういっかい見たいな
-
前提:ソースコードから理解しようとするのは間違いですよ。
-
手続き指向おじさん(仮)には少し慣れが必要なソースコード
-
johtaniさんより
- RestControllerを見ると、リクエストを処理する部分が見られるよ
- リクエストのパラメータで検索して追っかけてる
- ソースコードリーディングやろうかな
- 個人的にはぜひ参加したい
株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi
- Reroute Commands
- Allocate
- 未配置のshardを指定したNodeに配置
- Cancel
- 配置済みのshardを未配置に
- Move
- 文字通りshardの移動
- Allocate
- 動かす前に自動再配置を抑止しましょう
- Bonsai Is Cool!
株式会社ドワンゴモバイル 西田和史さん
- 1.0移行で追加したsnapshot/restore apiの話
- 戻すときにCloseするのを避ける
- Indes Aliases機能とリストア時のリネームを組み合わせて無停止で復元
- 大変実践的な内容だ