问具有150 m唯一标签的文本文件快速读取的API架构设计

EN

一般来说，这似乎是ETL流的一个典型案例:获取新文件、提取数据、将其转换为您的格式并加载到您的DB。一些注意事项：

1. 重要的是要记住的是，加载和查询是不同的和完全无关的操作。一个问题是“当90%的记录重复时，如何有效地将每天的1.5亿记录文件加载到数据存储中”，另一个问题是“如何有效地查询一个150m记录密钥/值存储”。分别回答这两个问题，因为它们是独立的。
2. 对于第一个问题，你担心加载90%相同的记录是一种浪费。你量过时间了吗？从文本文件中读取150 m条记录需要几秒钟，而一个好的密钥/值存储应该能够优化冗余的更新操作。或者，将新文件与前一个文件区分开来，创建一个实际的更改列表，作为ETL流的一部分，然后继续加载。定义此解决方案的度量标准(读取、差异、加载、加载时查询操作的中断等)，以便您可以评估解决方案。
3. 对于问题2，当现成的选项存在时，避免实现自定义解决方案.ElasticSearch可能会过度使用，因为您只是在存储键整数，但是有大量的键/值存储将为您提供良好的读取性能，包括磁盘支持的内存缓存、MRU缓存或不同的缓存策略(取决于您的使用情况)，可能还有前面提到的无操作更新操作，等等。同样，就像问题1一样，定义衡量成功的标准。您说“将5GB加载到RAM中是很昂贵的。是吗?您的服务器有多少RAM ?您考虑缓存普通查询吗?有必要吗?非缓存读取的速度有多快?测量！您是否需要使用自定义缓存策略，比如使用相关记录?检查您的使用模式。”

我不能告诉你最好的方法是什么。只有你知道的变量太多了--你的预算和使用模式，系统的未来计划和扩展潜力，与第三方数据源的关系(例如，它们是否可以被说服只生成差异，或者为记录添加时间戳/版本标签等等)。我所能做的就是建议核心模式:将摄入流从查询流中分离出来，使用尝试过的和经过测试的工具，以及最重要的是度量、度量、度量。

您可以考虑D.J.Bernstein的国开行所采用的方法，即：

cdb是一个用于创建和读取常量数据库的快速、可靠、简单的包。它的数据库结构提供了几个特性:快速查找:在大型数据库中成功查找通常只需要两次磁盘访问。不成功的查找只需一次。低开销:数据库使用2048字节，加上每个记录24个字节，加上键和数据的空间。没有随机限制: cdb可以处理高达4G的任何数据库。没有其他限制；记录甚至不需要放入内存中。数据库以与机器无关的格式存储.快速原子数据库替换: cdbmake可以比其他散列包快两个数量级来重写整个数据库。快速数据库转储: cdbdump以与cdbmake兼容的格式打印数据库内容。cdb被设计用于像电子邮件这样的关键任务应用程序.数据库替换对系统崩溃是安全的。在重写过程中，读者不必停下来。

您可能需要一个更现代的实现，它没有4GiB限制，比如这 one。