Question

我在~10MB .csv文件中保存了大约100GB的数据。如何针对此数据优化数千个查询的查找速度？具体来说，我不知道要考虑哪些技术或如何估计相对性能。

每个文件对于日期都是唯一的，并且包含多个人的数据，例如：

...
2005-07-03, "Daffy Duck", ...
2005-07-03, "Daffy Duck", ...
2005-07-03, "Mickey Mouse", ...
2005-07-03, "Mickey Mouse", ...
...

我想提取与给定日期/名称相对应的所有信息，数千个日期/名称对。等效的SQL查询将是SELECT * FROM myDB WHERE Date='2005-07-03' AND Name='Mickey Mouse'。

目前我还没有将数据加载到数据库中。要执行我的“查询”，我找到相应的日期文件，并按我要查找的名称过滤行。我是否可以在关系数据库，noSQL数据库或其他任何方式中存储数据？如果是这样，为什么以及多少？

Answer 1

我是否可以在关系数据库，noSQL数据库或其他任何方式中存储数据？

是（我建议使用'普通'RDBMS）

如果是，为什么......

这是索引所针对的事情之一

......以及多少？

大量

Answer 2

我将在这里讨论一个魔鬼的拥护者并说你可能无法通过关系数据库或任何其他数据库“系统”获得相对于放置所有工作所需的工作的更好的性能将这些数据存入数据库。

尽管我建议将数据加载到某种数据库（即完整的编码数据管理系统），但您的文件很小。从您的问题来看，听起来您可以在恒定时间内识别所需的文件，然后只需要读取和过滤（使用正则表达式？）最多10MB的数据，那么为什么需要关系数据库呢？

只需识别文件并通过grep管道即可完成，对吧？这非常有效。

具有适当索引（关于日期，名称）的关系数据库只会使第二步更有效，即使这样，数据集也相当小 - 每个10MB文件中有几千行？

我知道这听起来像是通过将所有内容保存在文本文件中来解决问题的一种非常粗略的方法，但请保持简单。您必须管理数据的解析，验证和加载到数据库中，然后以数据库形式管理数据的额外存储等。

您尚未提供有关执行此搜索所需频率的信息，您对所获得的数据或其他任何性能和操作要求的处理方式。

如果您需要每秒多次执行此特定操作，或者希望能够以更具创造性的方式灵活地处理数据，或者对数据进行任何类型的分析，这些数据目前位于单独的文件或任何数量的事物中那么关系数据库就会立即成为数据管理的最佳选择。

Answer 3

其他人已经提供了一些优点，让我先谈谈物理数据库结构......

如果可以的话，选择一个支持clustering ¹的DBMS，并制作一个PK为{Date, Name, No} ^{2 <的<（索引组织的）聚簇表/ SUP>。然后，您的SELECT可以通过简单的索引范围扫描来满足，并且根本不存在堆访问（表堆甚至不存在），因此您不必担心错误的clustering factor。实际表现应该非常出色，并且能够很好地扩展到比现在更多的数据。}

如果您的DBMS支持leading-edge index compression，请将其打开以消除此复合主要/群集索引的B树结构中重复值的存储（和缓存）成本。

¹例如Oracle，MS SQL Server，MySQL / InnoDB ......

²其中No区分同一Date上具有相同Name的多行。或者，只需使Date更精细（例如将其精确到一秒），将查询修改为：SELECT * FROM myDB WHERE Name='Mickey Mouse' AND Date >= '2005-07-03' AND Date < '2005-07-04')，并将PK字段的顺序反转为{Name, Date}，以满足修改后的查询。

Answer 4

我肯定会使用数据库，但选择正确的数据库需要更多信息，特别是有关数据格式的信息。以下是我的建议，以及有关我何时选择其中一个的详细信息：

<强>关系：

如果您的所有数据都适合相同的模式（具有所有相同的字段），那么关系将是有意义的。根据您的问题，您提到您只需要2个索引，date和name。

假设每个条目都有很多其他数据，那么SQL数据库就会很有意义（使用类似你的查询）。

优点：

您似乎已经知道它是如何运作的
非常类似于CSV服务方式
您可以使用SELECT / JOIN（如果您以后需要）

缺点：

为未使用的田地浪费空间
不能很好地扩展（如果你需要更多空间）
可能有点矫枉过正，因为这个问题并不是一种尴尬的关系

<强>的NoSQL：

如果您的数据不适合相同的架构（许多不同的键只有几个共享键），那么文档存储会更有意义。由于你的数据是一种关系，所以MongoDB会有很多意义。

我会为您的数据库使用以下JSON指南：

{
    "name": "MickyMouse",
    "date": ...,
    other fields...
}

我会将name和date设置为索引，就像在SQL示例中一样。 MongoDB速度很快，不会占用额外的密钥空间。

这种方法的好处：

缩放非常好（可以添加节点和分片）
使用起来非常简单

缺点：

可能无法提供您需要的功能

<强>结论：

两者都是很好的方法，但它实际上取决于数据的确切含义。一般来说，数据库非常擅长查询，而文件系统则不然，特别是当数据变大时。

我个人会去NoSQL路线，但我真的需要有关数据集和使用模式的更多信息。如果数据需要扩展，那么这可能是最佳选择。

我不是真正的专家，但我不喜欢那么多使用SQL。如果数据具有令人难以置信的关系，那么SQL很有意义，但看起来你所做的一切都适合一两个表。

快速查找100gb数据

4 个答案: