Algorithm 加入非常大的名单

让我们先输入一些数字： 其中最大的一项是大约1亿条记录。（但预计将增长到500）。其他名单（其中5-6个）以百万计，但在可预见的未来不到1亿。 这些参数始终基于单个id进行连接，而不会与任何其他参数进行连接。 加入这些列表的最佳算法是什么

我在考虑分布式计算。有一个好的散列（循环散列类型，可以添加一个节点，并且没有太多的数据移动）函数，并将这些列表拆分成几个较小的文件。由于它们总是在公共id上连接（我将对其进行哈希处理），因此可以归结为连接到小文件。也许可以使用nix join命令来实现

DB（至少是MySQL）将使用merge join进行连接（因为它位于主键上）。这会比我的方法更有效吗

我知道最好的办法是测试和观察。但是考虑到这些文件的重要性，它相当耗时。我想做一些理论计算，然后看看它在实践中是如何公平的

---

对这些或其他想法的任何见解都会有所帮助。我不介意花的时间稍微长一点，但我更愿意最好地利用我现有的资源。不要有庞大的预算：）

使用数据库。它们是为执行连接而设计的（当然有正确的索引！）

也许可以使用基于Hadoop的解决方案，如HBase？所有列表是否有序？小名单是否有序？（如果是这样，可以使用不同的切片技术来划分处理）。其他相关问题-您有多少CPU内核，每个处理节点有多少RAM，数据集消耗多少RAM，是否有共享存储？直觉告诉我们，最好的选择是将主列表拆分为N（其中N是CPU核心数），然后加入其他文件的相关子列表。我认为您使用散列是对的-只有在以后需要重复获取数据时，DB和B树索引才会有回报。@JulesLt我有选择权。因此，如果我希望对它们进行排序，我必须在新行进入/删除时保持顺序。我将仔细考虑你建议的CPU数学，稍后再回答@ar：谢谢，我会查的！但除非我做一些切分。数字相当高。所以我可以想象，我将不得不在db的外部1亿行之间进行最终合并，但实际上并没有那么大。通常的经验法则是考虑在5000万行左右使用表分区。