一张表9 GB的数据库是好的设计吗？

Question

我被要求为我们的应用程序考虑一个数据库。大约有7种不同的数据需要存储。一种是标识数据，其可以包含唯一的序列号、时间、位置。所有其他6个数据集(4个二进制原始数据，2个文本数据)必须由标识数据标识。其中3个记录的大小约为2MB，其他的只有几个KB。

要存储的最大记录数为1500。每行大约6 MB，因此最大总数据量大约为9 GB。

我在考虑只有一张桌子。但在我看来，它很丑陋，只有一个表，大约9 GB的数据。

你有这样的数据库吗？我们可以使用MySQL关系数据库管理系统。

Answer 1

我很难想象你的数据结构，但我会给出一个通用的经验法则：

只要表不能再规范化，那么这种大小的单个表本身就没有什么问题，除了性能问题。但是，如果数据是标准化的，并且您已经考虑了所有其他因素，我没有太多的建议。

但是，我会考虑是否真的有必要将二进制数据存储在数据库中。如果这些文件是图片文件、文档或可以存储在文件系统上的内容，我建议您将文件存储在文件系统上，并将路径存储在数据库中。(这是一个在这个网站上反复出现的话题，我同意大多数人的观点，即在不必要的时候存储BLOBS是一个坏主意。)

Answer 2

我认为MySQL将在这样的工作量下消亡:)，而关系数据库不适合于这样的任务。

所以你的描述看起来很像Google Big Table。你可以在YouTube上找到关于它的有趣演示文稿。

看看这类数据库Hadoop开源实现

Answer 3

我会稍微改变Daniel的解决方案:为简单的数据字段创建一个表，然后为每种类型的二进制对象创建单独的表。如下所示：

Records
=======
SerialNumber (PK)
Time
Location
Text1
Text2

Images
=======
SerialNumber (FK)
Image1
Image2

Files
=======
SerialNumber (FK)
File1
File2