Elastic{ON} 2016レポート What's Evolving in Elasticsearch #elasticon

キーノートの次は、Elasticsearch本体のプロダクト紹介セッションに参加しました。

最近のElasticsearch 2.xは？

最近のElasticsearch 2.x系では、ユーザビリティの改善、Javaヒープ使用量の削減、セキュリティの強化、テストの強化などが行われています。
特にElasticsearch 2.0で、doc valuesというオプションがデフォルトで有効になったおかげで、
ヒープ使用量がグッと下がり、それなりに少ないメモリでも機嫌よく動いてくれるようになったと実感しています。

たぶんもう1.x系には戻れないですね。

f:id:acro-engineer:20160218181304j:plain:w480

また、2.2ではプロファイルAPIという機能が追加されました。
これはちょうどSQLの実行計画を取得するようなもので、Elasticsearchに対するクエリが、
どのようなLuceneクエリに分解されて、
それぞれのLuceneクエリの処理に掛かった時間や取得したデータ件数などを確認できるようになる機能です。

パフォーマンス改善で利用できるのはもちろんのこと、Elasticsearchのクエリに不慣れなうちは、
自分が書いたクエリが期待通りのクエリに分解されるかどうかを確認するという用途でも使えます。
ほら、Elasticsearchのクエリの文法とかよく分からないから、最初はOR検索をうまくできなかったりするじゃないですか。
（主に僕がそうだったんですが。）

そういう人にも便利なので、プロファイルAPIはぜひ使ってみてください。
検索クエリに "profile": true とつけるだけで実行できます。

新機能その1、加工や更新のためのAPI。

これから追加される新機能の目玉の一つが、Ingest Node。
データの加工やフィルタリングなど、LogstashのFilterプラグインで実現していた機能をElasticsearch自身が持つというものです。

f:id:acro-engineer:20160218181521j:plain:w480

たとえばApacheやnginxのアクセスログを分解して、それぞれのフィールドに格納するだとか、
IPアドレスから位置情報を取得するとか、そのような加工をElasticsearchで行うことができるようになる、というものです。

これまでは、データ加工を行いたければLogstashを挟む必要がありましたが、その必要なくなるということですね。

これはデータの流れなどが変わる要因になる、大きな機能追加と言えます。

続いて大きな変更になるのが、Re-Index API。

f:id:acro-engineer:20160218181328j:plain:w480
次のようなクエリを発行することで、old_indexに対して検索を掛けて、一致したドキュメントだけをnew_indexにコピーすることができます。

POST _reindex
{
  "src": {
    "index": "old_index",
	"query": {
	  "match": {
	    "user": "twitter"
	  }
	}
  },
  "dest": {
    "index": "new_index"
  }
}

たとえばHTTPサーバのアクセスログを全部投入したうえで、
検索APIへのアクセスだけを別indexに入れて細かく検索条件を分析するだとか、
ログインしたユーザとそうでないユーザでindexを分けて異なる分析をする、
ということができるようになります。

同じような形で、もう一つ追加されるのが、Update by Query API。
これはindexに対して検索を掛けて、一致したドキュメントを、指定した条件で更新するというものです。

Ingest Node、Re-Index、Update By Queryを組み合わせれば、とにかくいったんElasticsearchにデータを投げ込んでおいて、
後で加工しながらindexを分ける、ということができるようになりそうです。

この辺りは実際にどういう形になるのかもう少し先にならないと分からないのですが、
何にせよElasticsearchにログを流し込むアーキテクチャをよりシンプルにできるものだと思います。

新機能その2、Java Http Client。

もう一つ、目が離せないのがJavaのHTTP Client。

Elasticsearchは標準で9200番ポートと9300番ポートの2つを利用しており、
9200番ポートがHTTP用（RESTクライアント用）、9300番ポートがクラスタ間通信の独自プロトコル用で使われていました。
それでcurlコマンドやSenseなどからは9200番ポートを使い、Javaのクライアントは9300番ポートを使っています。

9300番ポートの方がHTTPのオーバーヘッドがない分、パフォーマンスが良いと思うのですが（計測したことはないです）、
その反面、9300番ポートを使うJava APIのライブラリには、Elasticsearchサーバで必要なクラス群が含まれていました。

だって、元々クラスタ間通信のためのポートですからね。

今回、Java用に9200番ポートを使ったHTTP Clientができるおかげで、フットプリントの小さなJARライブラリができることになります。

f:id:acro-engineer:20160218181425j:plain:w480

また、Java APIは頻繁に（バージョンアップのたびに）APIが変わっていたのですが、HTTP APIは比較的安定していました。
特にJava APIを使う外部ツールを作っていた場合には、バージョンアップに追従するのが大変だったことも、一つの問題になっていました。

そういう点でも、HTTP APIがJavaでも使えるようになる恩恵は大きいと言えますね。

まぁこれだけ説明してきましたが、本音で言えば「やっとかよ、最初から作っとけよ！」なんですけどね！（笑）

その他は・・・

あとはk-dimensional treeを使ったPoint field encodingを数値型や日付型に対して行うことで、
データサイズの削減や検索パフォーマンスの向上、ヒープサイズの削減などが行われます。

f:id:acro-engineer:20160218181353j:plain:w480
この辺りあまり詳しくないので仕組みはよく分かりません、すみません。

そんなElasticsearch 5.0のalpha版は、まもなくダウンロード可能になるとのこと。

f:id:acro-engineer:20160218181632j:plain:w480

とにかく、早く試してみよう！

レポート一覧

AcroquestではElasticsearch、Logstash、Kibanaの無償ハンズオンセミナーを開催致します。

当社公認エンジニアがELKの基礎から、商用プラグインの利用、
実データを用いた可視化・分析までを、ハンズオン形式で説明致します。
可視化・分析の題材には、当社がミャンマーにて収集したビッグデータを用います。

詳細・参加応募はこちらからお願いします。
www.acroquest.co.jp

最近のElasticsearch 2.xは？

新機能その1、加工や更新のためのAPI。

新機能その2、Java Http Client。

その他は・・・

レポート一覧

1日目

2日目

3日目