CA.io#1的Elasticsearch学习会笔记

3 年 ago

科, 雅

1 minute

CA.io第一卷：支撑匹配服务的Elasticsearch

最近开始对Elasticsearch产生了兴趣（虽然还没亲自尝试过），碰巧有一个看起来挺合适的研讨会，所以我去参加了。以下是当时的笔记。

勉強会的网页链接：https://cyberagent.connpass.com/event/65002/。

第一场会议

《Elasticsearch 6.0 即将发布》作者：Jun Otani @johtani

elastic社
Apache Lucene-gosenコミッター
ElasticSearch Server日本語版の翻訳(<- これは今から勉強する人は読まないように。古い。) 宣伝 6.0出ます。今preview release 使ってバグ見つけて報告してね！ Elasticsearch 6.0 6.xにUpgradeするのはかなり楽 1.x -> 2.xのUpgradeは苦行だった
5.xにUpgrade 2.x -> 5.x deprecationが出せる。やるべき対応を洗い出してくれるプラグインがある。
6にUpgrade 5.x -> 6は、クラスタ全部を落とさなくても一台ずつアップグレードしてまわればダウンタイムなしでいける。

改善点

中で使っているLuceneのバージョンが上がった(Lucene7)

Better for storing sarse fields
Save on disk space

ソート検索のクエリ速度改善
レプリケーションが早くなっている。

破壊的変更

_type がなくなる

今まで間違った使い方をされがちだった
5.xで作ったものでアップグレードしている場合は使える。が、新しく6.xで作れなくなっている。

template が index_patterns にrename

その他の変更

Content-Type detection disabled
Deprecation of _all

Java High Level REST Client

第二個會議

「タップル誕生引入Elasticsearch的3个原因」，作者Valverde Antonio ，GitHub：@toniov

会員数 250万人
マッチング数 5500万組
ライク 6億件
App Annieランキングでアプリ収益第７位
フリック形式で恋人を探す

masterデータをMongoDBにもたせてあり、検索用データをElasticsearchにもたせている
導入の理由

検索のパフォーマンスのため

ユーザ検索

絞り込み項目が多い
もともとMongoDBで検索平均1,250ms
Elasticsearch 平均 231ms

より複雑な検索を実現するため

今まで作れなかった機能が開発できた
パフォーマンスに余裕が出たので、マルチサーチができるようになった(例並び順:新規ユーザ60%,既存ユーザ40%)

他の検索エンジンよりタップルに合っていた

Solrよりあっていた部分

Designd for the Cloud
Ease of deployment and use
JSON-based (サービスバックエンドがNode.js)
社内である程度使われていた
トレンド

第三节

「基于位置信息的Elasticsearch应用案例」由川田浩史撰写

CA7年目
担当サービス8個くらい、ほぼ新規
CROSSMEが一番担当長い

プロダクト紹介 CROSSME

「すれ違い」機能が付いたマッチングサービス
近所で出会いやすいアプリという打ち出し方

Elasticsearch x 位置情報を使った機能を3つ紹介

「すれ違い」機能

ある時刻範囲内で特定距離内にユーザがいるのをすれ違いとする。単純。
mapping

typeをgeo_point型とすることで位置情報として扱うことができる

クエリ

get_distance

distance: miles,centimeters,kilometersを単位付きで指定
distance_type

逆geo_location

緯度経度から住所を検索するAPIは基本的に有料
しかし、国土交通省が配布しているCSVがあるので、それをElasticsearchに突っ込めば無料で同じものが作れる

すれ違いカバー画像

自分の現在位置によってカバー画像が変わってくれる

住所以外の場所名でも画像を変えたい

geo_shapeを使用して、範囲内にヒットするものを探す(?)

第四节

“『Elasticsearch的应用和案例〜以mimi为例〜』由矢崎亮太撰写”

2016年12月リリース
好きな「顔」で検索できる

キレイ系/かわいい系
etc…

その他年齢、住所、趣味、その他もろもろの条件で検索可能
男/女で検索に使える属性が違う
完全一致で検索したい項目と、スコアマッチで検索したい項目がある

インデックス再構築事例

インデックス定義やシャーディングはあとからの変更はできない
elasticsearchに格納されていないフィールドがあったり、想定と違うフィールドがあったりした。

->インデクス再構築の必要性

新形式のインデックスを作成、同期ツールを作って同期を保った

タイミングをみてアプリケーション側で旧->新へ向き先を変更

第五个会议

中川武憲在GitHub上的「不包括与配对用户相关的3种方法」中提到的是：『排除掉与配对用户相关的三种方法』。

マッチしている場合、ブロックしている場合は表示してはいけない
方法

1:documentにもたせる

メリット

シンプル
検索速い

デメリット

user documentが肥大化

2:queryにもたせる

検索クエリでexclude userを指定
メリット

シンプル

デメリット

検索クエリが肥大化

3:parent-childを使う

exclude user documentのchild documentをもたせる
メリット比較的検索も更新も速い
デメリット

複雑
document数が増加
Parent-childはES6で仕様変更が予定されている

Elasticsearch on EC2

2つの選択肢

Elastic Cloud

Elasticsearch社の公式サービス
X-Packも使えて全部入り
最新のESが使える
GCPも選べる

Amazon Elasticsearch Service

AWSのフルマネージドサービス
ログ集計と可視化用途の色が濃い

負荷試験

Gatling

最終的な判断

EC2

構築運用できるエンジニアがいればコストパフォーマンス最強
ansibleで管理して、横軸組織で共有

構成

master node 3
data node 4

备忘录

Elasticsearch、アイデアしだいで面白いことができそう