【Elasticsearch】できることは何か概要をざっくりまとめる【覚書】


はじめに:調査方針と調査のゴール設定

具体的に何ができるのか、こだわって調べたこと

まず何ができるか、何に活用できるか、ランニングコスト(学習コスト、導入コスト、金銭面のコストなど)を調べてみます。

  • 何ができるか
  • 何に活用できるか
  • ランニングコスト(学習コスト、導入コスト、金銭面のコストなど)
  • ソフトウエアの生存期間

何ができるかは、それの具体性だけでなく、流れの中の範囲。入りと出のデータ内容も踏みたいですね。

Elasticはどういう立ち位置になるのか、前後左右、そして上下の関連性を整理することにより、姿をはっきりさせたいと思います。

できれば、最後に特徴を端的に一言でまとめたいと思います。

大まかな立ち位置:メイン機能

調査のスタート地点として、おおよその立ち位置をはっきりさせます。
Elasticsearchの主な機能は全文検索ができることです。

全文検索するとはどういうことか

全文検索とは、1つのファイルの検索だけでなく、複数のファイルつまり文書を対象にした検索方法です。 全文検索 - Wikipedia

Elasticsearchにどういう役割を任せられるかをはっきりさせるために、立ち位置として、前後の関係を整理したいと思います。

構成と前後の関係性

まず、全文検索自体の構成です。一概に全文検索は検索すればいいんでしょと思いがちですが、意外と複雑な構成です。

データ投入
文書登録
クローラ
文書フィルター
索引準備
構文解析・分かち書き N-gram
インデックスフィルター
index
storage

検索エンジンについては、2008年ごろの記事ですが、以下の記事がとある検索エンジン開発者本人の記事なので実践的です。また、設計ポイントもユースケースを交えてわかりやすく書かれています。 全20回ですが、30ページぐらいで概要がわかるのでさらっと読んでみてはいかがでしょうか?

検索エンジンを作る:連載|gihyo.jp … 技術評論社

http://gihyo.jp/dev/serial/01/make-findspot

検索エンジンの常識をApache Solrで身につける (1/4):ビッグデータ処理の常識をJavaで身につける(1) - @IT

https://www.atmarkit.co.jp/ait/articles/1111/18/news148.html

主に、データを投入するところ、索引を作るところ、検索するところの3部に分かれています。

準備フェーズ:索引の作成

フェーズ 役割・機能概要
データの投入 GoogleのようなWebタイプではクローラ、社内や特定サービスのシステムでは、各システムの連携やファイルの登録などデータの投入を行います。
文書フィルター ここでは、pdf, word,htmlなどから、検索しやすいようにテキストデータを抽出することです。HTMLであれば cssや スクリプトを除外します。ユニコードがあるおかげで最近は、だいぶ楽になりましたが、Shift_JIS,など文字種の判定も重要になってきます。最近はメタデータ、分類だとか、作成者だとか、日付、タグなどのデータもにゅうりょっくすべきポイントです。検索しやすいとは、人間的、システム的な話で、後段との連携に因ります。
構文解析
(Analyzer)
インデックスの一環です。インデックスの単位に合わせて分解します。おもに構文解析です。アジア圏のような1文字の重みが違う単語と欧州のような単語ではインデックスの作りが変わってきます。主流の方法に、都度全文検索は一般に使用されなく、インデックス方式のN-gramと形態素解析()を行います。メリットデメリットは後述します。
インデックスフィルター 使いやすくするため(スピード、サイズ、UI的)に少しインデックスのキーとなる単語を調整します。日本語には、索引を作るほどではない助詞がありますのでそれを除くだとか、”打合せ”や"東京都と京都","キューイフルーツ"など文字の揺らぎや、意味の似たもの、まったく違うものに対する扱いを整理します。現在毛糸過去形の違い、合成語、助詞の活用表現。英語では複数形などです。
インデックス 単純にテキストのまま保存しても、実際検索時には膨大な時間がかかるので、indexという目次機能を作ります。実際には、すべてのキーワードに対する目次が理想です。ディスクサイズ、性能、検索のしやすさに合わせて設計します。
検索文投入 検索文の投入です。タグなどのプロパティやメタ検索。AND OR検索などです。
検索結果の表示 検索結果を表示します。100万件のデータを検索自体の効率化も重要ですが、人間が見て検索を調整できるような機能、ランキングソート、部分データのみの返答など多様にあります。

使うとき

検索文
Storage

検索文とはキーワード検索やタグなどのメタ検索の指定方法です。

実際の検索対象は日々増えることになります。 indexはリアルタイムに、メンテが少なくできるのが理想です。

文書のフォーマットは多様にあるうえ、検索に影響しないほうが望ましいので、分割したり、外部モジュールが使えると便利です。

検索文については、上記の表で話しました。構文解析から索引作成についてはメインの機能なので、Elasticsearchの話に戻る前に、そこをもう少し深堀します。

インデックスの単位とインデックスの方法

分かち書きと、N-trigという方法があります。仕組みを理解して、採用のメリットデメリット、採用方針まで説明します。

分かち書き

英語の場合、単語の切れ目がはっきりしています。昔ははっきりしていなかったので、文字が読める人でも、誤解が多かったようです。aのような定冠詞で始まる単語が1単語になったりと名残が少しあります。

日本語のような場合は、空白や句点等ですべて判断できるわけではないので、漢字より文字種の少ないひらがななどの境目を利用して分割します。

今日も いい天気 ですね。

5段活用や送り仮名もあるため、辞書も必要になります。辞書が必要ということは、リアルタイムに言葉が増え変わっていく分野では、使いづらいということになります。

いい天気を 1つとして扱うのか、2つとして扱うのかという違いがあるので、そこについて工夫が必要です。全部取り込めればよいです。

この方式は、日本語に対する精度は高いものの、漏れも多く、言葉の揺らぎにも影響します。揺らぎ自体は、次の方式も影響を受けます。揺らぎ専用の辞書で、集約させる方法でデメリットを抑制します。

データの追加の時はそれほど影響しないのですが、構文解析を改良すると索引の作り直しが発生します。

専門用語が出てくる分野であれば、デメリットはそれほど出てきませんし、検索結果の精度が高いです。ただグローバル対応を考えると厳しいです。

日本では分かち書きタイプの全文検索では、Namazuが有名です。ただスケールしない、word等のフォーマット投入時にプロセスが独立していないなどのデメリットがあるようです。

N-trig

ほぼほぼ、全文検索と同じです。例えばテキスト文書を任意の2文字ごとに切り出し、索引を作ります。この2文字でわけることを2-trigで、同様に1文字、3文字があります。10文字の文書を2-trigで作ると5つではなくて、9パターンあります。1-trigの10文字と合わせて 約20パターン用意します。

検索のキーワードもこれに合わせて2文字に分割します。そのあと検索し、全て含まれていれば対象の文章となります。

キーワード毎に検索するのであれば、キーワードでソートされているとメモリ・ディスクアクセスの局所性が高まります。

検索の精度や、検索語周辺の情報が取れるよう 文書ID:出現箇所を保持しています( 転置索引方式:文書からキーを抜いた後、逆にしてインデックスしている )。出現箇所は文書の前のほうが価値が高い想定で、最初の一つだけです。複数にしても対象の文書を見つけること自体には影響は少ないでしょう。検索ランクに活用できますが、索引データはさらに複雑になり、検索性能が下がることが予想されます。

メリットとしては、漏れがなくなることです。ただゴミとなる価値の薄い情報を(ノイズ)拾ってしまったり、京都を探したとき、東京都が引っ掛かりやすくなってしまうということがあります(単語の類似性とニュアンスの類似性の乖離)。そのため NOT検索やメタ検索との組み合わせが実用的には必要となりますし、検索結果を見て、随時インタラクティブに修正するUIが重要です。

デメリットとして他には、索引のデータが大きくなるため、ストレージ容量、検索性能が重要になります。 また部分検索として、少しは動作する程度で完全な動作の期待はできなくなります。

Oracleの全文検索もこの方式を採用してました。

両方の特徴として、索引化により早くなるものの、索引用の準備に時間がかかり、ストレージ容量が必要になります。

個人的に何を採用するかという観点では、変化に強く漏れの少ない2-trigで、ランキング精度をどれだけあげられるかがポイントではないかなと思います。両方採用しても、デメリットばかり強く出てしまうので難しいところです。

Elasticsearchが担当するところ

話を少し戻します。
構成として、Elasticsearchではこの中で、主に形態素解析と検索文をもとに検索結果を返すところを行います。

もう少し詳細で具体的に注目すべき機能は?

Elasticsearchはレシピ検索を行おうとして、開発を始めたようです。

ここで、焦らずにレシピ検索をイメージしてみましょう。ユースケースから具体的なイメージ(要件や機能)を膨らませていきます。

  • お肉が食べたいときは、お肉を、野菜を取りたいときは野菜で検索しますね。
  • 素材が余ったとき、旬の食べ物のタケノコやキャベツ、サバが食べたくなった時は素材で検索します。
  • 今日は中華食べたいとか、鍋食べたいとか、ジャンルを検索しますね。
  • 麺類だけどちょっと飽きたなというとき バリエーションが知りたいです。
  • 試験前、試合前、発表前など、大事な時は精力を付けたいですね。その時はシチュエーションで検索します。

このように文章だけでなく、プロパティ検索が重要なのが見えてきます。

Elasticsearchでは、プロパティ検索ができそうだと予想できるでしょう。

要件

ついでに、必要な機能確認の前に、要件を見てみましょう。

  • 日本語や多言語対応
  • 日々増えるデータ
  • 多様なデータフォーマット
  • 誰が、日付が検索できるプロパティ検索
  • 検索性能(検索結果件数取得、サブセット抽出など)
  • メンテナンスの容易性
  • 誤記・揺らぎに対応した機能
  • わかりやすい検索結果(検索のソート、ランキングの調整)

これらのポイントを意識して、それぞれの機能の柔軟性や拡張性をチェックします。

第1回 エンタープライズサーチと6つの罠 - ITmedia エンタープライズ

調査会社の米IDCによると、企業内の情報検索に従業員の就業時間の約3割を(検索結果の分析まで含めるとそれ以上の時間を)費やしている

https://www.itmedia.co.jp/im/articles/0712/06/news146.html

Elasticsearchにある機能、ない機能

Elastic はちなみに 伸長とかいう意味です。 Elastic Stackとして売り出していることからも おそらく、柔軟性や連動性を意図したかったのでしょうか?

Elasticsearch はLucence をベースに開発されてます。先のそちらの機能を軽く見てみます。

Lucence を導入すればいい?

上記構成に関連した 大まかな機能を調べてみました。 Lucence はあらかじめ蓄積した大量のデータから、指定したキーワードを探し出す機能を持つ ようです。

FAQを見ると、

構成部分 機能
データ投入
索引作成
indexスピードは速く(150GB/h)。
analyzer機能を複数装備(空白区切りなど)
HTML , pdfなどは parse してテキストを Lucence に投入して indexする。
index aliasを持つ。
検索 レプリケーション機能、hilight機能、*,?に対応
スコアリングについては探せませんでした。おそらく出現頻度や単語間の距離、単語の一致割合などで計算していると思います。

Apache Lucence(るしーん?) の情報は以下が参考になります。内部はcoreなindexing, search部分と、検索結果Solr(API検索、ハイライト機能もある)があります。Solrについては未調査です。

Elasticsearch

index

構造

データの投入、RDBのようなテーブル形式の作成、データの投入、データの検索ができます。

概念的・論理的にストレージの箱をインデックス、データの種類をタイプと言うようです。データのフォーマットを表現していますね。RDBでいうテーブル相当に当たるかと思います。

データフォーマットはjson形式が可能で、NoSQLとしても使えます。json形式なので、階層構造が可能で、日付やジャンルなどプロパティ情報を用意できます。

それぞれのプロパティをフィールド、個々のテキストデータをドキュメントと言います。 スキーマレスと呼ばれる所以です。またインデックスによりマルチテナントの実現を支援していると思います。

インデックス > タイプ > フィールド > ドキュメントのような階層構造です。

Node/shardが何かを話すため、物理的な話もついでに話します。

indexA
shardA-primary,shartA-replica
indexB
shardB-replica,shartB-primary
<=>
cluster
NodeX : 物理サーバX
shardA-primary,shartB-replica
NodeY: 物理サーバY
shardA-replica,shartB-primary

shard(かけらという意味)で、primary shardと replica shard に分けることができ、indexの実体を複数の物理サーバに分散させます。

Node(物理的:サーバ) は物理的なサーバです。
その複数のNodeの集合を clusterといいます。

ただ、1つの物理サーバに、複数のindexのshardを載せることができるので、2台で 2index , 2shard (計4shard)を載せることもできます。Nodeを増やすと自動で設定した割合でshardが再配置され分散されます。1Node 1shardまで分散可能です

cluster単位が何を表すのわかりませんが、今回の機能性の範囲外なので調査はそのままにしてます。

index > shard です。また cluster > Node > shard 同時にという関係でもあります。
(左 > 右 が 1:nの関係)

データの投入

テキストとして投入するようです。json形式(先ほどのタイプ)でdocumentとして、投入します。indexは自動的にしてくれそうです。

pdf ,wordなどからの投入は、
Apache Tika xdoc2txt というライブラリがあるので、もし Elasticsearchがなくても、それほど心配ありませんね。

そのほか、windows系であれば、iFilter方式もあります。

データ投入時の揺らぎ・誤記等はは、index alias機能があります。

地理的情報も検索できるようです。N-trigとしてやっているのでしょうか?おそらく、数値そのままでは、計算コストが高いので、地球上の全領域を適度に分割したkey(文書IDの代わり)にしているのかもしれません。

Analyzer

日本語を使うのであれば、Kuromoji,Gosen,Sen,CJKAnalyzer,JapaneseAnalyzerなどがあるようです。

検索エンジンの常識をApache Solrで身につける (4/4):ビッグデータ処理の常識をJavaで身につける(1) - @IT

現在無料で利用できる形態素解析器としては「Sen」「Gosen」「Kuromoji」が有名です。また、Basis Technology社が提供するトークナイザも有料ですが利用できます。

https://www.atmarkit.co.jp/ait/articles/1111/18/news148_4.html

Apache Lucene - Wikipedia

日本語のデータをインデックスするためには、CJKAnalyzerかJapaneseAnalyzerを使う。CJKAnalyzerはbi-gram方式である。JapaneseAnalyzerを使うには形態素解析エンジンを組み込む必要があり、2014年現在ではオープンソースのSen(MeCabのJava実装)ベースの「lucene-gosen」、同じくオープンソースのKuromojiベースの2種類の実装がある。


https://ja.wikipedia.org/wiki/%E5%BD%A2%E6%85%8B%E7%B4%A0%E8%A7%A3%E6%9E%90

検索文

json形式で、階層構造のプロパティも検索キーに複数同時に指定できます。and/or/notをサポートしています。RESTfulなので拡張性も高いです。

検索結果

検索結果を見ると N-trig方式をベースにしたようで、出現頻度、検索語同士の距離情報を返します。こちらもjson形式なので、それぞれのデータタイプにあった状態を把握しやすいです。

検索ヒット件数や、ページング(結果のサブセットの取得)もできるようです。

検索

検索に時間がかかるので、検索する部分について、レプリケーション機能があり、分散処理できます。つまり、スケールアップ機能があります。

具体的な操作例サイクルは、以下のサンプルがわかりやすいです。

はじめての Elasticsearch - Qiita

https://qiita.com/nskydiving/items/1c2dc4e0b9c98d164329

Lucenceですが 1000万ドキュメントを処理可能だそうです。

その他

クラスターごとにユーザを設定できるようなので、マルチテナント性があるという意味かと思います。

採用に見合うか?

主な機能は以上です。機能的に使えるかという点で、どういうところまでElasticsearchが対応できるか見えてきたと思います。

次は、実際に使えるか、長期にわたって使えるかの視点で、情報を補足します。

ドキュメント・情報

あまり情報が内容で、逐一問い合わせないといけないかもしれません。
VideoやWebinarもありますが、契約して問い合わせしないとスピードが出ないかもしれません。

初期導入は難しくなさそうですが、少し凝ったことをやろうとすると学習コストは高そうです。

実活用例

ログ解析

logstash/fluentdなどの機能で、ログを転送し、データを抽出してElasticsearchに投入しているようです。監視機能によりalertを上げたり、必要な個所のデータを全文検索でフィルタリングして抽出し、そのままみるか、Kibanaを通じてGraphical化しているようですね。そのほかの見える化が具体的には調べ切れれてません。

経営情報の共有

情報に関する、在庫管理情報などを Elasticsearchにストレージのように使い、業務に即した適当なパターンで検索できるインタフェースを用意し、社員全員で見るなどしているようです。

導入事例

活用例、信頼性の面から、導入事例が参考になります。

導入事例 | Elastic Customers

https://www.elastic.co/jp/use-cases/

Apache Lucene/Solr はIBM WebSphere Commerce, Salesforce, Microsoft Azure, SAP Hybris, 楽天などで利用されている。

リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか (1/2):Elasticsearch+Hadoopベースの大規模検索基盤大解剖(1) - @IT

SolrからElasticsearchへ

https://www.atmarkit.co.jp/ait/articles/1507/08/news009.html

Elasticsearch - Wikipedia

Wikimedia,[4] Facebook,[5] StumbleUpon,[6] Mozilla,[7][8] アマデウスITグループ, Quora,[9] Foursquare,[10] Etsy,[11] SoundCloud,[12] GitHub,[13] FDA,[14] 欧州原子核研究機構,[15] Stack Exchange,[16] Netflix,[17] Pixabay,[18]Sophosなどがある。

https://ja.wikipedia.org/wiki/%E6%AC%A7%E5%B7%9E%E5%8E%9F%E5%AD%90%E6%A0%B8%E7%A0%94%E7%A9%B6%E6%A9%9F%E6%A7%8B

コスト・制限・ライセンス

無料
ライセンス Apache License 2.0

・ソフトウェアの使用や頒布、修正、派生版の頒布をすることを制限しない
・ 頒布される二次的著作物が同じライセンスで提供されたり、フリーソフトウエア、オープンソースソフトウェアとして頒布されることを要求しない
・使われていることを知らせる文言を入れる
・ ライセンスされたファイルそれぞれに元々ある著作権と特許権の記述はそのまま保持されなければならず、何らかの修正が施されている場合は、その旨を追加記述しなければならない。

実績・継続性

Apache Lucence は元々1999年 Doug Cutting (Hadoopの作者)により作られた 2007年 Apache トッププロジェクト、  2019年 ver 8.0リリース。

開発元のShay Banon Elastic Co. はオランダで2010年に創業したようです。2013年にKibanaとLogstashが製品ラインに2014年にElasticsearchが1.0として公開。2019年現在 ver 7.0がリリースされています。

Elasticsearchを開発するElastic、最新バージョン5.0とElastic Stackを解説 | Think IT(シンクイット)

2010年の創業からの6年間に行った買収や社名変更などを説明した。この中では2013年にKibanaとLogstashが製品ラインに加わったこと、2014年にElasticsearchが1.0として公開された

https://thinkit.co.jp/article/11234

Elastic 社は2018年で 1.5億ドル程の収入(Revenue:売上)です。前年比⁺82%です。利益(Net income: 税引き後純 )は50百万ドル。スタートアップから立ち上がりつつありますが、利益率、従業員の減少から判断すると、やや不安定さが残るように見えます。

Elastic company profile - Office locations, Competitors, Revenue, Financials, Employees, Key People, Subsidiaries, News | Craft.co

https://craft.co/elasticsearch

Elasticsearchの日本法人をたて、パートナーを募集しているので、サポート等も安心かもしれません。Elasticseach自体はやや実績が不足しているように見えますが、元となるlucenceの開発実績は長く、 Elasticseach は多くの有名の会社で採用されているようです。

ElasticのCEOと日本代表、日本での事業計画などについて語る | Think IT(シンクイット)

https://thinkit.co.jp/article/13299

まとめ

データの投入、可能な検索フォーマット、インデックスに関する機能、検索に関する機能など輪郭がかなり明確になりました。(自分だけかもしれない)

色々感じたところによると、Elasticsearchはフリーフォーマットに対応した検索ストレージだ! そして、柔軟な検索機能を備え、負荷に耐えられる

おまけ:その他

あいまい検索

N-trigとは違いますが、正規表現や距離の関数(diff方式)、ニュアンスによるグルーピング、推薦アルゴリズムなどあります。

曖昧検索asearch - 増井俊之

https://scrapbox.io/masui/%E6%9B%96%E6%98%A7%E6%A4%9C%E7%B4%A2asearch

diffの動作原理を知る~どのようにして差分を導き出すのか:一般記事|gihyo.jp … 技術評論社

http://gihyo.jp/dev/column/01/prog/2011/diff_sd200906


Delicious にシェア
Digg にシェア
reddit にシェア
LinkedIn にシェア
LINEで送る
email this
Pocket

343 views.



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です