我有很多數據想以二進制形式保存到磁盤，我想盡可能接近具有 ACID 屬性。由于我有大量數據并且無法將其全部保存在內存中，因此我知道我有兩種基本方法：有很多小文件（例如每分鐘左右寫入磁盤） - 如果發生崩潰，我只會丟失最后一個文件。然而，性能會更差。有一個大文件（例如打開、修改、關閉） - 之后的最佳順序讀取性能，但如果發生崩潰，我最終可能會得到一個損壞的文件。所以我的問題是：如果我選擇使用大文件選項并將其作為內存映射文件（或使用Stream.Positionand Stream.Write）打開，并且斷電，是否可以保證文件可能會發生什么？是否有可能丟失整個大文件，或者最終導致數據在中間損壞？NTFS 是否確保一定大?。?k？）的塊總是被完全寫入？Unix/ext4 上的結果更好/更差？我想避免使用 NTFS TxF，因為微軟已經提到它計劃停用它。我正在使用 C#，但語言可能無關緊要。（補充說明）似乎應該有一定的保證，因為 - 除非我錯了 - 如果在寫入文件時可能會丟失整個文件（或遭受非常奇怪的損壞），那么現有的數據庫將不會是 ACID，除非他們1) 使用 TxF 或 2) 在寫入之前復制整個文件？如果您丟失了您甚至不打算觸摸的部分文件，我認為日記不會幫助您。
2 回答
PIPIONE
TA貢獻1829條經驗 獲得超9個贊
您可以調用FlushViewOfFile，它啟動臟頁寫入，然后FlushFileBuffers，根據本文，它保證頁面已被寫入。
每次寫入后調用FlushFileBuffers可能“更安全”，但不建議這樣做。你必須知道你能承受多少損失。有一些模式可以限制這種潛在的損失，即使是最好的數據庫也可能遭受寫入失敗。您只需要以盡可能少的損失恢復生活，這通常需要一些多階段提交的日志記錄。
我想可以打開內存映射文件， FILE_FLAG_NO_BUFFERING但這FILE_FLAG_WRITE_THROUGH會消耗你的吞吐量。我不這樣做。我為異步 I/O 打開內存映射文件，讓操作系統通過它自己的異步 I/O 完成端口實現來優化吞吐量。這是最快的吞吐量。我可以容忍潛在的損失，并已適當減輕。我的內存映射數據是文件備份數據......如果我檢測到丟失，一旦硬件錯誤被清除，我可以檢測并重新備份丟失的數據。
顯然，文件系統必須足夠可靠才能運行數據庫應用程序，但我不知道有任何供應商建議您仍然不需要備份。壞事會發生。計劃損失。我做的一件事是我從不寫入數據中間。我的數據是不可變的和版本化的，每個“數據”文件限制為 2gb，但每個應用程序采用不同的策略。
ITMISS
TA貢獻1871條經驗 獲得超8個贊
NTFS 文件系統（和 ext3-4）使用事務日志來操作更改。每個更改都存儲在日志中，然后日志本身用于有效地執行更改。除了災難性的磁盤故障外，文件系統被設計為在其自己的數據結構中保持一致，而不是您的：在崩潰的情況下，恢復過程將決定回滾什么以保持一致性。在回滾的情況下，您的“尚未寫入但要寫入”的數據將丟失。文件系統將是一致的，而您的數據則不是。
此外，還涉及其他幾個因素：軟件和硬件緩存引入了一個額外的層，因此是一個故障點。通常操作是在緩存中執行的，然后緩存本身會刷新到磁盤上。文件系統驅動程序不會看到“在”緩存中執行的操作，但我們會看到刷新操作。這樣做是出于性能原因，因為硬盤是瓶頸。硬件控制器確實有電池，以保證即使在斷電的情況下也可以刷新自己的緩存。
扇區的大小是另一個重要因素，但不應考慮此細節，因為出于互操作性目的，硬盤驅動器本身可能與其原始大小有關。
如果你有一個 mewmory 映射并且你在中間插入數據，當電源關閉時，如果文件的內容超過了內部緩沖區的大小，則文件的內容可能部分包含你所做的更改。
TxF 是一種緩解問題的方法，但有幾個影響限制了您可以使用它的上下文：例如，它不適用于不同的驅動器或共享網絡。
為了成為 ACID，你需要設計你的數據結構和/或你使用它的方式，以免依賴于實現細節。例如，Mercurial（版本控制工具）總是將自己的數據附加到自己的修訂日志中。有許多可能的模式，但是，您需要的保證越多，您獲得的技術就越具體（并且與之相關）。
- 2 回答
- 0 關注
- 170 瀏覽
添加回答
舉報
0/150
提交
取消