*バックアップデータ構造の改善 [#pc299b0e]
-ページ: [[BugTrack2]]
-投稿者: [[Cue]]
-優先順位: 低
-状態: 提案
-カテゴリー: 本体新機能
-投稿日: 2005-08-31 (水) 03:50:07
-バージョン:
**メッセージ [#v43ed818]
**従来の仕様と特徴 (- PukiWiki 1.4.6) [#m5a5c2e9]
***バックアップファイル構造 [#i562cea6]
+バックアップファイル1ファイルの中にそのページの全ての世代が保存されている
++ディスクスペースは少なくて良い(特に小さいページが沢山ある場合)
+Boundaryは、PKWK_SPLITTER\sUTIME\n
+データ中にBoundaryが現れた場合、行末に半角スペースを加える
++保存データに手を加えるので処理としては良くない
++PKWK_SPLITTERは過去にはglobal $splitter
++\sに半角スペース以外が使われた事はない
+zlib extensionの有無でファイル形式が変わる((PHP 4.3.0 以降、zlib モジュールは php バイナリにビルトインされたため、PHP4.2.x以前＋zlibなし→PHP4.3.0以降でのみ発生する))
++設置サーバーの状況が変わると手作業しか移行手段がない(zlib無で.gz対応は不可能)
++Boundaryも含めて圧縮されるので、一部の損傷が全滅につながる
***backup.php内で外部からコールされる関数 [#ybb94d95]
-make_backup バックアップ追加処理
-get_backup バックアップ全データの取得(過去には一覧取得と各データ取得で分けられていたようだが今は全取得しか使われていない)
-_backup_file_exists バックアップの有無確認
-_backup_delete バックアップの全削除
-直接データ構造にアクセスする個所
--dump.inc.php、backup.inc.php(バックアップの存在する全ページ名の取得)
***backup.inc.phpとの連携部など [#sad248ef]
+常に解凍された全データを要求する
++複数回のファイル読み込みと解凍を要さない
++バックアップファイルが大きくなると処理の負荷が大きい(BugTrack/732)
+各バックアップは世代番号で管理される。世代番号はバックアップファイル内に存在する順で割り当てられる
++一覧表示から各データの取得までにバックアップ処理が起こると世代番号がずれる
+バックアップ日時は、そのページの前回の最終更新日時(そのデータが作られた日時)が割り当てられる
++タイムスタンプを変更しない編集を繰り返すと同じタイムスタンプのバックアップが複数作られる(BugTrack/685)
+$cycle=0 でも同一タイムスタンプでバックアップは働かない
++重いバックアップ処理を連打されずにすむ
++UTIMEでtouchはしていないので処理が重い場合など若干のずれが生じる
#comment
** 問題点 [#p5cf8c63]
*** backupに対する既存の機能要望 [#xda38abf]
+自動生成されるページを含めて基本は全ページが対象(BugTrack/708)
+世代を指定してバックアップを削除できない([[org:欲しいプラグイン/137]])
+通常バックアップと別に版管理を行いたい(BugTrack2/86)
--バックアップ時刻の外に一覧用の別データを埋め込める構造にする？要望した人は別の方法を見付けたみたいですが。
+ backupじゃなくて(あるいは選択式で)データベースが使えるようになって欲しい
--backup.phpをカプセル化して標準データとの相互変換コードを用意すれば内部構造をどう変えても対応可能
#comment
**改善案 [#j62ef48c]
***1ファイルは維持し、日付部分は圧縮しない案 [#f7b3dda2]
+ファイル読み込み・一覧作成の段階で解凍は発生しないので比較的低負荷
+一部が損傷しても全体に影響は及ばない
+ディスクスペースは若干増える
+圧縮部分に偶然Boundaryが現れる可能性にどう対処するか
++普通は各ブロックサイズを記録しておいてfseekしながら飛ばし読みする
***各バックアップ世代をページ名のディレクトリ下に独立ファイル化する案 [#ybc4136a]
+一覧作成はディレクトリ検索速度に依存する(必要メモリは少ないが、システムコールは多いはず)
+一部が損傷しても全体に影響は及ばない
+ディスクスペースは増える(特にFATファイルシステムで)
+Boundaryとバックアップ読み込み時のflock処理が不要
+特定の世代だけ削除するのが容易(ftpでも可能)
+dump.inc.phpが1ファイル状態を前提にファイルにアクセスしている
++データ構造に直接アクセスすべきではない。必要ならAPIを作る。
***CVS likeに差分のみで全体を構成する案 [#a33815f5]
+無圧縮でも非常に小さいサイズになる
++昨今の状況ではディスクスペースをそれほど重視しなくて良いのでは？
***世代管理にバックアップ時刻を使う案 [#s2f006dc]
+ページのタイムスタンプを変更しなくても編集した時刻が分かってしまう
++Recentには影響しないので構わないのでは？
+ページの最終更新日時はlast-modified headerにも使われるので、タイムスタンプを更新しない場合でも変更した方が良いはず。Recentに入れない等の処理は別の方法で実現した方が良いのでは？
+暫定的に差分の最終更新日時から得る方法もあり
***backup.phpに必要とされるAPI [#e61473b0]
+バックアップの追加 (現在のmake_backup)
+バックアップの有無 (現在の_backup_file_exists)
+バックアップデータ一覧の取得
+ある世代のバックアップデータの取得
+バックアップの全削除 (現在の_backup_delete)
+バックアップの部分削除
+バックアップの存在する全ページ名の一覧取得
+バックアップデータを標準データと相互変換する機能
-get_backupでの全取得はやめる
-どの形式を標準データにするか？
--互換性で問題がないのは現在の構造で無圧縮
-dump.inc.phpは標準データを扱うようにする
-バックアップデータの変換はタイムアウト対策が必須
-バックアップデータを一行ずつの配列(file()で読み込んだソース相当)で渡す必要はないのでは？
--(array)$multi_line_strの形で返しても問題無いみたいです
----
-過去(現状の調査と把握)を踏まえて進めようとされていて、ここにわかり易く解説していらっしゃる、それだけでも素晴らしい仕事だと思います ;) -- [[henoheno]] &new{2005-09-01 (木) 23:10:03};
-他に気付いた点や案があれば追加お願いします。 -- [[Cue]] &new{2005-09-03 (土) 00:39:25};
- 過去ログの世代管理についてですが、logrotateのようにファイル名に.1/.2とつけていく。というだけでも良い気がします。 -- [[romap]] &new{2005-09-15 (木) 14:18:45};
#comment
** 実装案 [#g5fd6c9d]
- => [[BugTrack2/103/idea1]]
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
