c++ - C++应用程序中的非永久巨大外部数据存储

Question

我正在重写一个处理大量数据（约100 GB）的应用程序，该应用程序被设计为关系模型。

该应用程序非常复杂。它是一种用于转换巨大街道（整个世界）的开放街道地图数据的转换工具，并将其转换为地图文件供我们自己的路线规划软件使用。例如，转换器应用程序将开放式街道地图中的节点及其坐标及其所有标签保存在其中（不仅限于此，但这应作为该问题的一个示例）。

现在的情况：

由于此数据非常庞大，因此将其拆分为几个文件：每个文件都是从ID到原子值的映射（让我们假设节点的标记列表是原子值；不是，但是数据存储可以这样对待）。因此，对于节点，我有一个保存节点坐标的文件，一个保存节点的名称，另一个保存节点的标签，其中节点由（非连续）ID标识。

该应用程序曾经被拆分为多个应用程序。每个应用程序都处理转换的一个步骤。因此，这样的应用程序仅需要处理文件中存储的某些数据。例如，并非所有应用程序都需要节点的标签，但是很多应用程序都需要节点的坐标。这就是为什么我将关系拆分为文件，每个“列”一个文件。

每个处理步骤都可以一次将整个文件读入RAM中的数据结构。这样可以确保查找效率很高（如果数据结构是哈希图）。

我目前正在重写转换器。现在它应该是一个单一的应用程序。现在，它不应为每个“列”使用单独的文件。它应该使用一些众所周知的体系结构以关系方式（例如数据库）来保存外部数据，但是要快得多。

=>哪个库可以提供以下功能？

要求：


它需要非常快地遍历现有数据（虽然不修改行集，但修改当前行中的某些值）。
它需要提供恒定或接近恒定的查找，类似于哈希映射（同时完全不修改整个关系）。
大多数类型的列都是不断调整大小的，但总的来说不是。
它需要能够以恒定的或对数的时间将新行追加到关系中。不需要实时更新某种搜索索引。在整个处理步骤完成之后，可能会更新（重建）索引。
有些关系是基于键值的，而另一些则是（连续索引的）数组。两者都应提供快速查找。
它不应该是一个单独的过程，就像MySQL这样的DBMS一样。查询的数量将是巨大的（大约100亿），并且将完全成为性能的瓶颈。但是，缓存查询可能是一种解决方法：批查询中可能会在单个查询中完成整个表的迭代，而写入表时（在同一处理步骤中不会读取任何数据）。但仍然：我想序列化，进程间传输和反序列化SQL查询将成为瓶颈。
精巧：易于使用。如果可以以与C ++标准和Qt容器类类似的方式使用关系，那将非常好。


不需要（为什么我不需要DBMS）：


同步同一关系的读写。该应用程序分为多个处理步骤。每个步骤都有一组读取的“输入关系”和写入的“输出关系”。但是，某些步骤需要读取一个关系的某些列，同时写入相同关系的其他列。
加盟关系。在不同的关系之间有一些交叉引用，但是，如果查找足够快，则可以在我的应用程序中解析它们。
永久存储。转换完成后，将不再需要所有数据。
基于键值的关系永远不会被重新设置；基于数组的关系将永远不会重新索引。

Answer 1

我可以根据您尚未在问题中量化的许多因素来考虑几种可能的解决方案。

如果您希望一个简单的存储查找内容并且有足够的磁盘，则SQLite作为数据库非常有效。请注意，没有SQLite服务器，“服务器”已链接到您的应用程序。

就个人而言，此工作有可能是embarrassingly parallel。我认为小的Hadoop cluster可以使整个工作快速完成。您可以在AWS中旋转它，处理数据并以非常便宜的价格关闭它。