避免数据损坏的文件结构

Posted 2023-02-16

【中文标题】避免数据损坏的文件结构

【英文标题】：File structure to avoid data corruption

【发布时间】：2012-04-17 16:47:55

【问题描述】：

我目前正在为监控系统开发我们当前媒体存储的升级（用于存储视频/音频/元数据），并且我正在重新设计记录结构以提供更强大的解决方案。

我需要为存储在数据文件中的数据创建一些索引数据，所以我正在创建一个索引文件结构，但我担心硬盘故障（想象一下如果在写入索引期间断电文件，它会损坏，因为数据很可能会被写入一半）。 我已经设计了索引的存储方式，但我担心的是电源故障或磁盘故障导致的数据损坏

那么，有人知道在写入时避免数据损坏的技术吗？

我已经进行了一些搜索，但没有找到好的解决方案，一种解决方案是创建写入文件的所有内容的日志，但是我每秒将有更多的 I/O（我担心数量每秒的 I/O 数，系统应该尽可能少地执行）。

我想出的是在索引文件中复制敏感数据以及时间戳和校验和字段。例如：

Field1 Field2 Field3 时间戳校验和

Field1 Field2 Field3 时间戳校验和

所以，我将数据写入了两次，如果当我读取文件时，第一组字段已损坏（校验和不匹配），我有第二组字段应该没问题。我相信如果在中间停止写入时会发生损坏，因此，例如，当软件正在写入第一组字段并且电源故障时，第二组仍然完好无损......如果电源故障而第二set 正在编写中，第一个已经完好无损。

你们觉得这个解决方案怎么样？是否避免数据损坏？

顺便说一句，由于部署具有事务性 NTFS 的系统的限制，我不能将任何类型的数据库用于这种存储或事务性 NTFS

欢迎任何想法，谢谢！

【问题讨论】：

使用数据库而不是重新发明***。你说你不能使用数据库，但这听起来很假。为什么不呢？

我和大卫，使用数据库是更现实的方式，检查火鸟How much time it takes to recover a Firebird database after a power failure?

嗯，在监控行业的软件中，数据库从不用于存储视频/音频数据，而是用于存储配置、日志，而不是与视频/音频相关的数据... Video/音频文件必须是独立的，就像视频文件（.AVI、WMV...）一样。对于我们需要实现的性能，数据库系统也有太多的控制和开销。如果我需要存储常规数据，我肯定会使用数据库。

我理解您对性能的担忧，但我仍然会听取上述建议并首先研究数据库系统，然后再重新发明***。考虑那些在你继续前进很久之后必须支持你的创作的成本:)

您可以使用不需要数据库部署的嵌入式数据库系统，例如 DISAM。

【参考方案1】：

忽略您关于无法使用数据库的部分问题:)

您可能会对 SQL Server 2012 的 FileTables 感兴趣。您可以将文件存储在数据库之外的文件夹中，但仍可以像访问数据库中的文件一样访问这些文件。您可以使用数据库将新文件插入到该目录或简单地将文件复制到文件夹中。您的数据库不会因为视频文件而变得很胖。如果数据库服务器软件出现故障，它们也将无法访问。您的帧索引可以是单个 .jpg 文件（或其他文件），并且这些文件也可以由 FileTable 引用，并通过外键索引到主视频文件。那么帧索引表就非常简单了。

因此，您消除了写入文件和维护日志以查看是否出现故障的数据库开销。如果操作系统由于电源故障而无法写入文件，那么数据库将没有机会。您可以进行目录比较，并使用强大的实用程序来移动文件，而不是在任何部分写入失败时删除源文件。

【参考方案2】：

它不能避免数据损坏，因为损坏可能发生在任何一组或两组字段上。

我认为您最好不要复制“敏感数据”，而是分两步写入该数据，第一步写入“校验和”字段为空的数据，第二步使用匹配的校验和更新校验和数据。此校验和将用作“事务已提交”标志并确保数据完整性。

当您读取数据时，您会忽略所有未提交的索引集，我的意思是校验和不匹配的位置。

然后进行大量测试和微调，在过程的每一步强制数据损坏，并保存随机数据。我个人认为测试需要做很多工作，因为失败是随机的，这就是为什么人们建议你使用经过多年测试的数据库。

请注意，虽然它增加了对某些类型数据损坏的保护，但它并不完美，您可以添加其他安全层来保护您的数据，包括数据复制、完整性检查和外部配置，包括不间断、RAID 系统、定期备份。

关于“交易”的理论太多了。

搜索“原子交易算法”以获取更多详细信息。

重新考虑使用数据库，重新考虑使用日志，甚至重新考虑使用文件系统来存储您的信息。

【讨论】：

感谢您的意见。我已经考虑过使用数据库，但是对于我需要的结构，数据库的使用和它可以添加的记录数量的限制，并且在监视应用程序上重新分配数据库系统是困难的。如果数据库是存储这种数据的最佳解决方案，我们所有的竞争对手都会使用，而恰恰相反，这个领域的所有竞争对手的软件都实现了自己的记录结构，因为这就是我们要表现的方式需要

关于你的解决方案，问题是新记录没有附加到磁盘的末尾......它们以固定的结构存储并且不断修改，我的问题是当数据这些索引被修改了，我们在写入数据的过程中出现了电源故障。所以，如果我在更新期间更新了一个字段并且电源故障，我会丢失数据，如果我写两次，我可能会备份旧状态，这就是我所需要的全部

再次阅读您的帖子，只是想明确表示我知道它不会避免损坏，无论如何数据都会损坏，我无法避免损坏我只需要一种方法来轻松恢复损坏的数据

【参考方案3】：

您可以使用某种事务逻辑。以小块创建索引，并首先使用临时文件。当你完成一个块（文件）时，检查完整性并将其复制为实际的索引文件，如果它通过了测试。此时，您可以分发几份已验证块的副本。