隔週連載groonga 第10回[実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（3） こんにちは、株式会社リブセンスの吉田健太郎です。第8回に続いて、私が体験したTritonnからmroongaのシステム移行プロジェクトを舞台裏からお届けします。 これまでのあらすじ 将来的な技術負債を残さない、そしてInnoDBの性能向上等の恩恵を受けるため、もはやレガシーとなったMySQL 5.0を捨てて、MySQL 5.6への移行を行いたい。しかしSolrへ乗り換えるほどでもなく、引き続きシンプルにSQLを用いた、リレーショナルな日本語対応の全文検索を使いたい。この構想を実現するため、groongaのMySQLバインディング版である「mroonga」を用いた、MySQL 5.6への移行プロジェクトが始動しました。 これまでの記事と、主なトピックは次の通り
![第10回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（3） | gihyo.jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/05b0af51bb41516773d6954ec69cb62b4b24568e/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fgihyo.jp%2Fassets%2Fimages%2FICON%2F2013%2F1099_groonga.png)
CREATE TABLE test ( id INTEGER AUTO_INCREMENT, PRIMARY KEY (id), text TEXT NOT NULL, FULLTEXT INDEX text (text) COMMENT 'parser "TokenBigram"' )ENGINE=mroonga COMMENT='engine "MyISAM"'; まず、Tritonn、mroongaの５行目では全文検索用のインデックスをはり、トークナイザ（検索ロジックの方式）としてNGRAM系を使用するように指定している。同じことをしているが指定方法にかなり違いがある。 次にmroongaでは６行目が追加され、ストレージエンジンの指定を行っている。 TritonnではストレージエンジンはMyISAMしか選択できなかったが、mroongaでは「 COMMENT=’engine “Inn
MySQLの全文検索エンジンTritonn(Senna)からmroonga(groonga)に移行する際の注意点 その２（データのリストア＆boolean modeでのプラグマ指定方法） その１（DDL文）の続き。 ２．Tritonn MySQLのデータをmroonga MySQLにリストアする際の注意点 TritonnでText形式のカラムを使用している場合、データの文字数に気を付ける必要がある。 TritonnのMySQLでのデータをバックアップし、mroongaのMySQLにリストアする場合、 mroonga側のトークナイザにより違いはあるが、記号や半角数字等で構成されたの長い文字列（4097文字以上）データをINSERTする際に、以下の様なエラーが発生する。 mysql> INSERT INTO test (`content`) values ('0123456789012345
早いもので前回のリリースから1年弱が経過してしまいましたが、SourceForgeのダウンロード統計を見ているとリリースが無い間も継続的にダウンロードしてくださる方々がいらっしゃるのが気になっていました。 そこで現在のMySQL 5.0系の最新版である5.0.87向けのソース配布版およびold-styleパッチをリリースしました！ https://sourceforge.jp/projects/tritonn/releases/ 今回のリリースはMySQL 5.0系最新版へのアップデートが目的です。Tritonn自体のバージョンは1.0.12のままです。 Tritonnの1.0.13については担当者多忙につき少しお休み中。MySQL 5.1対応についてはGroongaストレージエンジンを開発中です。 バイナリパッケージについては時間が取れ次第、随時リリースして行きます。 追記:11/26
今日一日調べたこととかまとめてみる。 問題点 次回リリースの新機能はDB select負荷がかなり掛かるはずである。 現状でもデータLOADによる負荷が10に達し、selectにスロークエリ、接続エラーが出ている。DBの負荷分散が急務である。 参考: Load Average 参考: Slow Query あと、STATUSテーブルが2GBに達しようとしているので、デフォルトのサイズ制限4GBが見えてきた。再定義できるけど。 垂直分割対応案 日本語版DBと英語版DBのデータベースとクローラを別ホストに格納する 現状、favotterとfavotter_enはほぼ同規模のDBとなっている。 ただし、参照は圧倒的にfavotterが多い。 favotter_enのクローラを止めたら、スロークエリが激減した事がある。 参考: 小野マトペ on Twitter: "まる一日英語版のクローラ止めてた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
