是否有可能拥有超过一百万列的 SQL 表？答案

【问题标题】：Is it possible to have an SQL table with over a million columns?是否有可能拥有超过一百万列的 SQL 表？
【发布时间】：2011-06-28 18:03:14
【问题描述】：

我正在为微阵列数据构建一个数据库。每个患者样本都有超过 1,000,000 个特征，我想将患者样本作为行存储在 SQL 表中，每个特征作为一列。

                 HuEX Microarray Data
+----+----------+----------+-----+------------------+
| ID | Feature1 | Feature2 | ... | Feature1,000,000 |
+----+----------+----------+-----+------------------+
| 1  |   2.3543 |  10.5454 | ... |          5.34333 |
| 2  |  13.4312 |   1.3432 | ... |         40.23422 |
+----+----------+----------+-----+------------------+

我知道大多数关系数据库系统对表中的列数都有限制。

+------------+-----------------+
|       DBMS | Max Table Col # | 
+------------+-----------------+
| SQL Server |  1,024 - 30,000 |
|      MySQL |    65,535 bytes |
| PostgreSQL |     250 - 1,600 |
|     Oracle |           1,000 | 
+------------+-----------------+

显然，这些限制对于我的任务来说太低了。是否有办法增加 SQL 数据库表可以拥有的列数，或者是否有其他 DBMS 可以处理如此大量的表列？

更新

请注意，所有列都将具有所有行的值。

【问题讨论】：

您是否真的收集了每个患者的一百万个数据点，或者更像是可能的 100 万个数据点中的几百个
Cassandra 就是你要找的东西
@Conrad，我正在研究人类表达微阵列，每个阵列（芯片）有超过一百万个探针组。这有点技术性，但基本上这意味着我们的样本有超过 100 万个特征都具有值（数字双精度）。
@Nixuz 如果不是稀疏数据（我原来是这么认为的！），也许只是将数据存储在适当的去规范化形式中，具体取决于准确的访问要求。例如。单个 blob、按块范围的 blob、XML（可以在某些 DB 中查询、fsvo 查询）、预提取的统计信息等。此外，由于这非常专业，RDBMS 可能不是是最好的存储它的方式——同样，取决于访问要求。
@Nixuz 我认为不一定会有简单的方法——我会先确定所需的访问/查询用例，然后看看如何以最少的数量实现它痛苦;-) 混合可能会将每个结果拆分为多个记录，例如 1000 个同质值以及段号。（每个 CPU 只生成一个 1000 条记录，而不是 1000000 条记录，并且应该是相对可查询的——也只包括段号。）

标签： sql limit database

【解决方案1】：

不要。

如果你能让它工作，它会非常缓慢和笨拙。

相反，您应该创建一个单独的表，其中包含 PatientID、Feature 和 Value 的列。
此表将为您建议的表中的每个单元格保留一行。

它还可以添加有关每个患者特征对的附加信息。

【讨论】：

我曾想过这样做，但这似乎是个坏主意。首先，它不是那么容易使用，其次，如果我想在我的一个数据集中查询所有患者的所有特征，我最终会得到 80,000,000 行。我的猜测是它会非常非常慢。你怎么看？
@Nixuz：这应该比你的模型更快更容易使用。
@Nixuz：但请检查您必须在在 80M+ 行表中运行查询之前添加哪些索引。

【解决方案2】：

您通常会拆分（规范化）表格：

Sample: ID, PatientID
Feature: ID, Name
SampleFeature: SampleID, FeatureID, value

SQL 数据库不能处理很多列，但它们可以处理很多行。

【讨论】：

【解决方案3】：

尝试重新安排你的桌子：

CREATE TABLE MicroarrayData (
    SampleID  INTEGER,
    FeatureID INTEGER,
    Value     REAL,
    PRIMARY KEY (SampleID, FeatureID)
);

【讨论】：

【解决方案4】：

这实际上是Entity-Attribute-Value Model (EAV) 的一个用例，实际上可能更适合在某些密集环境中的非 RDBMS/SQL 解决方案。（虽然关系数据库是主力……但最好使用一个，直到它被证明是不够的;-)

来自维基百科的文章：

实体-属性-值模型 (EAV) 是一种用于描述实体的数据模型，其中可用于描述实体的属性（属性、参数）的数量可能非常庞大，但实际适用于给定的数量实体比较适中。在数学上，这种模型被称为稀疏矩阵。

编码愉快。

【讨论】：

【解决方案5】：

好吧，使用新信息，即这是 密集数组 同质数值（双精度）值和查询很重要（也就是说，我将忽略去规范化到 blob/XML 和使用特殊UDF），我提出以下建议：

将每个结果拆分为多条记录，其中每条记录的格式为：

ID, SEGMENT, IDx ... // where x is [0, q]

q 的值是任意的，但出于性能/效率原因，应根据特定的数据库实现（例如，尝试适应 SQL Server 中的 8k 记录大小）进行选择。

然后将每个结果拆分为记录，以便SEGMENT 引用该段。也就是说，给定特征的“绝对索引”是n = SEGMENT * q + x，特征n 将在SEGMENT = n / q 的记录中找到。那么主键就是(ID, SEGMENT)。

因此查询仍然很容易——唯一的变化是与段之间的转换——唯一的额外要求是SEGMENT（此列也可能参与索引）。

（可以使用单独的表将特征映射到SEGMENT/x 或其他位置。这样它类似于 EAV 模型。）

因此，虽然在某些方面类似于完全规范化的形式，但它利用初始矩阵的压缩/同质/静态特征性质来显着减少记录数量 - 而 200 万条记录可以说是一张很小的表而 2000 万条记录只是一个“中型”表，2 亿条记录（200 个芯片 x 每个芯片 100 万个特征的结果，如果每个特征产生一个记录）开始变得令人生畏。虽然复杂度相同，但 q 为 200 会将记录数减少到仅 1000 万条。（就数据/结构比率而言，每个压缩记录也更加更有效率。）

编码愉快。

虽然以上是我的一个试探性“假设”建议，但我鼓励更多地探索这个问题——尤其是所需的确切数据访问模式。我不确定这是标准 RDBMS 的“典型”用法，而且 RDBMS 甚至可能不是解决此问题的好方法。

【讨论】：