フィールドの追加 データ長を決める int(10), varchar(128), text index.mapper.dynamic: false { } { } DDL 検索基盤スキーマ(json) ES Index Mysqlへ Elasticsearchへ PUT _mapping API PUT _settings API Rolling restart ALTER TABLE indexするか｜storeだけするか 文字列型ならアナライザを決める 検索対象なのか格納するだけなのか 追加するフィールドの型を決める boolean, integer, long, float, date, string 社内製アナライザ(kuromoji移行中？) 前提として ○ フィールド追加時に決めること
データの受け入れ ○ データ送信フロー （niconicoの検索を支えるElasticsearch by @shoito から引用） ① ② ① サービス側から新しいフィールドのデータを送信してもらう ② 検索基盤スキーマと比べて正しいフィールドのみElasticsearchへ デプロイするとElasticsearchへIndexingが開始される
クエリの受け入れ ○ 利用しているクエリ Query match query フィルタない時に利用 filtered query フィルタある時に利用 bool query Filter term filter query filter not_analyzrdな文字列でのフィルタなど range filter and / or / not filter Sort sort / function score sort 整数、日時、not_analyzrdな文字列など Aggregations Bucketing terms aggs Metric top hits aggs max / min aggs cardinality aggs グルーピング後の件数試算
Segments A B C E F ・・・ scroll中はどんどんセグメントらしき(本来削除された)ものが溜まっていく よって、リアルタイムなユーザーリクエストのためのものではない、という理解 ドキュメントには、scrollは異なる構成のデータストアに大量のデータを送り込むときに使うも のであると、最初の最初に書かれている D ＝リソース（ファイルディスクリプタなど）の消費も増えていく scrollとは（私の理解）
• ソートに限らず、広く利用される – field valuesへのアクセスを必要とする問い合わせで必要 – Aggregations、geolocation filters等のフィルタ、scriptで参照したとき・・ • 構造は非転置インデックス – 転置インデックスは単語からdoc idを探すのは得意だけど、逆にdoc idから単語 を取得するのが苦手なので、キャッシュに持つ • field valuesやシャードを跨いだGlobal ordinalsという序数を持つ – 容量は大きく、文字列フィールドだと1フィールドで500MBを超えることもある • デフォルトのフォーマットでは問い合わせ時にメモリ上に作成される – メモリに置かずかつ高速なdoc valueというフォーマットもあるが、まだデフォ ルトにはなってない – こちらはLUCENE 4.0で追加されたDocValuesを利用しているとのこと – デフォルトと違いIndex時に作成されるらしい なぜfilterやsortは、二回目の方が早いのか 疑問 2 f i e l d d a t a と は
h1kita
nishiuma
chumajin
cimadai
upura
fujiwara3
cybozuinsideout
hhiroshell
yoshimi0227
mosa_siru
yukimatsuyoshi
coconala_engineer
addyosmani
tanoku
scottboms
swwweet
mclloyd
sferik
maltzj
reverentgeek
edds
yeseniaperezcruz
marcelosomers
garrettdimon