[groonga-dev,04954] Re: pgroonga インデックス作成時の [ii][update][one] buffer is full エラー

Back to archive index
takashi sugaya tsuga****@gmail*****
2022年 4月 7日 (木) 09:10:33 JST


須藤様

お世話になっております。
菅谷です。

詳細なご回答ありがとうございます。

こちらで検証しているデータを確認すると、
閾値を変更することで格納できる可能性があるデータは、
約25万件中20件となっており、他のデータの登録や検索に影響が出るようであれば、
20件についてはエラーを許容することも視野に入れたほうが良いかもしれないですね。

ご教授いただいた内容を考慮して閾値を検討したいと思います。

何度もお付き合いいただきまして、重ね重ねありがとうございました。

以上、よろしくお願いいたします。

2022年4月7日(木) 5:58 Sutou Kouhei <kou****@clear*****>:
>
> 須藤です。
>
> In <CALHF5KCo4Mx0_UZWyJk=dA25ZZ5NZUZBja6t6hyKeS=w702c****@mail*****>
>   "[groonga-dev,04952] Re: pgroonga インデックス作成時の [ii][update][one] buffer is full エラー" on Wed, 6 Apr 2022 10:10:52 +0900,
>   takashi sugaya <tsuga****@gmail*****> wrote:
>
> > ご教授いただきましたSPLIT_COND()の閾値についてなのですが、
> > 他のファイルで動作を確認したところ、ntermsが361と512よりも少ないファイルが
> > 存在していることが分かりました。
> >
> > こちらの閾値について、他のファイルでもエラーになってしまう最小値を確認して、
> > 調整を行おうと思うのですが、値を小さくすることによる弊害はございますでしょうか?
>
> インデックスサイズが大きくなりやすい気がします。
> 検索時・更新時の性能が劣化しやくすなる気もしますが、もしかし
> たら、逆に性能がよくなることもある気はします。
>
> このしきい値を下げるということはより小さな塊に分割されやすく
> なるということです。小さな塊が多いほうがサイズ面でオーバーヘッ
> ドが大きくなりやすいのでサイズが大きくなりやすいと思います。
> 同様に、検索時・更新時も複数の塊を扱わなければいけないケース
> が増えてしまってオーバーヘッドが増える気もしますが、うまく最
> 小限の塊だけで処理を完結できて従来よりオーバーヘッドが少なく
> 性能向上につながることもありそうな気はします。
> _______________________________________________
> groonga-dev mailing list
> groon****@lists*****
> https://lists.osdn.me/mailman/listinfo/groonga-dev


groonga-dev メーリングリストの案内
Back to archive index