Shibuya.pm Technical Talk #10 (2008-11-27) kazuho 次 : sm5377485 (acotie) 最初: sm5377260 (lestrrat) マイリスト: mylist/9691133http://shibuya.pm.org/blosxom/techtalks/2008011.html
Senna 2.0βのリリースが見えてきました。 去年の夏に出すと言っていましたが、紆余曲折あっての現状です。 ライバルのTokyo Cabinet/Tokyo Dystopiaについては、 ストレージと全文検索インデックスを分割する方向性です。 mixi engineer blog 今までのSennaはTokyo Dystopiaに近いものでしたが、 Senna 2.0では逆にHyper Estraierのほうに近づく感じになっています。 それぞれ特色が出て面白いですねー。 今回は転置インデックス部分にもかなり手が入っているので、 Senna/Lucene/Tokyo Dystopiaのパフォーマンス比較もやってみたいと思います。 (とはいえ、パフォーマンス比較はそれぞれのライブラリに精通しないと意味のある情報が出せないので、大変ではありますね…) Senna 2.0 + MySQL 5
« setlock を使って cron をぶんまわす方法 | メイン | Range Coder の終了処理 » 2008年02月05日 Tritonn (MySQL+Senna) の join を高速化 自分の利用形態において、Tritonn の処理を最適化するパッチを書きました。具体的には、2種類の最適化を行いました。ひょっとするとバグがあるかもしれませんが、興味がある方は、以下のパッチ (tritonn-1.0.9用) とあわせてごらんください。 1. 全文索引内にプライマリキーを格納 SQL クエリを最適化する際、アクセスしたい全カラムを格納したインデックスを作成することで行データへのアクセスを抑止して速度を稼ぐ、というのは定石のひとつです。しかし、MySQL の全文索引 (フルテキストインデックス) では、他のカラムと組み合わせた複合キーを作成することができません。このことが、T
最近は、徹夜しながら MySQL + Senna の Tritonn を試している。先日まで、Tritonn を利用した全文検索では、取り出した結果がスコア値でソート(適合度順)されるものだと思っていた。 すなわち、 SELECT * FROM table WHERE MATCH(col) AGAINST('*D+ 検索' IN BOOLEAN MODE); というクエリを発行した場合、結果は TF-IDF に基づく順序だと思っていた。 これは、単なる思い込みで、正しくない。 SELECT *, MATCH(col) AGAINST('*D+ 検索' IN BOOLEAN MODE) FROM table WHERE MATCH(col) AGAINST('*D+ 検索' IN BOOLEAN MODE); こうすればスコア値を表示できるので、スコア順でソートされていないことを確認できた。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く