Scaling SOLR on Amazon EC2 - go big Posted by Barnaby on 29 July 2011 | 19 Comments Tags: SOLR, EC2, Scaling, Search, price per search, performance, solr benchmarking Running solr on Amazon ec2 presents new challenges and opportunities in picking the best way to arrange your indexes across multiple instances. This post looks into ec2 sizing, performance and benchmarking. Just as with traditional
Solr勉強会でElasticsearchを発表(ゴリ押し)してきました 資料: solrとelasticsearchの比較 // Speaker Deck サンプルにつかったRailsのコード:https://github.com/penguinco/ld_gourmet_search 文章の追加から、検索まで書いたのは100行無いと思いますのでさくっと試せます。 勉強会の内容については以下の方々が詳しくまとめてくれています 第9回Solr勉強会に行ってきた #SolrJP 第9回Solr勉強会を主催しました。#SolrJP | @johtani の日記 今回思ったのはkuromojiいいですねっていうことと、 jettyのマルチテナントを活用した開発環境の紹介は非常に勉強になりました。こういうのがないと開発者が多い場合に大変ですよね。 あとは、懇親会でいろいろな方がSolrをいろんな用
Live suggestions as you type into a search box, sometimes called suggest or autocomplete, is now a standard, essential search feature ever since Google set a high bar after going live just over four years ago. In Lucene we have several different suggest implementations, under the suggest module; today I'm describing the new AnalyzingSuggester (to be committed soon; it should be available in 4.1).
概要 Lucene/SolrのMoreLikeThisを使うと、Solrサーバ内に登録された文書の中から類似文書を探すことができる。 例えばニュースサイトの情報などをクロールしてSolrサーバに入れておき、後で「この記事に似た記事を探してこい」と命令すると、類似の記事を一覧で返してくれる、といった機能が作成できる。 本記事は試しにSolrにWikipediaの全日本語記事を放り込んで、いくつかの記事に対して類似文書を取得させてみた結果を羅列したものです。 パラメータ等について Solr3.5.0使用。mltのパラメータはmlt.count=10, mlt.maxqt=100, mlt.maxntp=10000, mlt.mindf=1, mlt.mintf=1を指定。mlt.maxqt=100はやり過ぎだろうか。クエリ投げてからレスポンス返るまで3〜5秒くらいかかる。 インデックスはluc
Solr.pl All things to be found – Blog related to Apache Solr & Lucene projects – https://solr.apache.org As Lucene and Solr are slowly showing up on the horizon I decided to take a look at another Solr feature which may be very useful for users – partial document update. Solr Version In order to test partial documents update functionality I used the upcoming Apache Solr 4.0 alpha. Assumptions Lets
Lucene入門 4章続き。前の記事でQueryParserを使ったQueryオブジェクトの作り方について書いたので、今回はQueryオブジェクトを直接newして生成するやり方について。 Queryオブジェクトを生成するといってもQueryクラスは抽象クラスなので、実際はサブクラスを生成することになる。サブクラスはQueryクラスのJavaDocを見てみればわかるように、とても沢山ある。ので、一部のみ抜粋してサンプルコードを書いてみた。なおLuceneのバージョンは3.6です。 検索対象は、以前作成した書籍データのインデックス。 TermQuery もっとも基本的なクエリ。フィールド名とTermのペアを指定する。 【コード例】 summaryに単語"プログラミング"を含むドキュメントを検索する。 Term term = new Term("summary", "プログラミング"); Que
{{{#!wiki red/solid This page is outdated and you should read about SolrCloud at the Solr Reference Guide instead: https://cwiki.apache.org/confluence/display/solr/SolrCloud. }}} http://people.apache.org/~markrmiller/2shard4serverFull.jpg SolrCloud SolrCloud is the name of a set of new distributed capabilities in Solr. Passing parameters to enable these capabilities will enable you to set up a hig
AI-POWERED SEARCH AND DISCOVERY PLATFORM Bring your search into the AI era. And your revenue with it Transform mountains of data into meaningful experiences in real time Get a Demo Grow faster by delivering AI-powered search that understands user intent and improves real-time digital experiences. Data-driven decision-making: the competitive advantage you’ve been missing. Join hundreds of the world
FunctionQuery allows one to use the actual value of a field and functions of those fields in a relevancy score. What is a Function? A function can be: A Constant (numeric or string literal) - See "constant" and "literal" below. A Field - See "fieldvalue" below. Also see notes later on multivalued/vector fields. Another Function Solr4.0 A parameter substitution: $arg, where arg is another function
先日、Lucene/Solrのbranch_3x(3.6)とtrunk(4.0)にコミットされた日本語向けのトークナイザ・トークンフィルタをご紹介します。 LuceneのJIRAのチケット LUCENE-3305 にて、日本語形態素解析器Kuromojiが導入されました。 これにより、日本語ドキュメントに対して形態素解析に基づく単語分割が可能になります。 従来、Lucene/Solrで日本語対応をする場合は、lucene-gosenやSenを使用する方法などをとってきましたが、今回の対応であらかじめLucene/Solrに組み込まれたものを使用するということが可能になります。 また一方で、LUCENE-2906にて、CJK文字に関するトークンフィルタも追加されました。 本記事では、これらのトークナイザ・トークンフィルタに関して、2012/2/23時点のソースに基づいて調査したものを解説いた
概要 全文検索エンジンとして有名なLucene/Solr。 この子を使って日本語文書のインデックスを作成したい場合、形態素解析かNgramを用いるのが一般的。 Ngramを選択した場合に良く利用されるのがCJKAnalyzer。日本語や英語なんかが混ざった文章を解析する時にはそこそこに便利。 ただ、その仕様や作成されるインデックスのサイズが必ずしも要件に合うとは限らない。これを自前で改変できるようになれば、用途に合った、よりコンパクトなインデックスが作成されるんじゃないだろうか。 そんなことを思ったので、気の向くままに「1文字をインデックスに入れない」とか「カタカナはBi-gramでなくまとめて登録する」とか「顔文字の検索を考慮する」などを試してみた。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く