具有简单密钥访问的大型表的良好数据库答案

【问题标题】：Good database for large table with simple key access具有简单密钥访问的大型表的良好数据库
【发布时间】：2011-04-24 11:31:23
【问题描述】：

我有几个大型数据库，超过 1 亿条记录。它们包括以下内容：

我现在将它们放在 mysql isam 表中。我的想法是，嘿，我只需在数据上设置一个覆盖索引，它应该会以相当快的速度退出。查询的形式...

select valstr,account 
    from datatable 
    where account in (12349809, 987987223,...[etc]) 
    order by orderPriority;

在某些测试中这似乎没问题，但在我们较新的安装中，它非常慢。完全没有索引似乎更快，这似乎很奇怪。

无论如何，我在想，也许是一个不同的数据库？我们对系统的其他部分使用数据仓库数据库，但它不太适合文本中的任何内容。任何免费或相当便宜的数据库都是一种选择，只要它们具有相当有用的 API 访问权限。 SQL 可选。

提前致谢。

-凯文

【问题讨论】：

一个新的数据库似乎在下结论。你检查过数据库上的 I/O 吗？也许看看索引碎片？分区策略？在放弃当前使用的内容之前，有很多事情需要先检查。
还没有，至少不会太多。如果你认为这是一个好的策略，我会这样做。只是想得到一些反馈。由于这是只读数据，我在想，也许有一个数据库做得很好？我将编辑我的问题（如果可能的话，对问题不熟悉）。
我不知道如何编辑。好的，所以更详细。这是只读数据。我可以以任何我想要的方式索引它。我非常愿意尝试 mysql 调整。我也可以在应用程序内进行排序，如果这有很大帮助的话。查询的大小通常在 1,000 到 50,000 之间。由于这可能会跳过整个索引，因此我不知道将性能提高到合理状态的最佳计划是什么（显然，合理是相对的，但可以说比表扫描好得多。实际数字很快就会跟进）。
您总是按订单优先级排序吗？如果是这样，在该字段上添加聚集索引是有意义的。制作另一个索引来覆盖您选择的字段（valstr、account）并查看它对性能的影响。
WHERE ACCOUNT IN () 子句中有多少个帐号？如果 WHERE 子句中只有一个帐号，与拥有 10 个帐号相比，性能如何？

【解决方案1】：

CouchDB、MongoDB 和 Riak 都将擅长相对快速地找到密钥（帐户）。

您将遇到的问题（任何解决方案）都与“order by”和“account in”子句有关。

问题 1：帐户

1.2 亿条记录可能意味着千兆字节的数据。你可能有一个关于演出的索引。这是一个问题的原因是您的“in”子句可以轻松跨越整个索引。如果您搜索帐户“0000001”和“9999581”，您可能需要加载大量索引。

因此，为了找到记录，您的数据库首先必须加载潜在的内存。然后要实际加载数据，您必须再次返回磁盘。如果您在 in 子句中的“帐户”不是“靠近在一起”，那么您将多次返回以获取各种块。在某些时候，只进行表扫描然后加载索引和表可能会更快。

那么你就会遇到问题 #2...

问题 2：按顺序排序

如果您从“in”子句返回大量数据，那么 order by 只是另一层缓慢。使用“order by”，服务器无法向您传输数据。相反，它必须加载内存中的所有记录，然后对它们进行排序，然后流式传输它们。

解决方案：

我是 K/V 数据库的忠实拥护者，但您必须查看第 1 点。如果您没有大量 RAM 并且您有大量数据，那么无论您使用什么数据库，系统都会运行缓慢。如果您想在这些场景中获得良好的性能（大数据集中的小查找），那么 RAM / DB 大小比率非常重要。

【讨论】：

【解决方案2】：

CouchDB 将为您提供按键存储，您可以创建视图来进行查询/排序。第二种选择可能是 cassandra，但学习曲线相当长。

【讨论】：

【解决方案3】：

这是一个使用 innodb 引擎的 MySQL 数据库的合理大小示例，该引擎利用了大约 1000 个表上的聚集索引。 1.25 亿行，查询运行时间为 0.021 秒，这似乎相当合理。

其他有用的链接：

希望它被证明是有趣的。

【讨论】：