这个矩阵有5000万行和10万列。行大多是稀疏的，每一行只有<1k个非零值。在这种情况下，所有的列也是非常稀疏的。值都是32位整型。对这些数据最常见的操作是:
- 根据索引获取几行。
- 基于查询获取索引，如非常简单的组合
col_a>val_a AND col_b>val_b OR col_c>val_c ...，或更复杂的条件，如根据col_x + col_y + ...选择前10名，甚至更复杂，如col_x*x + col_y*y ...，我们不需要在单个查询中支持基于10多个不同列的条件。
我们的前端人员想让我把稀疏矩阵放到数据库中。我几乎不使用数据库。但是我知道postgresql(虽然我们不需要使用postgresql)不支持超过1.6k列，sql不支持超过1024列。所以我想知道这样做的最佳实践是什么?有什么特殊的数据库能容纳这么多的列吗?如果没有的话。我怎么能在正常的sql/postgresql数据库处理这个?
- 我应该将行分割到不同的表中(每个表1k列，100个表)吗?如果我们需要跨不同表的查询，比如
col_x + col_y ...的top N，效率会有多高? - 也许我可以存储每一行数组在一列?但是，我不能使用稀疏列，而是依赖于服务器端压缩。在这种情况下如何有效地查询top N呢?
我担心的是，我怀疑数据库索引可以帮助我们的查询，除了最简单的一个col_a > val_a AND ...。对于前N个查询，理论上，我们可以缓存每个组合的前100个数据，但考虑到可能的组合的数量，这是不可能的。
在我们的应用程序中，大多数时间矩阵都是只读的。用数据库来保存它有意义吗?
更新用wide data, wide columns搜索后。我看到Cassandra和HBase可以处理数百万列。但是它们不是sql，可能很难设置。Spark在理论上没有列限制，但它似乎只对长而薄的数据有效。所以可能有一些数据库套件是我特别需要的。
我的研究结论是没有数据库支持100K列。
解决这个问题的一种方法是有100个表，每个表有1K列，所有这些表都用一个公共键链接在一起。
话虽如此……如果你在StackOverflow之外做自己的研究，你可能会发现和我发现的相同的观点，并且坚持自己，这真的是一个愚蠢的想法。