タグ

2019年11月5日のブックマーク (5件)

  • プロダクトに日本語の全文検索機能を加えたい、検索インデックスのリアルタイム更新もほしい というときの手軽な方法 - Qiita

    プロダクトに日語の全文検索機能を加えたい、検索インデックスのリアルタイム更新もほしい というときの手軽な方法MySQL検索InnoDB全文検索mysql5.7 プロダクトオーナー や ユーザからの要望によって 検索機能 の必要性に迫られたとき、 ありふれた方法 でかつ 速攻 で実装する方法です 要件 日語文章 などのデータに対して、全文検索できる 検索リクエストに対して、十分高速にレスポンスを返す 検索インデックスはリアルタイム更新され、実データと相違がでない 検索対象のデータが追加/更新/削除されたら検索結果にも即反映される 希望 できるだけ速く実装/提供したい できるだけ運用コストも小さくしたい おすすめな方法 もしもプロダクトがMySQL互換のデータベースを使っていたら、要件を満たして 明日にも提供できる かもしれません(気持ちです、フロント周りの実装など事情によって当然コストが

    プロダクトに日本語の全文検索機能を加えたい、検索インデックスのリアルタイム更新もほしい というときの手軽な方法 - Qiita
    k-holy
    k-holy 2019/11/05
    既存テーブルに全文検索インデックス追加、または検索用テーブルを追加してトリガーで更新。正規化処理は必須となると検索用テーブルを用意すべきか。
  • MySQL5.7 InnoDB のN-gram全文検索を検証&サービス導入した

    ※ この記事は以前Mediumで公開した記事 の転載です MySQL5.7・InnoDB・N-gram という環境下で全文検索の挙動やパフォーマンスについて検証を行った。FULLTEXT INDEXは以前はMyISAMでしか利用できなかったが、 5.6.4からInnoDBでのサポートが始まっていた。 InnoDBの全文検索は5.7、特に5.7.6以降でいわゆるCJK(中国語・日語・韓国語)がN-gramで標準サポートされ始め、 CREATE TABLE文で簡単にパーサーを指定できる構文のサポート、 設定やクエリの組立で考えないといけない事が減った事で導入障壁がかなり下がっている。 ※4.1と5.0でサービス導入経験がある私の個人的な比較感想です。 FULLTEXT INDEXも他のINDEXと同様にデータ更新・削除の際にINDEXのrebuildが走るので更新時の負荷には注意が必要で、F

    k-holy
    k-holy 2019/11/05
    "「他INDEXが付与されたカラム」による絞込の方が効率的であってもそのINDEXは無視されて、FULLTEXT INDEXによる検索が実行される"
  • Regexp.ja

    解析前に行うことが望ましい文字列の正規化処理 辞書データを冗長にして異表記を吸収するのにも限界がある。 辞書データを生成する際には以下で述べる正規化処理を全て適用しているため、 解析対象のテキストに対して以下の正規化処理を適用すると、辞書中の語とマッチしやすくなる。 mecab-ipadic-neologd のエントリを生成する際の正規化処理 以下にmecab-ipadic-neologd のエントリを生成する際に、処理の各所に分散している正規化処理をまとめる。 生成時には色々置換と削除をしているが、最後に反映されているのは以下である。 全角英数字は半角に置換 0-9=> 0-9 A-Z=> A-Z a-z=> a-z 半角カタカナは全角に置換 半角の濁音と半濁音の記号が1文字扱いになってるので気をつけること。 ハイフンマイナスっぽい文字を置換 以下はハイフンマイナスに置換する。 MODI

    Regexp.ja
    k-holy
    k-holy 2019/11/05
    mecab使う際の正規化処理
  • Mroongaの全文検索がいい感じだった - Qiita

    tl;dr InnoDBの全文検索自体は遅くない ただしブール全文検索を行い別項目でソートを行うと、とたんに遅くなる LIMITで取得件数を絞ってもあまり変わらない Mroongaには全文検索特化の最適化がありレスポンスが早い! ことのはじまり 地味に溜めていたテキスト情報が1000万レコードを超え、そろそろLIKE検索も限界なので、MySQL5.7から使えるようになったMeCabプラグインを使い全文検索機能を実装してみました。実装当初はそこまでレスポンスが悪くないと思っていたのですが、それなりのレコード数のあるワードを入力し、ソート条件を指定するとソートキーがたとえPKやインデックスが貼られているカラムでも劇重に!(おそらく1テーブルに使えるインデックスは1つまでというMySQLの制約) 別の方法がないか模索していたところ、Mroongaエンジンの全文検索を使ってみたらいい感じだったので

    Mroongaの全文検索がいい感じだった - Qiita
    k-holy
    k-holy 2019/11/05
    MySQL+MroongaでMeCabを使うケース
  • まだ日本語全文検索で消耗してるの? - Qiita

    この記事は InnoDB のフルテキストインデックスで日語 NGRAM の続きです。 以降↑の記事を「前回の記事」と呼称します。 例によって実験しつつ記述しています。整合性や内容の保証はできません。 検証に使ったのは CentOS 7, mysql 5.7.9 です。 前回の記事は何をしているのか 端的に言えば下記です。 文字列を ngram 化するファンクションを定義 全文検索したい複数カラムを結合して ngram 化した文字列を格納するカラムを定義 トリガーで↑のカラムに ngram 化した文字列を放り込む ↑↑のカラムに対して FULLTEXT INDEX を張る 検索時に ↑↑↑のカラムに対して MATCH AGAINST 検索を行うことで全文検索 とまぁ色々めんどいことをしています。 特に筋ではないトリガーとファンクションの定義が嫌。 mysql 5.7.9 には・・・ とこ

    まだ日本語全文検索で消耗してるの? - Qiita
    k-holy
    k-holy 2019/11/05
    InnoDBでFULLEEXTインデックスの全文検索