こんにちは。WEBサービス開発グループの中野です。 Elasticsearchでは、今後のバージョンアップで typeの段階的な廃止 が予定されていますが、従来 joinクエリ(has_child や has_parent)は複数のtypeを利用する前提の機能となっていました。 今回は、このtypeの仕様変更後にjoinクエリを利用する方法を確認したいと思います。 typeの段階的な廃止 ドキュメントでアナウンスされている内容を確認すると、今後の変更は次のような流れで進められていくようです。
Elasticsearchには、辞書形式のデータの配列(複数のプロパティを持つオブジェクトの配列)をインデックスする際に、Nested と言うフィールドタイプが用意されています。 インデックスする際にJSONデータの内容は同じでもNested型でマッピング定義されているのか?単にオブジェクトの配列としてマッピング定義されているのかで、検索やソートなどで動作が異なるので注意が必要です。と言うか検索要件によって使い分ける必要が有ります。 デフォルトのダイナミックテンプレートでは、単純にオブジェクトの配列としてマッピング定義されます。 Array Objects最初に、通常のオブジェクトの配列についての説明です。 BtoB向けのECサイトを例に、商品は顧客ごとに販売価格が異なる仕様だとします。 { "product_id": "A000001", "prices": [ { "customer_
こんにちは。ホリデー株式会社の内藤です。 ホリデー株式会社では Holiday(https://haveagood.holiday) という新規サービスの開発・運営を行っています。*1 以前投稿した記事でご紹介したように、Holiday では全文検索エンジンとして Elasticsearch を利用しています。 Ruby on Rails で構築されたアプリケーションから Elasticsearch を操作するには、公式 gem である elasticsearch-rails を使うのがとても便利です。 もちろん、Holiday でも活用させてもらっています。 大方の機能についてはこの gem で提供されるもので満足だったのですが、一点だけ、Holiday の運用をしている中で困ることがありました。 それが、サービス公開後のインデックスの再構築です。 elasticsearch-rails
リインデックスってどうやるんだろう?と思い調べていたところ、エイリアスの方が気になってしまったので先にまとめ。 インデックス・エイリアスとは?インデックス・エイリアスはその名の通りインデックスに別名をつけられる機能のこと、同じエイリアス名を複数のインデックスにつけることもできるし、1つのインデックスに複数のエイリアス名をつけることもできます。FAST ESP のサーチプロファイルっぽい!または、リレーショナルDBのビューみたい!なイメージの機能です。 実際の設定は、各インデックスに対してエイリアス名を設定するのですが、理解するイメージは下の図の方がイメージしやすいかと思います。 インデックス・エイリアスエイリアスを使わない場合は、直接インデックスを指定して検索するわけですが、クライアントからエイリアス宛に検索するようにすることで、検索対象のインデックスをElasticsearch側でコント
こんにちは。 エンジニアの伊藤です。 11/18に開催された第7回Elasticsearch勉強会にて「niconicoの検索を支えるElasticsearch」と題して、niconicoでのElasticsearchの運用事例について発表してきました。 発表の機会を与えてくださった@johtaniさん、スタッフの皆さん、ありがとうございました。 (この投稿は報告が遅くなっただけで、アドベントカレンダーネタではありません...) 使用したスライドがコチラになります。 https://speakerdeck.com/shoito/niconico-elasticsearch 講演では、まずElasticsearchを使った検索基盤を作った背景、 次に、なぜElasticsearchを使うことにしたのか? そして、どう使っているのか?どう運用しているのか? 最後に、良く参考にしているElast
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
株式会社クイックでアプリケーションエンジニアをしているhamanokamiです。 弊社ではあるシステムの検索機能でElasticsearchを使用しています。 ただチームメンバ全員がElasticsearchの知識を持っているわけではないため、 Elasticsearchに詳しくなくても、ある程度運用できるように設計を行っています。 その1つとして、無停止でのインデックス再構築フローがあります。 Elasticsearchを運用していると、途中でマッピング構造やフィールド型を変更したいことがあります。 その場合、サービスでは既存マッピングで検索機能を使用しつつ、 裏でインデックスを再構築を行うことで、サービスの質を保ちたいものです。 その方法として一般的なのは、エイリアスを使用した再構築フローだと思います。 (参考) http://techlife.cookpad.com/entry/20
今回のソリューション:【Found】 〜検索速度を大幅に改善する「Found」の使い方〜 日本最大級のクラウドソーシングサービス「クラウドワークス」を運営する株式会社クラウドワークス。同社ではクラウドソーシングサービスの肝である検索機能を強化するため、Elasticsearchのホスティングサービス「Found」を導入し、検索速度を10倍に向上することに成功した。 ユーザー体験を最上位に考える文化が根づく同社では、検索機能の強化という課題に対しても、ツールの選定からインフラの構築方法までの全てにおいてユーザー目線を大切にしながら取り組んでいる。同社でエンジニアを務め、Foundの導入を進めた九岡 佑介さんに詳しいお話を伺った。 目標はソフトウェア界の人間国宝! 私のキャリアの中で、クラウドワークスは4社目の会社です。新卒で社内SEのような仕事をした後にソーシャルゲームの開発をする会社に転職
これまでの記事でも Cluster や Node を始めとする Elasticsearch を構成する要素について触れているのですが、 文章だけでは理解しづらいところもあるので、今回は改めて Elasticsearch の基本コンセプトについて図も交えて解説したいと思います。 それではさっそく。 Cluster は Node の集合 Cluster は 1つ以上の Node (Elasticsearch Server) で構成されます。Elasticsearch は検索トラフィックの増加とデータ量や書き込み速度の分散を Node を増やすことで対応することができます。 Index は RDB の Database に近い概念 Elasticsearch の Index は、リレーショナル・データベースの Database に相当します。1つの Cluster に複数の Index を作成す
こんにちは。木内です。elasticsearchは分散アーキテクチャで可用性を確保するデータベースです。今回はelasticsearchクラスタでノード障害が起きたときに、どのような挙動を取るかについて解説します。 elasticsearchのプライマリシャードとレプリカシャード elasticsearchのデータを考える際に、キーとなる要素は「プライマリシャード」と「レプリカシャード」です。それぞれ以下のような役割を果たします。 プライマリシャード : ドキュメント(つまりインデックスに保存されるデータのうちの1つ)がelasticsearchに記録されるときに、あらかじめ定義された関数に従い、できるだけ分散されるようにプライマリシャードに配置されます。(elasticsearchクラスタの中に、インデックスごとに作成される)プライマリシャード数のデフォルト値は 5 です。 レプリカシャ
概要 Vagrant上にElasticsearchのクラスタを構築してfailoverを検証してみます。 環境 Ubuntu 14.04 Elasticsearch 1.4.4 Vagrant 1.7.2 以下の3台でクラスタを構築します。 ノード IP web1 192.168.33.10 web2 192.168.33.11 web3 192.168.33.12 Vagrantの用意 以下のコードをVagrantfileに追加して起動してください。 config.vm.define :web1 do |web| web.vm.network :private_network, ip: "192.168.33.10" web.vm.provider "virtualbox" do |vb| vb.memory = "1048" end end config.vm.define :web2
概要 Bool QueryとDis Max Queryの違いが曖昧だったのでちゃんと調べました。 環境 Ubuntu 14.04 Elasticsearch 2.2.0 データ投入 curl -s -XPOST localhost:9200/my_index/my_type/_bulk -d ' {"index": {"_id": "1"}} {"title": "Quick brown rabbits", "body": "Brown rabbits are commonly seen."} {"index": {"_id": "2"}} {"title": "Keeping pets healthy", "body": "My quick brown fox eats rabbits on a regular basis."} ' 上記のデータに対し、Brown foxというクエリを投
Elasticsearch の特徴の一つスキーマレス(事前のスキーマ定義なしにデータをインデックスできる機能)ですが、日本語ではなかなかこの恩恵を受けることが出来ません。アナライザーを日本語向けにカスタマイズしたり、一つのフィールドでも日本語、ファセット、などコンテンツの内容と、いろいろな用途で使用することを考慮して、マッピング定義を設計する必要があるからです。 せっかくスキーマレスな検索エンジンなのに毎回マッピング定義をいちいちするのもめんどいと思うのは私だけでしょうか?と言うことで、動的マッピングを使って日本語でもスキーマレス環境の構築を考えたいと思います。 目指すは、検索の高度な知識を習得しなくても簡単に使える環境! 使用する主な機能日本語環境でもスキーマレスな環境を手に入れる為に以下の機能を使用しました。 インデックステンプレート(Index Templates) インデックステン
本投稿は、Elastic stack (Elasticsearch) Advent Calendar 2016 の2日目の記事かつ、以前書いた以下の投稿の続編。 Elasticsearch の analyzer 関連の設定で知ってることを全て書く Elasticsearch多言語化その1 背景等 以前書いた内容と重なる部分もあるが、背景等について説明しておく。 Elasticsearch を、各種開発者向けサービスの横串検索用に使用 GitHub, Slack, Google Drive 等のデータを API 経由で取ってきて、Elasticsearch に入れて、それを横串・一括検索出来るようなツールを作っている。元々は内部向けのツールだったが、ぼちぼち体裁等が整って来たので、現在β版的な感じでひっそり公開中。(今年中にはちゃんと公開したい。) 詳細はこちら → GitHub も、Sla
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
今日はクエリ周りについて学んだ。 Query contextとFilter context Query and filter context | Elasticsearch Guide [8.0] | Elastic ElasticSearchのクエリにはQuery contextとFilter contextというのがある。簡単にいえばQuery contextで解釈されたクエリはスコアに影響を及ぼし、Filter contextで解釈されたクエリはスコアに影響を及ばさない。 これらのcontextはBool Queryで概念として出てくる。こちらのドキュメントの例を見てみると、boolクエリのmustやshouldはQuery contextで解釈され、filterはFilter contextで解釈されるように見える。つまりmustやshouldに指定したクエリはスコアに関係し、fi
ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上:Elasticsearch+Hadoopベースの大規模検索基盤大解剖(2)(1/3 ページ) リクルートの事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する連載。今回は、テンプレートを利用したインデックス生成など、検索結果の品質を向上させるためのさまざまな取り組みを紹介する。 連載目次 リクルートの全社検索基盤「Qass」の事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する本連載。初回の前回「リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか
日本語の文章を形態素解析するときは、トークナイズする前に文字列の正規化を済ませて検索精度を向上させよう! この記事は、Elasticsearch Advent Calendar 2014 の18日目のエントリーです。即席で申し訳ないですが、なんとかまとめましたので是非最後までお付き合いください。 今回は、日本語形態素解析における文字列正規化のお話です。 それでは早速本題に。 非正規化された日本語の文章を形態素解析を使って、なるべく意図したようにトークナイズするためには、全角英数字を半角英数字に正規化したり、半角カタカナを全角カタカナに正規化したり、不要な文字を除外したり、単語ではなく、文字単位での正規化が重要になってきます。 Japanese (kuromoji) Analysis Plugin のページでも紹介されているように、全角英数字や半角カタカナの正規化には、CJK Width F
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く