C++ 避免数据损坏的文件结构

我目前正在为监控系统升级我们当前的媒体存储（存储视频/音频/元数据），并将录制结构重新设计为更强健的解决方案

我需要为存储在数据文件中的数据创建一些索引数据，因此我正在创建一个索引文件结构，但我担心的是硬盘故障（想象一下，如果在写入索引文件的过程中断电，它将变得不正确，因为数据很可能被写入了一半）。 我已经设计了索引的存储方式，但我担心的是电源故障或磁盘故障时的数据损坏

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

我已经搜索了一点，没有找到好的解决方案，一个解决方案是创建一个记录写入文件的所有内容的日志，但是我每秒会有更多的I/O（我也关心每秒I/O的数量，系统应该尽可能地执行最少的操作）

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

字段1字段2字段3时间戳校验和

字段1字段2字段3时间戳校验和

因此，我将数据写入了两次，如果在读取文件时，第一组字段已损坏（校验和不匹配），那么第二组字段应该可以。我相信当写在中间时，如果发生了损坏，例如，当软件写第一组字段和断电时，第二组仍然完好无损…如果在写入第二组数据时出现电源故障，则第一组数据已完好无损

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

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

---

欢迎提出任何意见，谢谢

忽略问题中关于无法使用数据库的部分：）

您可能会找到感兴趣的SQL Server 2012文件表。您可以将数据库外部的文件存储在文件夹中，但仍可以像访问数据库内部的文件一样访问这些文件。您可以使用数据库将新文件插入到该目录，或者只需将文件复制到文件夹中。你的数据库不会因为视频文件而变得很胖。如果db服务器软件宕机，它们也无法访问。您的帧索引可以是单个.jpg文件（或其他任何文件），这些文件也可以由文件表引用，并通过外键索引到主视频文件。框架索引表是非常直接的

---

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

这并不能避免数据损坏，因为损坏可能发生在任何一个或两个字段集上

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

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

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

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

关于“交易”有太多的理论

搜索“原子事务算法”以获取更多详细信息

---

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

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

使用数据库，而不是重新发明轮子。你说你不能使用数据库，但这听起来是假的。到底为什么不呢？我和大卫在一起，使用数据库是更现实的方式，检查firebird，在监控行业软件中，数据库从来没有用来存储视频/音频数据，而是用来存储配置、日志，但不是与视频/音频相关的数据。。。视频/音频文件必须是独立的，就像视频文件（.AVI，WMV…）一样。对于我们需要实现的性能，数据库系统也有太多的控制和开销。如果我需要存储常规数据，我肯定会使用数据库。我理解您对性能的担忧，但我仍然会听取上述建议，在重新发明轮子之前，先研究数据库系统。考虑那些在你移动之后必须支持你的创作的成本：）有你可以使用的不需要数据库部署的嵌入式数据库系统，比如DBISAM。谢谢你的想法。我已经考虑过使用数据库，但是对于我需要的结构，数据库的使用和它可以添加的记录数量的限制，以及在监视上重新分配数据库系统