我计划将质谱仪的扫描结果存储在 MySQL 数据库中，并想知道存储和分析这些数据量是否远程可行。我知道性能因环境而异，但我正在寻找大致的数量级：查询需要 5 天还是 5 毫秒？
输入格式
每个输入文件都包含一次光谱仪运行；每次运行都由一组扫描组成，每次扫描都有一个有序的数据点数组。有一些元数据，但文件的大部分由 32 位或 64 位整数或浮点数数组组成。
主机系统
|----------------+--------------------------------| | 操作系统 | Windows 2008 64 位 | | MySQL 版本 | 5.5.24 (x86_64) | | 中央处理器 | 2x Xeon E5420（共 8 核）| | 内存 | 8GB | | SSD 文件系统 | 500 GiB | | 硬盘阵列 | 12钛B | |----------------+--------------------------------|
在服务器上运行的其他一些服务使用的处理器时间可以忽略不计。
文件统计
|------------------+--------------| | 文件数量 | ~16,000 | | 总尺寸 | 1.3钛B | | 最小尺寸 | 0 字节 | | 最大尺寸 | 12 GiB | | 意思| 800 MB | | 中位数 | 500 MB | | 总数据点 | 约2000亿 | |------------------+--------------|
数据点的总数是一个非常粗略的估计。
提议的模式
我正计划做“正确”的事情（即疯狂地规范化数据），所以会有一个runs表，一个spectra带有外键 to的表runs，以及一个datapoints带有 to 外键的表spectra。
2000 亿数据点问题
我将跨多个光谱进行分析，甚至可能进行多次运行，从而产生可能涉及数百万行的查询。假设我正确地索引了所有内容（这是另一个问题的主题）并且没有尝试在网络上洗牌数百个 MiB，那么 MySQL 是否可以远程处理这个问题？
附加信息
扫描数据将来自基于 XML 的
mzML格式的文件。这种格式的
<binaryDataArrayList>核心在于存储数据的元素。每次扫描都会产生 >= 2 个<binaryDataArray>元素，这些元素加在一起形成一个 2 维（或更多）形式的数组[[123.456, 234.567, ...], ...]。
这些数据是一次性写入的，因此无需担心更新性能和事务安全性。
我对数据库模式的天真计划是：
runs桌子
| 列名 | 类型 | |--------------+--------------| | 编号 | 主键 | | 开始时间 | 时间戳 | | 姓名 | VARCHAR | |--------------+--------------|
spectra桌子
| 列名 | 类型 | |----------------+--------------| | 编号 | 主键 | | 姓名 | VARCHAR | | 索引 | 情报 | | 频谱类型 | 情报 | | 代表 | 情报 | | 运行标识 | 外键 | |----------------+--------------|
datapoints桌子
| 列名 | 类型 | |--------------+--------------| | 编号 | 主键 | | 频谱ID | 外键 | | mz | 双 | | 数量 | 双 | | 索引 | 情报 | |--------------+--------------|
这合理吗？
所以，正如你可能已经推断的那样，我是程序员，而不是实验室的生物学家，所以我对科学的了解几乎不如实际的科学家。
这是我将要处理的数据类型的单光谱（扫描）图：
该软件的目标是找出峰值的位置和重要性。我们现在使用专有软件包来解决这个问题，但我们想编写自己的分析程序（用 R 语言），这样我们就知道在表格下面到底发生了什么。如您所见，绝大多数数据都是无趣的，但我们不想丢弃我们的算法遗漏的可能有用的数据。一旦我们有了一个满意的可能峰值列表，管道的其余部分将使用该峰值列表，而不是原始数据点列表。我想将原始数据点存储为一个大块就足够了，因此如果需要可以重新分析它们，但只保留峰值作为不同的数据库条目。在那种情况下，每个光谱只有几十个峰，所以疯狂的缩放东西不应该