非易失性C++映射结构的备份方案

使用最好的锤子钉钉子，尽管事实上你对你的c++锤子最满意（我会在同一条船上。）

就性能和数据完整性而言，数据库似乎是您的最佳选择。它们是为了处理你在帖子中描述的那种场景而构建的。

那么，我认为你需要做的两件事是：

• 为您想要存储的信息类型开发一个坚实的数据库模型。我不是这方面的专家，但我知道做好这件事很重要
• 对一个好的C++数据库包装器做一些研究。这样，您就可以将MySQL的详细信息留给库，并可以专注于您最强大的地方

如果未来没有增强功能的计划，那么简单的C++方法是好的。Redis或Cassandra等关键价值商店可能非常适合您的需求。它们透明地处理存储和中断，并在一台机器不足时增强对多台机器的存储。它们的性能非常好，在某些情况下甚至可能优于C++代码。除非在多台计算机上运行，否则完整的SQL数据库对于您的目的来说太慢了。

如果每秒有数百万个存储到映射，那么一个足够快的SQL将非常涉及到一些你似乎是事后才想到的事情。密钥库可能对你的应用程序更好，但如果你真的达到了性能极限，你可能会考虑只写一个你对内存存储进行更新的日志。您可以从日志中重建内存中的存储，以满足您的持久性要求。

您仍然可以使用您的地图，它被包裹在处理地图上操作的对象中。修改映射的操作除了修改内存中的映射外，还会更新磁盘上的存储。

然后，您的下一个问题将是确定哪种存储模型最适合您的数据，例如sql数据库，或者可能是记录所有更新的日志，也可能是具有固定大小记录和您自己的索引方案的二进制文件。

如果还要求数据库可以在几个用户之间共享，每个用户都可能更新数据库，那么您还需要添加一种机制来保持地图同步。。。也许到那时，总是查询会变得更容易。但在任何情况下，到那时您的对象都可以处理数据上的所有操作，并且只需要替换该对象的内部。

我不是您的应用程序的用户，但在关闭时存储大量数据是个坏主意，原因有很多：

• 当有人想关闭你的应用程序时，他们希望它能很快关闭，而不是停留很长时间。如果它不倒下，他们很可能会杀死它

• 如果他们"崩溃"，您的数据将无法保存。

因此，定期保存是一个更好的主意，为此，当行当前未保存时，您可能希望将其标记为"脏"，这意味着您可能希望有更多数据来标记脏记录。这可以通过一组简单的键或向量来完成，这些键的数据是脏的，并定期保存它们并删除它们的脏状态。

在关闭时，你会写下任何剩余的脏记录，但不会有太多。

这在很大程度上取决于地图更改的频率。

还要记住，用户交互应该始终具有最高优先级，并且任何"脏"成员对持久性的提交都应该发生在优先级较低的后台线程中。