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

【问题标题】：Backup scheme for non-volatile C++ map constructs非易失性 C++ 映射结构的备份方案
【发布时间】：2012-03-12 16:44:58
【问题描述】：

我经常在我的 C++ 代码中使用 std::map 或 tr1::hashed_maps。我有一个即将到来的项目，我通常会默认使用此类构造，但是在这个项目中，我要求此类地图是非易失性的。 IE。在应用程序终止时（安全关闭或意外终止，例如断电），地图数据应安全存储在磁盘上，并在后续应用程序执行时恢复。请注意，这并不要求存储断电前的每一位数据，只需在几秒钟前存储即可。

要求仍然是应用程序必须是高性能的，在对地图的访问和存储方面。显然“高性能”是主观的，但每秒会有数百万次加载/存储到地图中。

这让我“猜测”我应该使用 SQL 数据库，但是我对数据库缺乏经验，并且担心从简单的 C++ 容器迁移到完整的 SQL 基础架构会出现相当大的性能下降。 SQL“缓存”结果是否会以某种方式减轻性能影响？

或者，一个简单的答案可能只是频繁（比如每 10-30 秒）将映射的副本写入（序列化）到磁盘。根据地图的大小，这将很大（至少数百万个条目），这可能是不明智的。

有什么推荐吗？

谢谢！

【问题讨论】：

你可以试试placement new和mmap。 [stackoverflow.com/questions/2650034/…[1]：stackoverflow.com/questions/2650034/…

标签： c++ database stl map backup

【解决方案1】：

用最好的锤子敲钉子，尽管事实上你最喜欢你的 c++ 锤子（我会在同一条船上。）

听起来数据库在性能和数据完整性方面将是您的最佳选择。它们旨在处理您在帖子中描述的那种场景。

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

为您要存储的信息类型开发可靠的数据库模型。我不是这方面的专家，但我知道做到这一点很重要。
对一个好的 C++ 数据库包装器进行一些研究。这样您就可以将 MySQL 的详细信息留给库，您可以专注于自己最擅长的地方。

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：

如果存储频率较低（每秒 100 次或 1000 次）但每秒仍有数百万次负载，性能方程式是否会改变？

【解决方案4】：

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

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

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

【讨论】：

谢谢 - 我想这会给我地图的速度，数据库作为它背后的备份

【解决方案5】：

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

当有人想要关闭您的应用程序时，他们希望它能够相当迅速地关闭，而不是停留很长时间。如果它不下去，他们很可能会杀死它。
如果他们“崩溃”，您的数据将不会被保存。

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

在关闭时，您会写入任何剩余的脏记录，但不会很多。

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

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

【讨论】：