Naoya Murakami
visio****@gmail*****
2013年 8月 22日 (木) 11:25:09 JST
お世話になっております。村上です。 本件につきまして、事象の原因を追い込むために、 本日、再現しようと思ったら再現しなくなっていました。 すいませんでした。 先日やったときは、flush tablesやmysqldの再起動、 はてはOSの再起動しても、何度やってもデータサイズ が大きいまま残っていたのですが。。。 先日と変わった点というと、テストしたデータが 格納された元のテーブルでベクターカラムで 構成した特定の２列のデータが変な状態になっていたので （なぜか頭文字しか見れない）、その２列をUPDATEし直しました。 ひょっとしたら、その部分のデータ構造がなにか 不正な状態になっていて、悪さをしていたのかも しれません。 再現できなくなったので、推測でしかありませんが。。 また、同事象が発生したら相談させてください。 以上、よろしくお願いします。 2013年8月21日 5:43 Naoya Murakami <visio****@gmail*****>: > お世話になっております。村上です。 > > mroongaストレージモードで以下の事象が発生しました。 > > 大量データの場合は、インデックスを無効にした状態で > まず、バルクインサートした後に、alter enable keys > しないと時間がかかりすぎるので、この状態はかなり苦しいです。 > なにか良い回避方法はないでしょうか？ > > ＜事象＞ > mroongaストレージモードでインデックスを無効にした状態で > insertしたデータをdelete,updateするとサイズが増える。 > > （１）インデックスを無効にした状態でinsert→delete→enable > insert後：186M > delete後：202M > enable後：208M > drop table後：188K > > （２）インデックスを無効にした状態でinsert→enable→delete > insert後：186M > enable後：212M > delete後：252M > drop table後：188K > > （３）インデックスを無効にした状態でinsert→enable→update空白 > insert後：186M > enable後：212M > update後：226M > drop table後：188K > > （４）インデックス有効にした状態でinsert→delete > insert後：253M > delete後：17M > drop table後：180K > > ＜環境＞ > mroonga-3.06.2013.08.20 (vectorカラムの出力区切り文字をセミコロンに書き換え） > groonga-3.06の先週ぐらい時点のmaster (too many postings回避のため、GRN_II_MAX_TF > を0x1fffffに書き換え） > MySQL5.5.14 > CentOS6.4 > > 以上、よろしくお願いします。 >
