我有一个关于数据库设计的基本问题。
我有很多文件需要阅读并将其插入数据库中。每个文件都有几千行，每行有大约30个字段（按这些类型：small int，int，big int，varchar，json）。当然我使用多线程和批量插入以提高插入速度（最后我有30-40万条记录）。
插入后我想进行一些复杂的分析，性能对我来说很重要。
现在我得到每个行字段，我准备插入所以我有3种方法：
1-一个大表：
在这种情况下，我可以创建一个包含30列的大表，并存储其中的所有文件字段。所以有一张大尺寸的桌子我想对它进行大量的分析。
2-相当大的表格（A）和一些小表格（B）s
在这种情况下，如果我们将它们与其他列分开，我可以创建一些包含具有相同记录的列的小表。所以这些小表只有几百或几千条记录而不是三千万条记录。所以在相当大的表（A）中，我发出了我把它们放在另一个表中的列，我使用外键代替它们。最后，我有一个表（A），其中包含20列和3千万条记录，以及一些表（B），每列有2-3列和100-50000条记录。因此，为了分析表A，我必须使用一些连接，例如在select和...
中3-只是一张相当大的表
在这种情况下，我可以创建一个相当大的表，如上表中的表A（有20列），而不是使用外键，我使用源列和目标列之间的映射（这就像外键，但有有点不同）。例如，我有3列c1，c2，c3，在案例2中，我将它们放在另一个表B中并使用外键访问它们，但现在我为每个独特的记录分配一个特定的数字，包括c1，c2，c3 at插入时间并在程序代码中存储记录与其指定值之间的关系。因此，该表与第2号案例中的表格A完全相同，但不需要在select中使用联接或...
虽然插入时间很重要，但我所拥有的分析时间对我来说更重要，所以我想知道您对哪种情况更好的看法，我也很高兴看到其他解决方案。
答案 0 :(得分：1)
从设计的角度来看，30到40万人的数字并不差。性能完全取决于您设计数据库的方式。
如果您使用的是SQL Server，则可以考虑将大表放在单独的数据库文件组中。我曾以类似的方式处理过一个案例，我们在一张桌子上创造了大约18亿条记录。
如果您不打算一次性查看整个数据，请进行分析。您可以考虑对数据进行垂直分区。您可以根据需要使用分区架构。一些示例可能是将数据拆分为年度分区，如果您的分析仅限于一年的数据（仅举例），这将有所帮助。
主要的是根据您的需要进行非规范化/规范化，当然还有非聚集/聚簇索引的数据。同样，这取决于您将使用哪种分析查询。
答案 1 :(得分：0)
单个线程一次可以INSERT一行，并在一两天内完成40M行。使用LOAD DATA，您可以在一小时或更短的时间内完成。
但正在加载真正的问题？对于分组，求和等，问题是关于SELECT。对于＆＃34; analytics＆＃34;，问题不是表格结构。拥有一个原始数据表，以及一个或多个＆＃34;汇总表＆＃34;为典型的查询选择真的很快。
在您提供有关数据的更多详细信息之前，我无法提供有关自定义解决方案的更多详细信息。
分区（垂直或水平）在MySQL中不太可能有用。 （再次，需要详细信息。）
规范化会缩小数据，从而加快处理速度。但是，听起来数据集太小，以至于它都适合RAM？ （我假设您的＃2是＆＃39;规范化＆＃39;？）
谨防过度规范化。