哪个数据库用于每年 1 亿行的 1 个表？

Question

我有一个包含 70 个问题的问卷，需要存储答案。

问题：每年有 1 亿条记录。

我有使用不同类型存储的经验，但从来没有处理过这些庞大的数字。现在我担心每一个错误的决定都可能导致巨大的负面影响。

信息有关数据：

• 我在想一张有70 列的表
• 列已经定义，一段时间后可能会稍微调整（+/- 10 列）
• 每列的数据类型是主要整数和字符串与大多2字符，最大值 10 个字符。
• 不需要嵌套（树）结构
• 不需要灵活的数据类型
• 不需要加入

数据定义（伪代码）

COLUMN           |   TYPE   | MAX. LENGTH
-----------------------------------------
id               | Integer  | 10  
questionnaire_id | Integer  | 10
answered_at      | Datetime | -
answered_by      | Integer  | 10
answer1          | Integer  | 2
answer2          | Integer  | 2
answer3          | Integer  | 2
answer4          | Integer  | 2
...
answer35         | String   | 2
answer36         | String   | 2
...
answer70         | String   | 2

优先事项：

• 存储大数据
• 在可接受的时间内运行标准聚合函数（avg、min、max、count、...）、过滤和排序

是否有任何最佳实践或清单可供遵循，以减少我的选择，从而减少错误的决定？

先感谢您！

编辑：规范化，受戴夫启发

# questionnaire
- id (PK, AI)

# questions
- id (PK, AI)
- questionnaire_id (FK)
- label

# submits
- id (PK, AI)
- questionnaire_id (FK)
- answered_by
- answered_at

# answers
- id (PK, AI)
- submit_id (FK)
- question_id (FK)
- value      // Integers only (strings are mapped: A => 1, B => 2)

Answer 1

使用该表，没有额外的键/索引，每行有 160 个字节，因此每年 100,000,000 行大约为每年 16GByte。如果您有适当的硬件/虚拟资源，任何体面的 DBMS（SQL Server、postgres、[YourFavouriteDBHere]、...）都应该能够应对这种情况，并且（假设索引正确）有效地查询它。键和其他索引占用的额外空间不应过多地膨胀空间需求，如果确实如此，则结构可能不是更普遍的最佳结构。

所以简单地存储数据不应该是一个担心。

一些数据库支持压缩、稀疏表和其他技术，如果空间是您的主要关注点，这将对这种结构有很大帮助，但在考虑它们之前，首先确保这实际上是您需要的结构。

正如其他人在评论中讨论的那样，您当前的结构可能不是您需要执行的分析的最佳结构，因此如果您需要帮助，则需要编辑您的问题以包含此类详细信息。所有数据库设计中的一个关键是考虑您想要的输出以及您的输入。

不幸的是，我目前不知道每个必需的选择查询。

您必须对希望针对数据运行的报告类型有所了解。不需要是您将要运行或什至接近的每个查询，但是针对某些预期报告进行优化远比盲目地挖掘数据要好得多，希望它可能对最终会出现的某事/任何事情是最佳的向上。

在可能的情况下，不要纯粹根据您的输入进行设计。

对输出没有任何想法，也许是的：只需将数据放入这样的表中，至少在日期上带有索引，因为这很可能是您想要过滤/分区/聚合数据的关键方式之一在报告中，当您知道需要执行什么分析时，通过 ETL 将数据转换为其他内容。但是，如果您对开始的输出有一个想法，您可能能够避免创建和维护两种结构（一种用于活动记录，一种用于报告）以及将数据从一种转换为另一种的过程。当然，这两种结构系统可能是最佳的，但是如果没有更多细节，我们根本无法告诉您一种方式或另一种方式。