23:04全文検索を実装するときに、転置インデックス的なやり方(そんな名前がついてるとか知らなかったけれど)は検討したのだけれど、どんでもないレコード数になるから、扱いづらくて遅いんじゃないかと思ってました。CHARSET=utf8;nidは、65万件くらい。1nidに対して、ngram化した文字が1000あったとして、レコード数は6億レコードとかになる。insertは、10万nidで15分くらいだったから、許容範囲だろうか。3;FULLTEXTの場合は、こんな感じだったもの。mode);さあ、どんな結果がでるのだろう。ただいま、データinsert中。MyISAMで更新の多いFULLTEXTインデックスは、すぐにオーバーヘッドが発生するし、修復もハイコストだし、なんとかしたいというのが動機。InnoDB化がきっかけ。01:106億レコードもなかった。70,295,304レコード。(InnoDBはレコード数をカウントするのが遅いことを知る)では、検索スピード比較(3文字ngram)数日前のポストマップのインデックスからです。秒)「そんなことじゃないかと思っていました。秒)スピードに関しては、十分という気がする。3文字までなら転置の方が速くて、それ以上はFULLTEXTという結果かな。1.6G倍くらいなら、気にならない。(`nid`,`ngram`)こうしておかないと、nidで検索したときにインデックスが使用されない。http://dev.mysql.com/doc/refman/5.1/ja/multiple-...検索を更新するときに、nidで検索して削除しなければならないから。13:19これはとんでもない勘違いだ。検索でindexが使用できなくなるじゃないか。CHARSET=utf8;nidに追加でindexをつけるしかなさそうだ。コメント(4)MySQL,fulltextインデックス,Ngram化のまとめ。00:46少し説明的に。MySQLには、fulltextという全文検索用のインデックスがあります。日本語は単語単位で区切られていないので、なんらかの方法で区切る必要があります。区切り方には、形態解析で区切る方法と、意味なんて考えずに1文字とか2文字とかで区切っていくNgramという方式があります。(あ、その前に、検索対象が数万件くらいなら、「REGEXP」で検索するのがいいと思います。速いし、おそらく厳密だし。)で、今までは形態解析の方でやってました(mecabなるものを利用)。このインデックス化は、「アイスクリーム」を検索したい時に、インデックスに「アイスクリーム」しかないと、「アイス」という検索ではヒットしないというところが難点でした。初期導入時は、、なんとなく意味で区切った方がインデックス文字列が少なくていいし、優れているのではないかというのが選択動機だったと思います。インデックス文字列の作り方。Ngram化したい文字列。',$str));こんな感じで、$strをMySQLにインサートします。