在 MySQL 数据库中存储整数数组答案

【问题标题】：Storing integer arrays in a MySQL database在 MySQL 数据库中存储整数数组
【发布时间】：2015-08-04 13:05:31
【问题描述】：

我有很多光谱要存储在数据库中。光谱基本上是一个整数数组，在我的例子中，可变长度通常为 512 或 1024。如何最好地存储这些光谱？除了光谱，我还想存储一些额外的数据，比如时间和标签，这将是我数据库中的简单字段。光谱不会经常被检索，如果我需要它们，我需要它们作为一个整体。

为了存储光谱，我可以想到 2 种可能的解决方案：

将它们存储为字符串，例如“1,7,9,3,...”
将光谱存储在单独的表中，每个值在单独的行中，包含诸如spectrum_id、索引和值等字段

关于使用哪一个有什么建议吗？当然也非常感谢其他解决方案！

【问题讨论】：

我猜存储的光谱可以很好地表示为 x 轴上的波长和功率、光子计数或 y 轴上类似的图表。您存储的每个光谱是否共享相同的 x 轴值？您是否需要存储和检索描述单个光谱的 x 轴的信息？您是否想通过诸如“查找在 550nm 处测量值 > 250 的光谱”之类的查询来查找内容？

标签： mysql arrays

【解决方案1】：

当人们从过程/OO 编程思维转变为数据库思维时，您的第一个解决方案是一个常见错误。这一切都与效率、要获取的记录数量最少等有关。数据库世界需要不同的范例来存储和检索数据。

我会这样做：制作 2 张桌子：

spectra
---------
spectra_id (primary key)
label
time

spectra_detail
---------
spectra_id
index
value

要检索它们：

SELECT     *
FROM       spectra s
INNER JOIN spectra_detail sd ON s.spectra_id = sd.spectra_id
WHERE      s.spectra_id = 42

【讨论】：

谢谢。您的解决方案基本上就是我对第二个选项的想法。虽然这个选项乍一看更复杂，但我同意这可能更有效。然而，我很惊讶地看到在 PHP 代码中使用 serialize 函数在将数组写入数据库之前将其转换为字符串的频率。
如果您不需要通过该数据进行查询，则序列化方法会更好。

【解决方案2】：

如果您有一个小数据集（数百 MB），则将 SQL DBMS 与任何替代方案一起使用都没有问题。

正如 Maciej 所提议的，序列化是对其他替代方案的改进，例如您可以将每个频谱扫描分组为单个元组（表格中的行），从而减少键和其他信息的开销。

对于序列化，您可以考虑使用线串或多点等对象，以便能够使用 SQL 函数更好地处理数据。这将需要一些扩展，但允许查询数据，如果您使用 WKB，您还可以在存储使用方面获得相关收益，而性能损失很小。

问题是频谱数据容易累积，存储使用可能成为序列化技巧无法轻易解决的问题。您应该在您的项目中仔细考虑这一点。

在处理类似问题时，我得出的结论是，使用任何 SQL DMBS（MySQL、SQL Server、Postgre 等）来管理大型数值矩阵数据（例如频谱扫描测量）都是一个坏主意。这有点像试图通过将图像逐像素存储到数据库中来创建图像库 CMS。

下表对我实验中的几种格式进行了比较。这可能有助于理解使用 SQL DBMS 存储数值数据矩阵的问题。

MySQL 表具有键 - Int(10) - 和值 - 十进制(4,1) 1 157 627 904 B 的表 TXT CSV 十进制(4,1)，相当于14bit 276 895 606 B BIN（原始）矩阵 1 字节 x 51200 列 x 773 行 + 元数据 40 038 580 B HDF5 矩阵 3 字节 x 51200 列 x 773 行 + 元数据 35 192 973 B TXT + Zip CSV 十进制 (4,1) + 标准 zip 压缩 34 175 971 B PNGRGBa 矩阵 4 字节 x 51200 列 x 773 行 33 997 095 B ZIP(BIN) 使用标准 zip 26 028 780 B 压缩的原始 BIN 文件 PNG 8bIndexed 矩阵 1 字节 x 51200 列 x 773 行 + 色标 25 947 324 B

使用 MySQL 的示例没有使用任何序列化。我没有尝试过，但人们可能期望通过使用 WKT 线串或类似功能将占用的存储空间减少到几乎一半。即便如此，使用的存储空间几乎是相应 CSV 的两倍，是具有相同数据的 PNG8b 大小的 20 多倍。

当您停下来想一想您在使用 SQL DBMS 时在键和搜索优化方面存储了多少额外数据时，这些数字是意料之中的。

作为结束语，我建议您考虑使用 PNG、TIFF、HDF5 或任何其他更适合构建前端来存储频谱数据（或任何其他大型矩阵）的数字格式，以及可能使用 SQL DBMS 来处理围绕此核心数据的维度，例如谁测量、何时测量、使用哪种设备、达到哪个目的等。简而言之，在数据库内部或外部有一个 BLOB 文件，因为它更适合您的系统架构。

或者，值得考虑使用围绕某些数字格式（例如 HDF5）的大数据解决方案。每个工具都到了尽头。

【讨论】：