Susumu Yata
yata****@razil*****
2016年 1月 5日 (火) 13:52:20 JST
矢田です． 村上さんの指摘通り， grn_ra は 8 bytes より大きな要素に対応しています． しかし，要素が 8 bytes より大きくなると，アトミックに更新できなくなるため， 更新中の参照で不完全なデータが見える可能性があります． たとえば， 16 bytes の要素について，前半は更新前，後半は更新後というように， 中途半端なデータを取り出してしまうケースが考えられます． grn_ja については，新しいデータは新しい領域に配置し，位置情報をアトミックに 書き換えることで上述の問題を回避しています． 固定長の要素を保存するカラムなのに grn_ja を使っている理由は以上で， 参照ロックフリーを維持するため， grn_ra を使うわけにはいかないのです． そういうわけで，使い方がシングルスレッド限定だったり，多少の誤りは気に しなかったりするのであれば， grn_ra を使えるようにするのもありかもしれません． ただ，「参照ロックフリーです，ただし○○は除く」的な存在になるのが気になります． 後は，ほかのところで問題が出るかもしれないのが少し怖いところです． 今年もよろしくお願いいたします． 2016年1月5日 0:16 Naoya Murakami <visio****@gmail*****>: > 村上です。 > > 現在、grn_column_createではsizeof(int64_t)=8バイトを超えるものは > 可変長カラムのgrn_ja_createが利用されるようになっています。 > https://github.com/groonga/groonga/blob/v5.1.1/lib/db.c#L4518 > > 一方、固定長カラムのgrn_ra_createはもっと大きいサイズでも入るように > デザインされていると思います。 > https://github.com/groonga/groonga/blob/v5.1.1/lib/store.c#L36-L39 > > ビルトイン型だけの場合、固定長カラムはINT64まででいいと思うのですが、 > C-APIのgrn_type_createを使って、UINT128,256とかもう少し大きいものを > 保存したいと考えています。 > > 具体的な私のユースケースとしてはカラムのminhash値の最下位ビットk個を > 保持しておいて高速に類似計算することを実験しています。 > https://github.com/naoa/groonga-minhash > kが多いほど精度を上げられるため、64ビット以上のビット列を保持したいと > 思っています。 > > SHORT_TEXTと区別するだけでいいなら、たとえば、以下のように4096以上 > の場合のみgrn_ja_createにするようにしてもらえないでしょうか？ > > if ((flags & GRN_OBJ_KEY_VAR_SIZE) || value_size >= 4096) { > > 以上、ご検討よろしくお願いします。 > > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev > -- Susumu Yata <yata****@razil*****>
