OSDN -- 開發和下載開源軟體
繁體中文翻譯狀態 translation status for zh-tw
  • R/O
  • SSH
  • HTTPS

okuyama: 提交


Commit MetaInfo

修訂914 (tree)
時間2012-02-13 20:01:32
作者okuyamaoo

Log Message

(empty log message)

Change Summary

差異

--- trunk/ReadMe-UTF.txt (revision 913)
+++ trunk/ReadMe-UTF.txt (revision 914)
@@ -22,6 +22,92 @@
2222 ・改修履歴
2323 ========================================================================================================
2424 [New - 新機能追加、不具合対応]
25+[[リリース Ver 0.9.2 - (2012/02/XX)]]
26+・メモリオブジェクトのバックアップ機能を追加
27+ メモリオブジェクトのバックアップ機能により、今までDataNode復帰時に操作記録ログから復旧していたのに対して、
28+ 高速に停止前の状態に復元されるようになった。
29+
30+ メモリオブジェクトのバックアップは通常25分に一度作成される。作成されたログはDataNodeの標準出力に
31+ 開始時間と終了時間が表示される。作成される場所及びファイルの名前は、DataNodeの設定ファイルである
32+ DataNode.propertiesの以下の設定値の第一設定値の名前として拡張子に「.obj」が付加されて作成される。
33+ "KeyManagerJob1.Option="
34+ 例)
35+ "KeyManagerJob1.Option=./keymapfile/1.key,./keymapfile/1.work.key"
36+ ※上記の設定の場合はkeymapfileディレクトリ内に「1.key.obj」として作成される。
37+
38+ また、一度作成され、その後25分が経過した場合は同じファイルに上書きとして作成される。
39+ そのため、履歴管理などは行われない。
40+ DataNodeのストレージモードとこのメモリオブジェクトにストアされるデータの関係は以下となる
41+ 1.Key=メモリ、Value=メモリ
42+ ->メモリオブジェクトにKeyとValueの両方がストアされる。
43+ 2.Key=メモリ、Value=ディスク
44+ ->メモリオブジェクトにKeyとValueのディスク上の位置がストアされる。
45+ 3.Key=ディスク、Value=ディスク
46+ ->メモリオブジェクトは作成されない
47+
48+ 「1.」、「2.」それぞれのDataNode再起動時のデータ復元の挙動は以下となる。
49+ 1.メモリオブジェクトが存在した場合はメモリオブジェクトを読み込む。その後、操作記録ログが存在した場合は、
50+ 操作記録ログからメモリオブジェクト作成開始直前からの操作がトレースされ、DataNode停止直前の完全な状態が
51+ 復元される。
52+ 2.メモリオブジェクトが存在した場合はメモリオブジェクトを読み込む。その後、Valueを保存しているディスク上の
53+ ファイルの損傷チェックを行い、損傷が発生している場合はそのデータを削除する。そして、操作記録ログが存在
54+ した場合は、操作記録ログからメモリオブジェクト作成開始直前からの操作がトレースされ、DataNode停止直前の
55+ 状態に復元される。
56+ メモリオブジェクトは存在するが、Valueを保存しているディスク上のファイルが存在しない、サイズが0である
57+ 場合などは、操作記録ログに残されているデータのみが復元される。
58+
59+
60+・完全ファイルモード時にDataNodeを停止後、再起動した際に操作記録ログがなくても停止直前の状態に復元されるように
61+ 起動時の挙動を変更。
62+ 従来のバージョンでは完全ファイルモード(Key=ディスク、Value=ディスク)で合っても再起動時は操作記録ログから
63+ 全てのデータを復元するしかデータを前回停止前の状態に戻す方法はなかった。そのため、大量のデータを保存している
64+ 場合は起動時に大量の操作記録ログを読み出す必要があり非常に時間がかかってしまう場合があった。
65+ そこで本機能はDataNode停止時のKey用、Value用のディスク上のファイル群がディスク上に残っていれば、再起動時に
66+ そのファイル群を再度利用するように変更し、起動時間の短縮をおこなった。
67+ なお、Key用、Value用のディスク上のファイルが損傷している場合は可能な範囲で修復され、そもそもディスク上に
68+ データがが残されていない場合は従来取り、操作記録ログから復元するプロセスとなる。
69+ ※本機能により、完全ファイルモード時はローテーション済みの操作記録ログ(1.work.key1など最後に数値のついたファイル)を
70+ 残す必要はなくなるが、定期的にバックアップをUtilClientによって取得することで保全性を高めることが出来る。
71+ 利用方法は特に意識する必要なく、本機能は有効となる。
72+
73+
74+・ディスクキャッシュ機能を追加
75+ 本機能はValueをディスクに保存している場合のみ有効となる。
76+ okuyamaはValueの場所をディスクにした場合は、一定までのサイズのValueを全て1つのファイルで集中的に管理している。
77+ ここに保存している1Valueのデータはブロックデータと呼ばれる。
78+ getなどの取得処理の場合は、このファイル上をシークしブロックデータを取り出している。SSDのようなシーク処理を
79+ 必要としないディスクの場合は高速に稼働するが、HDDなどの場合はアクセスが集中しかつ、ValueのファイルがOSの
80+ バッファサイズを超えるようになると、アクセス速度が低速化する。
81+ そこで本機能では、一度読みだしたブロックデータをHDDよりもランダムリードが高速なデバイスに一時的にキャッシュ
82+ することでget処理を高速化するのが、本機能である。
83+ 一時的にキャッシュされるValueはレコード数で指定可能である。Defaultは1DataNode当たり、10000件となる。
84+ キャッシュに利用するディスクサイズの算出は、ブロックデータのサイズを利用して計算することが可能であり。
85+ そのブロックサイズはDefaultでは12888byteとなる。そのため、利用されるディスクサイズは、以下の計算式で求める
86+ 12888byte × 10000件 = 128880000byte
87+ このブロックサイズはDataNodeの起動引数である「-s]を利用して「-s 8192」のように変更が可能である。
88+
89+ キャッシュ用の有効化及び、キャシュファイルの作成場所指定は、DataNode.propertiesの「KeyManagerJob*.cacheFilePath=」
90+ 要素を指定し、ファイルパスを記述することで有効化される。利用しない場合はこの要素そのものを消すか、ファイル指定を
91+ 消すことで無効かされる。
92+ [DataNode.propertiesでの設定例]
93+ 例) "KeyManagerJob1.cacheFilePath=/usbdisk/cachedata/cache1.data"
94+
95+ キャッシュされるValueの件数はDataNodeの起動引数である「-mdcs」を利用して「-mdcs 50000」のように
96+ キャッシュしたい件数を指定して変更可能である。デフォルトは前述の通り、10000件
97+
98+ 利用中にUSBフラッシュメモリが壊れた場合は、キャッシュの利用が停止されるだけとなり、DataNodeの停止は
99+ 発生しない。壊れた場合は、USBをサーバから引き抜き、新しいUSBディスクを故障前と同じ名前でマウントすれば、
100+ 自動的に再認識され、利用される。その際DataNodeの停止は伴わない。
101+
102+
103+
104+・有効期限を30日以上に設定出来ないバグを修正
105+・ノード追加に伴うデータ移行中にTagデータを新規登録すると、正しく取得出来ないバグを修正
106+・DataNodeのリカバリー処理、ノード追加時のデータ再配置処理の堅牢性を向上
107+・いくつかの性能向上
108+
109+========================================================================================================
110+[New - 新機能追加、不具合対応]
25111 [[リリース Ver 0.9.1 - (2011/12/19)]]
26112
27113 ・PHP版のOkuyamaClientの不具合対応
--- trunk/ReadMe.txt (revision 913)
+++ trunk/ReadMe.txt (revision 914)
@@ -17,11 +17,97 @@
1717 [Think IT] "分散KVS「okuyama」実践TIPS"
1818 第1回 okuyamaを導入するまでに知っておきたいサーバリソースとの4つの関係 http://thinkit.co.jp/story/2011/10/12/2303
1919 第2回 okuyamaを運用するために知っておきたい基本的な操作 http://thinkit.co.jp/story/2011/10/26/2316
20- 第3回 okuyamaでのアプリ開発で押さえておきたい機能
20+ 第3回 okuyamaでのアプリ開発で押さえておきたい機能 http://thinkit.co.jp/story/2011/11/10/2325
2121
2222 ・改修履歴
2323 ========================================================================================================
2424 [New - 新機能追加、不具合対応]
25+[[リリース Ver 0.9.2 - (2012/02/XX)]]
26+・メモリオブジェクトのバックアップ機能を追加
27+ メモリオブジェクトのバックアップ機能により、今までDataNode復帰時に操作記録ログから復旧していたのに対して、
28+ 高速に停止前の状態に復元されるようになった。
29+
30+ メモリオブジェクトのバックアップは通常25分に一度作成される。作成されたログはDataNodeの標準出力に
31+ 開始時間と終了時間が表示される。作成される場所及びファイルの名前は、DataNodeの設定ファイルである
32+ DataNode.propertiesの以下の設定値の第一設定値の名前として拡張子に「.obj」が付加されて作成される。
33+ "KeyManagerJob1.Option="
34+ 例)
35+ "KeyManagerJob1.Option=./keymapfile/1.key,./keymapfile/1.work.key"
36+ ※上記の設定の場合はkeymapfileディレクトリ内に「1.key.obj」として作成される。
37+
38+ また、一度作成され、その後25分が経過した場合は同じファイルに上書きとして作成される。
39+ そのため、履歴管理などは行われない。
40+ DataNodeのストレージモードとこのメモリオブジェクトにストアされるデータの関係は以下となる
41+ 1.Key=メモリ、Value=メモリ
42+ ->メモリオブジェクトにKeyとValueの両方がストアされる。
43+ 2.Key=メモリ、Value=ディスク
44+ ->メモリオブジェクトにKeyとValueのディスク上の位置がストアされる。
45+ 3.Key=ディスク、Value=ディスク
46+ ->メモリオブジェクトは作成されない
47+
48+ 「1.」、「2.」それぞれのDataNode再起動時のデータ復元の挙動は以下となる。
49+ 1.メモリオブジェクトが存在した場合はメモリオブジェクトを読み込む。その後、操作記録ログが存在した場合は、
50+ 操作記録ログからメモリオブジェクト作成開始直前からの操作がトレースされ、DataNode停止直前の完全な状態が
51+ 復元される。
52+ 2.メモリオブジェクトが存在した場合はメモリオブジェクトを読み込む。その後、Valueを保存しているディスク上の
53+ ファイルの損傷チェックを行い、損傷が発生している場合はそのデータを削除する。そして、操作記録ログが存在
54+ した場合は、操作記録ログからメモリオブジェクト作成開始直前からの操作がトレースされ、DataNode停止直前の
55+ 状態に復元される。
56+ メモリオブジェクトは存在するが、Valueを保存しているディスク上のファイルが存在しない、サイズが0である
57+ 場合などは、操作記録ログに残されているデータのみが復元される。
58+
59+
60+・完全ファイルモード時にDataNodeを停止後、再起動した際に操作記録ログがなくても停止直前の状態に復元されるように
61+ 起動時の挙動を変更。
62+ 従来のバージョンでは完全ファイルモード(Key=ディスク、Value=ディスク)で合っても再起動時は操作記録ログから
63+ 全てのデータを復元するしかデータを前回停止前の状態に戻す方法はなかった。そのため、大量のデータを保存している
64+ 場合は起動時に大量の操作記録ログを読み出す必要があり非常に時間がかかってしまう場合があった。
65+ そこで本機能はDataNode停止時のKey用、Value用のディスク上のファイル群がディスク上に残っていれば、再起動時に
66+ そのファイル群を再度利用するように変更し、起動時間の短縮をおこなった。
67+ なお、Key用、Value用のディスク上のファイルが損傷している場合は可能な範囲で修復され、そもそもディスク上に
68+ データがが残されていない場合は従来取り、操作記録ログから復元するプロセスとなる。
69+ ※本機能により、完全ファイルモード時はローテーション済みの操作記録ログ(1.work.key1など最後に数値のついたファイル)を
70+ 残す必要はなくなるが、定期的にバックアップをUtilClientによって取得することで保全性を高めることが出来る。
71+ 利用方法は特に意識する必要なく、本機能は有効となる。
72+
73+
74+・ディスクキャッシュ機能を追加
75+ 本機能はValueをディスクに保存している場合のみ有効となる。
76+ okuyamaはValueの場所をディスクにした場合は、一定までのサイズのValueを全て1つのファイルで集中的に管理している。
77+ ここに保存している1Valueのデータはブロックデータと呼ばれる。
78+ getなどの取得処理の場合は、このファイル上をシークしブロックデータを取り出している。SSDのようなシーク処理を
79+ 必要としないディスクの場合は高速に稼働するが、HDDなどの場合はアクセスが集中しかつ、ValueのファイルがOSの
80+ バッファサイズを超えるようになると、アクセス速度が低速化する。
81+ そこで本機能では、一度読みだしたブロックデータをHDDよりもランダムリードが高速なデバイスに一時的にキャッシュ
82+ することでget処理を高速化するのが、本機能である。
83+ 一時的にキャッシュされるValueはレコード数で指定可能である。Defaultは1DataNode当たり、10000件となる。
84+ キャッシュに利用するディスクサイズの算出は、ブロックデータのサイズを利用して計算することが可能であり。
85+ そのブロックサイズはDefaultでは12888byteとなる。そのため、利用されるディスクサイズは、以下の計算式で求める
86+ 12888byte × 10000件 = 128880000byte
87+ このブロックサイズはDataNodeの起動引数である「-s]を利用して「-s 8192」のように変更が可能である。
88+
89+ キャッシュ用の有効化及び、キャシュファイルの作成場所指定は、DataNode.propertiesの「KeyManagerJob*.cacheFilePath=」
90+ 要素を指定し、ファイルパスを記述することで有効化される。利用しない場合はこの要素そのものを消すか、ファイル指定を
91+ 消すことで無効かされる。
92+ [DataNode.propertiesでの設定例]
93+ 例) "KeyManagerJob1.cacheFilePath=/usbdisk/cachedata/cache1.data"
94+
95+ キャッシュされるValueの件数はDataNodeの起動引数である「-mdcs」を利用して「-mdcs 50000」のように
96+ キャッシュしたい件数を指定して変更可能である。デフォルトは前述の通り、10000件
97+
98+ 利用中にUSBフラッシュメモリが壊れた場合は、キャッシュの利用が停止されるだけとなり、DataNodeの停止は
99+ 発生しない。壊れた場合は、USBをサーバから引き抜き、新しいUSBディスクを故障前と同じ名前でマウントすれば、
100+ 自動的に再認識され、利用される。その際DataNodeの停止は伴わない。
101+
102+
103+
104+・有効期限を30日以上に設定出来ないバグを修正
105+・ノード追加に伴うデータ移行中にTagデータを新規登録すると、正しく取得出来ないバグを修正
106+・DataNodeのリカバリー処理、ノード追加時のデータ再配置処理の堅牢性を向上
107+・いくつかの性能向上
108+
109+========================================================================================================
110+[New - 新機能追加、不具合対応]
25111 [[リリース Ver 0.9.1 - (2011/12/19)]]
26112
27113 ・PHP版のOkuyamaClientの不具合対応
Show on old repository browser