okuyama-0.6.3リリース&KVSを業務システムに使用したフィードバック

okuyama-0.6.3をリリースしました。


今回の変更ポイントは
■データノードをmemcacheのノードとして利用可能に


  okuyamaはマスターノード、データノード、トランザクションノードで


  構成されているんですが、ただ単にデータをキャッシュとして保存する場合は


  マスターノードとトランザクションノードは不要で、データノードだけで可能です。


  なので、データノードもmemcacheプロトコルで会話出来るようにしました。


  対応メソッドはset,get,add,deleteです。


  ファイル永続化モード(トランザクションログでの永続化、データ完全ファイル保存での永続化を選べます)で


  起動できるのでノードを落としてもデータは消えません(どこかで聞いたことあるような機能ですね。。。)


  まあ、じつは前の日記(2010/03/30 memcache速っ!!)で書いたのですが、


  okuyamaの「マスターノード=>データノード」の構成でmemcacheに戦いを挑んだところボロ負けしたんですよね。。。


  ちょっと悔しかったんですよね。。。


  何とか単ノード、データ永続化の条件で勝ちたくて。。。








  memcacheはsetで6500QPS出てたので、okuyamaデータノード(永続化モード)は








  5500QPS!!!!!






  ・・・・
  負けてるやん。。。。orz


  まあこんなもんでしょ。
  やっぱmemcache速いですね。


 memcacheの変わりとして永続化可能なストレージとして使えるので良ければ使ってやってください。






  残りの変更点は


■Key値からHash値を求めるロジックを変更


  okuyamaは渡されたKey値をハッシュ値にして内部では扱っているのですが、ハッシュ値化する


  ロジックが衝突を生む可能が高かったので、変更しました。


  ただ今までのデータが使えなくなるので、変更せずに利用する場合はReadMe.txtをご覧ください。




■データ登録メソッドsetValue時の処理速度を20%向上


  従来の「マスターノード=>データノード」の構成時のsetValueの処理効率を20%向上しました。


  従来マスターノードはデータノードへ登録データ送信中は何もせずにデータノードの返答を待っていたのですが、


  この時間が無駄なので待ち時間を利用してスレーブデータノードへの送信準備をするように変更しました。




■バグFix
  いくつかのバグを修正






以上がリリース内容です。




やっぱり業務で使いはじめたのでそこからのフィードバックが大きいです。


いくつかのバグはそのフィードバックからでました。


業務システムではトランザクションはかなりの確率で


必要です。これがないと満足にデータの更新もできません。


okuyamaの場合は分散ロックが使えるのでこれで一意性を


確保しています。

後、良くない点としては小さなデータ(メタデータのような文字情報)から

大きなデータ(ファイル)まで全て1組のokuyamaに登録していますが、


あまり効率が良くないですね。


okuyamaは1データ当たりの登録可能なサイズが決まっています(ImdstDefine.javaのsaveDataMaxSize変数が保存可能なbyte数)


そのサイズを超えるデータは登録できないので、そのサイズを超えるようなデータ(長い文字列や、ファイルなど)は


分割して別キー値(このキー値はシステムが独自で生成しています)を付けて保存しています。


分割するので当然取得時は別々に取得しないといけないんですが、この効率が悪いです。


本来なら保存可能なサイズの最適値をあらかじめ予想してokuyamaを構成すればもっと効率良くなると思います。
(大きなファイルを登録するクラスターと、小さなメタデータを保存するクラスターなど)


でもそうなるとアプリ側で制御が煩雑になる可能性なんかも考えられて。。。


最適な配置問題は大きな課題ですね。
分散ファイルシステムにも注目が集まっているし、周りのお客さんで実際に求めているかたもいるので、
調査していきます。