Elasticsearchのための新しい形態素解析器 「Sudachi」 - Qiita
tl;dr （要約） Kuromojiに代わる新しい形態素解析器「Sudachi」 なにが良いの？ 最新の辞書 企業（ワークスアプリケーションズ）による継続的な更新 複数の分割単位 → 検索用途での再現率と適合率の向上 プラグインによる拡張 省メモリ Elasticsearchで使いたい プラグイン: WorksApplications/elasticsearch-sudachi 使い方は当記事の後半をご覧ください 注: この記事の執筆者はSudachiの開発に関わっています さまざまな形態素解析器 形態素解析は、伝統的な自然言語処理（Natural Language Processing, NLP）において基盤となる技術です。そして世の中にはさまざまな形態素解析器が存在します。販売されているものもありますが、一般に公開されているものだけでもいくつか例をあげると、JUMANとRNNLMを利
はてなブックマークに基づく関連記事レコメンドエンジンの開発
MySQLは広く使われているRDBMSです。速いし、レプリケーションのノウハウもあるし、Web上にたくさんの情報もあるからいざというときも安心、というのがその理由でしょう。 そんなMySQLの弱点の1つがデフォルトでは日本語で全文検索できないことです。でも、日本語で全文検索したいし。。。どうしよう。 そんなあなたに最近の日本語の全文検索事情を紹介します。Solr？Elasticsearch？Groonga？PostgreSQLはどうやっているの？Mroonga？Sphinx？ いろいろ考えると日本語で全文検索するときもMySQLを使うのがいいね！と思えてくるから不思議です。最近の日本語の全文検索事情を聞いて一緒に考えてみませんか？
Elasticsearch で作る検索エンジン ― 理論と実践 (1/2) | Wantedly Engineer Blog
こんにちは。エンジニアの岩永です。 先日 Wantedly では Elasticsearch と検索エンジンについて勉強会を開催しました。 概要 Wantedly が内部向けにやっている勉強会に20名様だけご招待。 63,000回。Google は一秒間にこれだけの検索をしていると言われています。 1.2年ごとに世界中の情報が倍になっている現代において、 検索はユーザが目的のものに素早くアクセスする手助けをしています。 情報に素早くアクセスできるというのはどんなサービスでも重要なことです。 しかし、検索エンジンを作ると言っても、実際に何に気をつけて作っていけばいいのかわからないという方も多いと思います。 今回の実践会では GitHub の I カバー画像は Elasticsearch 開発元である Elastic 社の Jun Ohtani さんがおみやげに持ってきてくれたグッズです。(あ
いろいろあって Elastic Cloud がオススメな件 - なんたらノート第三期ベータ
MySQLのインデックスの代わりにElasticsearchを使おうと思い立っていろいろやってみた結果、Elastic社のホスティングけっこうオススメなんじゃないかってなった話です。これです: www.elastic.co 経緯としては、AWSにのっけたサービス、とりあえずMySQLとRedisだけでやってきた仕組みが、そろそろノーキャッシュ新規クエリ単発で1秒以上かかる場合が出てきたというのがあります。 アプリケーションで決まったパターンの問い合わせだけやってるぶんには、問い合わせのパターン数だけ複合インデックを作ればいいし、負荷分散したければリードレプリカが簡単、ということでほとんどの場合MySQLでいいのですが... MySQLは個別のインデックス勝手に組み合わせてくれない、全パターン定義しないといけない 管理者が使う検索機能のよっては、想定したインデックスにうまくヒットしない条件に
Elasticsearchインデクシングパフォーマンスのための考慮事項 - Qiita
マッピングタイプを使いすぎないようにする Elasticsearchでは１つのインデックスの中に複数の異なるスキーマ定義を持つことができる。このスキーマ定義をマッピングタイプという。単に「タイプ」と呼ばれる事もある。フィールドのデータタイプとは別の概念。インデックスはデータベースに、マッピングタイプはその中のテーブルに例えられる事が多いが、同じ名前のフィールドはマッピングタイプが異なっていても定義が共有されたりして、データベースのテーブルほど互いに独立していない中途半端なものになっている。（2.0より前のバージョンではタイプごとにフィールド定義が異なっていても多少使えたりしたが、2.0以降は厳密に禁止されるようになった. 参照：Conflicting field mappings） タイプが異なっていてもデータは同じLuceneインデックスの中に混ざって入ってしまうため、タイプ間で互いに影
FRILの商品検索をnGramから形態素解析にした話 - mosowave
この記事はElasticsearch Advent Calendar 2015の7日目のエントリです。 こんにちは、ファッションフリマアプリFRILを運営しているFablicでエンジニアをしている@sinamon129です。 FRILの商品検索はElasticsearchを使っていて、最近nGramベースだったものを形態素解析ベースに変更しました。 その経緯やどういう手順で行ったかを書こうと思います。 主にユーザー辞書とsynonym辞書の構築の話がメインです。 どうしてnGramベースから形態素解析ベースに変更することになったか 関係ないものがなるべくひっかからないようにしたい nGramだとファーで検索したときに、ローファーやローリーズファームが引っかかり、本当に検索したかったものが出てこないという問題がありました。 （実際は出ているのだけども、埋もれてしまっている状態） 同じ意味の単
WikipediaのデータからElasticsearch用類義語辞書をつくる - Qiita
Elasticsearchには類義語によるクエリ拡張機能があります。これを適用すると まどマギ と検索したときに まどかマギカ と書かれた文書もヒットするようになります。 (LuceneやSolrにもありますがここではElasticsearchの話だけします) この類義語辞書は、人手で作ること (e.g., FRILの商品検索をnGramから形態素解析にした話 - mosowave) もできますが、今回はなるべく手間をかけたくないのでWikipediaのリダイレクトデータから自動で類義語辞書を作る方法を紹介します。 (自動といってもノイズも含まれてるので実用的に使うにはある程度人手でフィルタリングする必要があります。それでも一から人手で作るよりは手間が少ないと思います) (ElasticsearchではWordNetでの類義語検索に対応しているようですが、これを書いてる2015年12月時点
Elasticsearch Sever勉強メモ基本的な概念や基本API、マッピングについて
『Elasticsearch Sever』を読んで勉強をしたことの俺得メモです。今回は基本的な概念や基本API、マッピングについてです。 英語ですが、公式ドキュメント『Elasticsearch Reference [2.1]』も充実しているのでななめ読みしています！ 詳しい使い方は公式のチュートリアル『Tutorial - jq』あたりがお勧めです 🎃 Elasticsearchの基本概念Elasticsearchの論理的な構成要素検索で使うデータの構成要素のイメージ。 - インデックス - ドキュメントの集合体。リレーショナルDBのテーブルのようなもの。格納された値は、全文検索に最適化される。 - ドキュメントタイプ - 1つのインデックス内に複数のオブジェクトを格納できる。その区分のこと。 - ドキュメント - リレーショナルDBのレコードのようなもの。型(type)は自動で決まる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
