タイトルはおそらくもっとうまく付けられたかもしれませんが、とにかく。データベースの ACID プロパティに似た、ファイルへの書き込み機能があるかどうか疑問に思っていました。理由は、電源が切れた場合に、私が行っているファイルの書き込みが混乱したり、ファイルが破損したりしないようにしたいからです。
3 に答える
ファイルとプラットフォームで正確に何をしているかに応じて、いくつかのオプションがあります。
状態を維持するためにメモリからディスクに blob を繰り返しシリアル化する場合 (例: dhcp リース ファイル)、Posix システムを使用している場合は、データを一時ファイルに書き込み、一時ファイルをターゲットに「名前変更」できます。 . Posix 準拠のシステムでは、これはアトミック操作であることが保証されており、ファイルシステムがジャーナリングされているかどうかは問題ではありません。Windows システムを使用している場合は、MoveFileTransactedという名前のネイティブ関数があります。バインディングを介して利用できる可能性があります。ただし、ここでの重要な概念は、一時ファイルがデータを保護するということです。システムが再起動した場合、最悪の場合、ファイルには最新の適切なデータ更新が含まれています。このオプションでは、変更を記録するたびにファイル全体を書き出す必要があります。dhcp.leases ファイルの場合、これは大きなパフォーマンス ヒットではありませんが、ファイルが大きいほど扱いにくくなる可能性があります。
データのビットを絶えず読み書きしている場合は、sqlite3 が最適です。これは、クエリのグループのアトミック コミットをサポートし、独自の内部ジャーナルを備えています。ここで注意すべきことの 1 つは、データベースのロック、データのフラッシュの待機などのオーバーヘッドが原因で、アトミック コミットが遅くなることです。
他に考慮すべき点がいくつかあります。ファイルシステムが非同期にマウントされている場合、write() が返されるため、書き込みは完了したように見えますが、まだディスクにフラッシュされていない可能性があります。この場合、名前の変更はあなたを保護します。sqlite3も同様です。
ファイルシステムが非同期にマウントされている場合は、データを書き込んで、データが書き込まれる前に移動できる可能性があります。そのため、UNIX システムを使用している場合は、sync をマウントするのが最も安全かもしれません。それは「これが失敗したら人が死ぬかもしれない」というパラノイアのレベルです。しかし、それが組み込みシステムであり、それが機能しなくなった場合、「これが失敗すると職を失う可能性がある」ということも、保護を強化するための適切な合理化です。
ZODBは、(ほとんど) python で記述された ACID 準拠のデータベース ストレージであるため、ある意味で答えはイエスです。しかし、これは少しやり過ぎだと想像できます:)
OS がこれを提供する必要があるか、独自の ACID 準拠を実装する必要があります。たとえば、書き込むファイルに「レコード」を定義し、開いたり読み取ったりするときに、どのレコードが書き込まれたかを確認します (これは、完全に書き込まれていないデータを破棄する必要があることを意味する場合があります)。たとえば、ZODB は、レコード自体のサイズを書き込んでレコードを終了することでこれを実装します。このサイズを読み取って一致する場合は、レコードが完全に書き込まれていることがわかります。
そしてもちろん、ファイル全体を書き換えるのではなく、常にレコードを追加する必要があります。
あなたの主な目標は、電源障害やシステム クラッシュが発生した場合に書き込まれたファイルの整合性を確保することだと思われます。これを行う際に考慮すべき点がいくつかあります。
- ファイルを閉じるときに、データがディスクに書き込まれていることを確認してください。閉じても、ディスクに書き込まれるのを数秒間待っているデータの一部が OS キャッシュにある場合があります。f.flush() に続いて os.fsync(f.fileno()) を使用すると、強制的にディスクに書き込むことができます。
- 更新されたデータが安全にディスク上にあることを確認する前に、既存のデータを変更しないでください。この部分は非常に扱いにくい場合があります (OS/ファイルシステムに依存します)。
- データの整合性を検証するのに役立つファイル形式を使用します (チェックサムなどを使用)。
もう 1 つの方法は、sqlite3 を使用することです。
編集: 2 番目の点については、次のプレゼンテーションを強くお勧めします: http://www.flamingspork.com/talks/2007/06/eat_my_data.odp . これは、「アトミック リネーム」の問題もカバーしています。