我有 100 万亿个元素，每个元素的大小从 1 字节到 1 万亿字节（0.909 TiB）。如何存储它们并非常有效地访问它们？答案

【问题标题】：I have 100 trillion elements, each of them has size from 1 byte to 1 trillion bytes (0.909 TiB). How to store them and access them very efficiently?我有 100 万亿个元素，每个元素的大小从 1 字节到 1 万亿字节（0.909 TiB）。如何存储它们并非常有效地访问它们？
【发布时间】：2012-01-17 05:28:45
【问题描述】：

这是一道面试题：

假设：我有 100 万亿个元素，每个元素的大小从 1 字节到 1 万亿字节（0.909 TiB）。如何存储它们并非常有效地访问它们？

我的想法：他们想测试有关有效处理大量数据的知识。这不是一个只有一个正确答案的问题。

将它们保存到一些特殊的数据结构中？

其实我对这种开放式问题一无所知。

非常感谢任何帮助。

【问题讨论】：

1 万亿字节！= 1 GB
别无礼，但你确定你想要一份问你一个你不知道如何处理的问题的工作吗？
确实，100 万亿个一字节对象将是 100 TB (90 TiB) 的原始数据，不包括开销。在这种规模下，您不必担心数据结构，而是担心基础设施。
这真的取决于您系统的可用资源。像这样的假设性问题，可能有假设性答案和现实性答案。
购买谷歌并使用他们的基础设施 ;-)

标签： algorithm data-structures save large-data-volumes

【解决方案1】：

最简单、成本最低（至少在您大规模扩展之前）的选择是使用现有服务，如 Amazon S3。

【讨论】：

【解决方案2】：

我会使用B-tree 的某种分布式形式。 B-tree 能够以非常好的访问时间存储大量数据（树通常不是很深，但很宽）。由于这个属性，它被用于关系数据库中的索引。并且在许多节点（计算机）之间分发它也不会很困难。

我想，这个答案应该足够面试了……

【讨论】：

【解决方案3】：

这实际上取决于所讨论的数据集。我认为重点是让您讨论替代方案并描述各种优缺点。

也许你应该用更多的问题来回答他们的问题！

需要如何访问它？（顺序，随机，一些可预测的分布？）
元素的顺序重要吗？
元素的大小会改变吗？
插入/删除性能有多重要？

您选择的数据结构将取决于您愿意做出什么样的权衡。

例如，如果您只需要按顺序遍历集合，也许您应该使用链表，因为它的存储开销相对较小。

如果您需要随机访问，您可能需要研究：

哈希表（恒定时间查找，但需要一个良好的数据哈希函数）
某种索引/树结构？
缓存！您可能无法将其全部保存在内存中 - 即使可以，您也希望尽可能利用数据局部性。

TL;DR：这完全取决于问题。有很多选择。

这与文件系统/数据库所面临的问题基本相同。

【讨论】：

我看到 TL;DR 并以为我在不同的站点ಠ__ಠ

【解决方案4】：

好吧，我会使用 DHT 并将其拆分为 8MB 的块。然后有一个包含文件哈希（SHA-1 256）、文件名和块的表。

这些块将被存储在 3 个不同的 NAS 中。拥有 1200 TB NAS 服务器和负载均衡器，以获取当时更方便获取的 3 个副本中的任何一个。

【讨论】：