どこにでもいるSEの備忘録

たぶん動くと思うからリリースしようぜ

【読んでみた】Elasticsearch実践ガイド

最近少しずつElasticStackの勉強をしています。

nogawanogawa.hatenablog.com

nogawanogawa.hatenablog.com

nogawanogawa.hatenablog.com

nogawanogawa.hatenablog.com

その中でも、コアに当たる製品がElasticSearchで、正直こいつを使いこなせるかどうかで、ほかの製品の価値もだいぶ変わるのかなと思っています。 というわけで、こちらの本で勉強してみました。

Elasticsearch実践ガイド (impress top gear)

Elasticsearch実践ガイド (impress top gear)

ElasticSearchとは

基本的なところは過去に書いたはずなんでそちらをご参照ください。

nogawanogawa.hatenablog.com

nogawanogawa.hatenablog.com

今回は追加でElasticSearchの特長についてまとめます。

Elasticsearchの用途

この本では、

と紹介されています。文書あるいはログデータの収集が主に想定されているようですね

Solrとの比較

よく類似製品としてApache Solrと比較されてたりします。 比較するとこんな感じです。

Elasticsearch       Solr
言語 Java Java
Lisence Apache Lisence 2.0 Apache Lisence 2.0
開発組織 Elastic社 Apache Software
登場 2010年 2004年
バックエンド検索ライブラリ Lucene Lucene
クラスタ構成時の調停方式 内臓のZen Discovery Zookeeper
シャード数の変更 インデックス作成後は変更不可 インデックス作成後も追加は可
シャードの自動リバランス 不可
可視化 Kibana Banana

実際使用されている量としてはこんな感じですね。

f:id:nogawanogawa:20190508122223p:plain

db-engines.com

機能については、かなり似ていますが、人気としてはもはや、Solrに圧勝している形になっています。 全文検索エンジンというカテゴリではデファクトスタンダードといっていいでしょう。

全文検索の仕組み

全文検索はこんな感じの動作をするようです。

f:id:nogawanogawa:20190511191355j:plain:w600

サーチャー、インデクサー、クローラーから構成されます。

インデクサは対象ドキュメントから検索キーワードとなる単語を抽出します。 サーチャーは、構成したインデックスに基づいて検索機能を実現します。 クローラは定期巡回などによって検索対象のドキュメントをサーチャーに渡します。

特に、インデクサによって検索対象のインデックスを構成する検索手法は索引型検索と呼ばれ、ElasticSeearchも索引型検索を行っています。

Elasticsearchの概念

論理的なデータの概念については過去にやりました。

nogawanogawa.hatenablog.com

物理的な概念とその用語について見ていきます。

f:id:nogawanogawa:20190511192500j:plain:w500

  • ノード
    • Elasticsearchが動作する各サーバ
  • クラスタ
    • 強調して動作するノードグループ
  • シャード
    • インデックスのデータを異なるノードに分割保持する際の、分割したインデックスデータ群
  • レプリカ
    • シャードを自動複製したもの

この辺は、性能とか耐障害性とかの非機能要件関係の設定ですかね。

ざっくりとした性能要件

書いてある感じ、こんな感じだとちゃんと動くらしいです。

  • メモリ
    • 開発なら1-2GB
    • ちゃんとやるなら8-64GBでJVMのヒープサイズの上限は32GBにする
  • CPU
    • 2-8コアで十分
  • ネットワーク
    • 1GbEや10GbEなど高速なものを使用する

検索

全文検索エンジンって言ってるくらいだから、検索が一番大事なんでしょう。 ただ、検索といっても様々で、Google検索みたいなキーワードだけの検索だけではなく、ElasticSearchではより複雑な検索が可能になっています。

フィールド

検索に使用できるフィールドも文字列だけではなく、数値や配列、オブジェクトなど様々あります。

  • 文字列
    • text
    • keyword (完全一致のマッチングに使用する)
  • 数値
    • int
    • float
  • bool
  • object
  • array

この辺を組み合わせてそれぞれ適した形で検索を行うことが可能になっています。

クエリ

検索に使用するクエリの構成としてはこんな感じですかね。

{
"query":{<クエリ内容>},
"from": <検索を何件目から表示するか>,
"size": <検索を何件表示するか>,
"sort": <並べ替えについての指定>,
"_source":<検索結果に含めるフィールド>
}

query以降は検索結果のどこを使用するか(どう表示するか)を設定しています。

検索の条件指定自体はqueryの値にjsonとして指定していきます。

検索条件の指定クエリには大きく下記のような分類になるかと思います。

  • 基本クエリ
    • 全文検索クエリ
      • 文書が格納されているフィールドに対して検索を行う
    • Termベースクエリ
      • 指定したフィールドに完全一致するかの判定による検索を行う
  • 複合クエリ
    • Boolクエリ
      • 複数の基本クエリの条件を組み合わせる

Match

CRUDとかやり始めるときりがないので、本当に検索の基本だけ確認します。

個人的に、curlべた書きでElasticSearchを操作することがないので、Pythonで書いてみます。

Term

Matchだと、部分一致で検索にヒットしたんですが、完全一致のケースだけを検索でヒットさせたい場合があります。 そういう時はフィールドをkeywordにして、Termで検索を行うことで実現できます。

Term指定時はこんな感じで書くといけるみたいですね。

Mappingとかで準備していない場合でも.keyword句で指定するとkeywordとして検索してくれるようです。 そのため、.keyword句付けて、term句を使用すると完全一致での検索が可能になります。

感想

いろいろ勉強になりました。 比較的簡単に使えるツールだと思うので、バンバン使って慣れていきたいと思います。