我想要存储在数据库中的光谱很多。光谱基本上是一个整数数组,在我的例子中,可变长度通常为512或1024.如何最好地存储这些光谱?除了光谱,我想存储一些额外的数据,如时间和标签,这将是我的数据库中的简单字段。光谱不会经常检索,如果我需要它,我需要它们作为一个整体。
为了存储光谱,我可以想到两种可能的解决方案:
有关哪一个使用的建议?其他解决方案当然非常受欢迎!
答案 0 :(得分:2)
当人们从程序/ 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
答案 1 :(得分:0)
如果您的数据集很小(数百MB),则将SQL DBMS与任何其他选择一起使用都没有问题。
如Maciej所建议的那样,序列化是对其他选择的改进,例如,您可以将每个频谱扫描分组为一个元组(表中的行),从而减少键和其他信息的开销。
对于序列化,您可以考虑使用诸如线串或多点之类的对象,以便能够使用SQL函数更好地处理数据。这将需要一些扩展,但是将允许查询数据,并且如果您使用WKB,还可以在不影响性能的情况下在存储使用方面获得相关的收益。
问题在于频谱数据趋于累积,并且存储使用量可能会成为问题,无法通过序列化技巧轻松解决。您应该在项目中仔细考虑这一点。
研究类似的问题,得出的结论是,使用任何SQL DMBS(MySQL,SQL Server,Postgre等)来管理大型数值矩阵数据(例如频谱扫描测量)是一个坏主意。有点像试图通过将像素逐像素存储到数据库中来创建图像库CMS。
下表列出了实验中几种格式之间的比较。这可能有助于理解使用SQL DBMS存储数字数据矩阵的问题。
MySQL Table Table with key - Int(10) - and value - decimal(4,1) 1 157 627 904 B TXT CSV decimal(4,1), equivalent to 14bit 276 895 606 B BIN (original) Matrix 1 byte x 51200 columns x 773 rows + Metadata 40 038 580 B HDF5 Matrix 3 bytes x 51200 columns x 773 rows + Metadata 35 192 973 B TXT + Zip CSV decimal (4,1) + standard zip compression 34 175 971 B PNGRGBa Matrix 4 bytes x 51200 columns x 773 rows 33 997 095 B ZIP(BIN) Original BIN file compressed with standard zip 26 028 780 B PNG 8bIndexed Matrix 1 byte x 51200 columns x 773 rows + Color scale 25 947 324 B
使用MySQL的示例未使用任何序列化。我没有尝试过,但是可以期望通过使用WKT线串或类似功能将占用的存储空间减少一半。即使这样,所使用的存储空间也几乎是相应CSV的两倍,并且是具有相同数据的PNG8b大小的20倍以上。
当您停止考虑使用SQL DBMS时在键和搜索优化方面要存储多少额外数据时,这些数字是可以预期的。
对于结束语,我建议您考虑使用PNG,TIFF,HDF5或任何其他更适合于构建前端以存储光谱数据(或任何其他大矩阵)的数字格式,并且也许使用SQL DBMS来确定围绕此核心数据的维度,例如谁来度量,何时,使用哪种设备,要达到何种目的等等。简而言之,在数据库中包含BLOB的文件或外部文件,因为它更适合您系统架构。
或者,值得考虑在某些数字格式(例如HDF5)周围使用大数据解决方案。每个工具都结束了。