Télécharger la liste

Description du projet

Javaで実装された分散キーバリューストア(KVS)です

Githubへ移行しました。 https://github.com/kobedigitallabo/okuyama

今後の更新はGithub上にて行います。 こちらにある過去リリース分はそのまま維持します。

Système requise

System requirement is not defined

Livrée : 2012-03-03 12:40
okuyama 0.9.2 (1 files Cacher)

Notes de release

[New - 新機能追加、不具合対応]
[[リリース Ver 0.9.2 - (2012/03/03)]]
■メモリオブジェクトの自動スナップショット機能を追加
メモリオブジェクトのスナップショット機能により、今までDataNode復帰時に操作記録ログから復旧していたのに対して、
高速に停止前の状態に復元されるようになった。

メモリオブジェクトのスナップショットは通常25分に一度作成される。作成されたログはDataNodeの標準出力に
開始時間と終了時間が表示される。作成される場所及びファイルの名前は、DataNodeの設定ファイルである
DataNode.propertiesの以下の設定値の第一設定値の名前に拡張子に「.obj」が付加されて作成される。
"KeyManagerJob1.Option="
例)
"KeyManagerJob1.Option=./keymapfile/1.key,./keymapfile/1.work.key"
※上記の設定の場合はkeymapfileディレクトリ内に「1.key.obj」として作成される。

また、一度作成され、その後25分が経過した場合は同じファイルに上書きとして作成される。
そのため、履歴管理などは行われない。
DataNodeのストレージモードとこのメモリオブジェクトにストアされるデータの関係は以下となる
1.Key=メモリ、Value=メモリ
->メモリオブジェクトにKeyとValueの両方がストアされる。
2.Key=メモリ、Value=ディスク
->メモリオブジェクトにKeyとValueのディスク上の位置がストアされる。
3.Key=ディスク、Value=ディスク
->メモリオブジェクトは作成されない

「1.」、「2.」それぞれのDataNode再起動時のデータ復元の挙動は以下となる。
1.メモリオブジェクトが存在した場合はメモリオブジェクトを読み込む。その後、操作記録ログが存在した場合は、
操作記録ログからメモリオブジェクト作成開始直前からの操作がトレースされ、DataNode停止直前の完全な状態が
復元される。
2.メモリオブジェクトが存在した場合はメモリオブジェクトを読み込む。その後、Valueを保存しているディスク上の
ファイルの損傷チェックを行い、損傷が発生している場合はそのデータを削除する。そして、操作記録ログが存在
した場合は、操作記録ログからメモリオブジェクト作成開始直前からの操作がトレースされ、DataNode停止直前の
状態に復元される。
メモリオブジェクトは存在するが、Valueを保存しているディスク上のファイルが存在しない、サイズが0である
場合などは、操作記録ログに残されているデータのみが復元される。



■完全ファイルモード時にDataNodeを停止後、再起動した際に操作記録ログがなくても
停止直前の状態に復元されるように起動時の挙動を変更。

従来のバージョンでは完全ファイルモード(Key=ディスク、Value=ディスク)で合っても
再起動時は操作記録ログから全てのデータを復元するしかデータを前回停止前の状態にす
方法はなかった。そのため、大量のデータを保存している場合は起動時に大量の操作記録ログを
読み出す必要があり非常に時間がかかってしまう場合があった。

そこで本機能はDataNode停止時のKey用、Value用のディスク上のファイル群がディスク上に
残っていれば、再起動時にそのファイル群を再度利用するように変更し、起動時間の短縮をおこなった。
なお、Key用、Value用のディスク上のファイルが損傷している場合は可能な範囲で修復され、
そもそもディスク上にデータがが残されていない場合は従来取り、操作記録ログから復元するプロセスとなる。

※本機能により、完全ファイルモード時はローテーション済みの操作記録ログ(1.work.key1など最後に数値のついたファイル)を
残す必要はなくなるが、定期的にバックアップをUtilClientによって取得することで保全性を高めることが出来る。
利用方法は特に意識する必要なく、本機能は有効となる。



■ディスクキャッシュ機能を追加
本機能はValueをディスクに保存している場合のみ有効となる。

okuyamaはValueの場所をディスクにした場合は、一定までのサイズのValueを全て1つの
ファイルで集中的に管理している。

ここに保存している1Valueのデータはブロックデータと呼ばれる。
getなどの取得処理の場合は、このファイル上をシークしブロックデータを取り出している。
SSDのようなシーク処理を必要としないディスクの場合は高速に稼働するが、HDDなどの場合は
アクセスが集中しかつ、ValueのファイルがOSのバッファサイズを超えるようになると、
アクセス速度が低速化する。

そこで本機能では、一度読みだしたブロックデータをHDDよりもランダムリードが高速な
デバイスに一時的にキャッシュすることでget処理を高速化するものである。

一時的にキャッシュされるValueはレコード数で指定可能である。Defaultは1DataNode当たり、
10000件となる。キャッシュに利用するディスクサイズの算出は、ブロックデータのサイズを
利用して計算することが可能であり。そのブロックサイズはDefaultでは12888byteとなる。
そのため、利用されるディスクサイズは、以下の計算式で求める
--------------------------------------------------------------------
[12888byte × 10000件 = 128880000byte]
--------------------------------------------------------------------
このブロックサイズはDataNodeの起動引数である「-s]を利用して「-s 8192」のように変更が可能である。

キャッシュの有効化及び、キャシュファイルの作成場所指定は、DataNode.propertiesの「KeyManagerJob*.cacheFilePath=」
要素を指定し、ファイルパスを記述することで有効化される。利用しない場合はこの要素そのものを消すか、ファイル指定を
消すことで無効化かされる。
--------------------------------------------------------------------
[DataNode.propertiesでの設定例]
例) "KeyManagerJob1.cacheFilePath=/usbdisk/cachedata/cache1.data"
--------------------------------------------------------------------
キャッシュされるValueの件数はDataNodeの起動引数である「-mdcs」を利用して「-mdcs 50000」のように
キャッシュしたい件数を指定して変更可能である。デフォルトは前述の通り、10000件

利用中にUSBフラッシュメモリが壊れた場合は、キャッシュの利用が停止されるだけとなり、DataNodeの停止は
発生しない。壊れた場合は、USBをサーバから引き抜き、新しいUSBディスクを故障前と同じ名前でマウントすれば、
自動的に再認識され、利用される。その際DataNodeの停止は伴わない。



■Java&PHPのOkuyamaClientにObjectの新規登録を保証するsetNewObjectValueメソッドを追加
setNewValueはValueにString型しか対応していなかったが、ValueをObjectとするバージョンを追加。
利用方法はsetNewValueと同様
利用例)※Java版
------------------------------------------------------
OkuyamaClient client = new OkuyamaClient();
client.connect("127.0.0.1", 8888);

Map objectValue = new HashMap();
objectValue.put("Key_XXX", "Value_XXX");
objectValue.put("Key_YYY", "Value_YYY");
objectValue.put("Key_ZZZ", "Value_ZZZ");

String[] setResult = client.setNewObjectValue("Object_Key", objectValue); // 新規登録

if (setResult[0].equals("true")) { // 登録を確認
System.out.println("登録成功");
} else {
System.out.println("登録失敗 Message=[" + setResult[1] + "]");
}
------------------------------------------------------



■UtilClientを利用したバックアップ機能でのokuyamaの負荷軽減機能を追加
UtilClientを利用したバックアップを行った場合okuyama側はリソースの限界まで利用して
バックアップ作成をおこなっていたが、バックアップの指定引き数をあたえることで、低速で徐々にバックアップを
作成する機能を追加。これによりバックアップ作成時にokuyama側がbusyにならないようにすることが可能
従来から2つ引き数を追加
第4引き数:クライアントがなんだかの理由でアボートした場合にokuyama側がそれを検知する時間(ミリ秒)
第5引き数:okuyama側データを出力する際に一定量排出した後にここで指定したミリ秒だけ停止する。大きくすると負荷は下がるが時間がかかる

利用方法)
java -classpath ./:./okuyama-0.9.2.jar:./lib/javamail-1.4.1.jar okuyama.imdst.client.UtilClient bkup 127.0.0.1 5553 10 20 > bkupFor5553.dump



■起動パラメータを以下の通り追加
DataNode用の起動パラメータ
-crcm 記述:true/false
説明:MasterNodeとDataNode間の処理に失敗した場合に強制的に1度だけ再処理を行うようにするかの設定
Networkが不安定な場合や遅い場合はtrueにするとよいことがある
true/再接続する, false/再接続は自動
デフィルトはfalse
設定例: -crcm true

-dcmuc 記述:整数(利用回数)
説明:MasterNodeとDataNode間のSockeの最大再利用回数 (整数) 少ない値にすると接続コストがかかる
デフィルトは50000
設定例: -dcmuc 10000

-smbsmf 記述:整数(格納数)
説明:SerializeMapのBucketサイズのJVMへのメモリ割当1MB単位への格納係数(整数)
デフィルトは400(レスポンスを向上したい場合は小さな値にすると良いが、メモリ当たりの格納数は減る)
設定例: -smbsmf 200

-red 記述:true/false
説明:完全ファイルモード時に既に存在するデータを再利用する設定
デフィルトはtrue。
falseにすることで停止前のデータを全て削除してトランザクションログからの起動を選択する
設定例: -red false

-wfsrf 記述:true/false
説明:DataNode起動時に操作記録ログ(トランザクションログ)を読み込む設定
trueの場合は読み込む(デフォルト)
falseの場合は読みこまない.この場合はデータは常に0件からの起動になる
設定例: -wfsrf false

-udt 記述:1/2
説明:データファイルを保存するディスクのタイプを指定することで、ディスクへのアクセスが最適化される
1=HDD(デフォルト) 2=SSD
設定例: -udt 2

-mdcs 記述:整数(格納数)
説明:ディスクキャッシュ利用時に、どれだけの件数をキャッシュに乗せるかを件数で指定する
「■ディスクキャッシュ機能を追加」も参照
デフォルトでは10000件
設定例: -mdcs 50000



■PHP版のOkuyamaClient.class.phpで未実装だった以下のメソッドを実装。挙動はJava版と同様である
1.getTagValues
2.getMultiTagValues
3.getMultiTagKeys

※以下のメソッドは未実装
getTagKeysResult
getMultiTagKeysResult


■Linux用のサービス化スクリプトを試験的に作成。install/配下に
MasterNode用[okuyamaMasterNodeServiceScript]
DataNode用[okuyamaDataNodeServiceScript]
として配置


■有効期限を30日以上に設定出来ないバグを修正
■ノード追加に伴うデータ移行中にTagデータを新規登録すると、正しく取得出来ないバグを修正
■DataNodeのリカバリー処理、ノード追加時のデータ再配置処理の堅牢性を向上
■getMultiValuesメソッドで特定の条件下で応答が返ってこないバグを修正
■いくつかの性能向上

Changelog

No Changelogs