Javaで実装された分散キーバリューストア(KVS)です
Githubへ移行しました。 https://github.com/kobedigitallabo/okuyama
今後の更新はGithub上にて行います。 こちらにある過去リリース分はそのまま維持します。
[[リリース Ver 0.9.4 - (2012/12/05)]]
■okuyamaFuseを追加
※ベータ版のため、予期せぬエラーなどが起こる可能性があります!!
テスト時は仮想環境等での利用を推奨します。
okuyamaFuseディレクトリに追加
okuyamaをストレージとして動くファイルシステムです。
ファイル、ディレクトリの新規作成、追記、参照、部分追記、部分参照、削除といった一般的な操作に対応しています、
また、所有ユーザ、権限にも対応しています。
※シンボリックリンク、a-timeのみの変更は対応していません。
okuyamaをストレージとして動くためokuyama側の特性を引き継ぎます。
そのため、okuyama側をメモリモードで高速なストレージや、
ファイルモードで大容量のファイルサーバが作成可能です
ファイルのデータを1ファイル1Valueとして管理するのではなく、1ファイルをブロックに分解し、
okuyama上で管理します。そのため、ランダムリード、ライトなどファイルの一部を操作する処理に
性能を発揮します。また、複数の処理からの同時参照にも高い処理性能を発揮します。
また、1ファイルの上限も実質存在しないため、テラバイト以上の巨大なファイルも作成可能です。
その際もファイルの一部分へのアクセス速度は落ちません。
その反面、ファイルのシーケンシャルなアクセスではそこまで性能はでません。
また、現状ではrmによるファイル削除に時間がかかります。これは1ファイルを構成するブロックである
okuyamaのKey-Valueを全てremoveしていることに起因します。
作者はMySQLのデータファイル置き場やVirtualBoxの仮想イメージ置き場としてテストしています。
MySQLのデータ置き場として利用した場合、検索や更新などの処理が混在した場合性能の向上が見られました。
ストレージの性能や容量はokuyamaに依存するため、okuyama側をスケールアウトすることで
okuyamaFuseもスケールアウトします。
その際もokuyama側が無停止であるため、okuyamaFuseも停止する必要はありません。
ファイルシステムを構成する全てのデータ(メタデータ、ファイルのブロックデータ)は全てokuyamaで
管理されるため、あるサーバにマウントしファイルを作成すれば同じokuyamaを利用してmountしている
okuyamaFuseは全てのデータは同期されています。
そのため、mountしているサーバがダウンした際など別サーバでmountを行えばサーバダウン前までの
データにアクセスできます。
その反面、同一のファイルを複数サーバから更新するとファイルのデータを壊してしまいます。
詳しい利用方法等はokuyamaFuse/ReadMe-UTF.txtをご覧ください。
■sendMultiByteValueをJava版のOkuyamaClientに追加
一度に複数のKeyとbyte型のValueを登録する機能
通信回数の節約になる。ただし一度にokuyamaに大量のデータを送ることになるので、
okuyama自体のメモリを枯渇させないように注意する必要がある。
引数はMap型となり値はKeyとValueのセットとなる。
戻り値はMap型となり値は引数で渡されたKeyとそのKeyの登録結果をBoolean型で格納したMap
[OkuyamaClientでのメソッド]
public Map sendMultiByteValue(Map<String, byte[]> requestData) throws OkuyamaClientException;
■getTagObjectValues追加
Tagを指定してValueを取得する際にそのValueをObject型に復元して返す。
getTagValuesのValue取得部分をgetObjectValueとしたバージョンである
そのため、紐付くValueが全てsetObjectValueで登録した値でないといけない
指定したTag内にsetObjectValueで登録した値以外が含まれるとエラーとなる
[OkuyamaClientでのメソッド]
public Map getTagObjectValues(String tagStr) throws OkuyamaClientException;
■MasterNoed.propertiesのMyNodeInfoを設定していなくても、自身のHost名を利用して設定を補填するように機能追加
正しく各サーバのHost名を設定していないMasterNodeの冗長構成が正しく機能しない可能性があるため、注意が必要である。
本機能はMasterNoed.propertiesのMyNodeInfoの設定を省略することで機能する。
■Valueがディスクモード時にスナップショットオブジェクトからデータを復元した場合は-s起動オプションで指定した
バイト数もしくは12888バイトを超えるデータを取得出来ないバグを修正。このバグが発生した場合は
スナップショットオブジェクトを消し、操作記録ログもしくはバックアップで作成したファイルから復元すると
完全にデータが復元できる。
■バックアップ用のスナップショットObjectを出力するかの有無
keymapfile配下に出力されるスナップショット機能によるバックアップファイル(1.key.obj等)の出力有無を
選択できるように起動引数を追加。okuyama起動時にデータ復元が全く必要ない場合は、この設定を利用することで
スナップショットファイルが作成されなくなる。
引数名 -efsmo
記述:true/false
意味:true=スナップショットファイルが作成される/ false=作成されない
省略時:true
設定例: -efsmo false
■DataNodeを動かすサーバがリカバリ時、DataNode追加時のデータ再配置時に高負荷になる
場合に設定する起動パラメータを追加。この設定はデータを出力する側のサーバに設定する。
リカバリ時の場合は正常に稼働している側のDataNode。追加時は元から稼働してる側のDataNode
[注意!!]本設定を行うと設定前に比べてデータノードのリカバリ、データの再配置処理に余分に時間がかかる
負荷を掛けたくないことを指定
引数名 -lsdn
記述:true/false
意味:true=負荷を掛けたくないことを指示/ false=負荷を指定をしない
省略時:false
設定例: -lsdn true
負荷を掛けたくないことを指定
引数名 -lsdnsdc
記述:整数
意味:一度にリカバリ対象or再配置対象に転送するデータ数
本値は-lsdnを指定しない場合50000~100000が利用される
省略時:2000
設定例: -lsdnsdc 4000
■検索Index作成時にダブルバイト文字の1文字の場合作成されない問題を修正
■バグフィックスと性能向上を実施