我知道过去对此有疑问，例如here和here，但是我还没有真正见到能处理非常大的数据集的问题。
因此，我拥有大量结构化的数据（该数据包含有关美国境内流的信息，每个流都有时间序列数据，并且所有流都由唯一的ID标识）。现在，它存储在NetCDF文件中，并且为避免拥有巨大的文件，这些文件被分成较小的段。现在，如果我们只想访问一个流中的数据（因为没有多少人希望同时查看全部270万个流），我们就必须遍历所有NetCDF文件并提取该一个流的数据。我们还构建了一个REST API（django-rest-framework），该API对调用端点的任何人都具有相同的作用。
我认为，就效率而言，似乎有更好的方法。我曾考虑过建立一个包含所有数据的数据库，但令我担心的是，这实际上可能比仅循环访问所有文件要慢，因为将所有数据放在一个位置会占用多个TB的磁盘空间。我正在阅读有关this的有关MongoDB的文章，看来他们的产品可以帮助解决此问题。 我的问题是，将所有这些数据存储在数据库中会节省检索数据的时间吗？实现起来会有多困难？
答案 0 :(得分：1)
简短的回答是“也许”。
更长的答案是，这取决于几个因素：
1.正确构造数据。这意味着将不相关的数据拆分为单独的文档，在相关数据之间正确创建关联等。
2.正确索引数据。例如，如果您有代表流的各个“块”的文档，并且具有“流ID”以标识块所属的流，那么具有“流ID”字段的索引将确保您可以有效地抓取所有该流的大块。
3.您拥有的资源。您可能需要研究数据库的水平扩展，即分片，这将需要您真正了解自己在做什么。您可能需要专门的DBA来处理数据的设置和维护，尤其是在进行复制以避免丢失一个节点而完全杀死数据集的情况下。这要花钱。
4.您能够正确和准确将所有数据迁移到数据库中。一个小小的失误可能意味着您丢失了重要的数据块，或者没有应关联的数据，或者数据输入错误或类型错误，或者出现了许多问题。
绝对建议您使用数据库。即使具有如此大量的数据，仅索引和数据分离也将对数据检索的效率产生巨大影响。如果没有其他问题，那么减少的文件I / O和摆脱对文件内容的直接分析应该会使事情变得更快。但是，如果要使用数据库，则需要格外小心。如果您需要保留数TB的现有数据，那么就不应该进行大量工作。您将需要经验丰富的人来处理迁移，设置和长期维护。这不是轻功。