mysql - 具有简单键访问的大型表的良好数据库

Question

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

1. 唯一的 key 。
2. 一个整数值，不是唯一的，但用于对查询进行排序。
3. 一个 VARCHAR(200)。

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

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

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

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

提前致谢。

-凯文

Answer 1

CouchDB、MongoDB 和 Riak 都将擅长相对快速地找到 key (帐户)。

您将遇到的问题(使用任何解决方案)都与“order by”和“account in”子句相关。

问题 #1:账户在

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

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

然后你就会遇到问题 #2...

问题 #2:排序依据

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

解决方案:

1. 有大量内存。如果 RAM 不能容纳整个索引，那么加载会很慢。
2. 尝试限制“在”项的数量。即使此子句中有 20 或 30 个项目也会使查询真的变慢。
3. 试试键值数据库？

我是 K/V 数据库的忠实拥护者，但您必须了解第 1 点。如果你没有很多 RAM 而你有很多数据，那么无论你使用什么数据库，系统都会运行缓慢。如果您希望在这些场景(大数据集中的小查找)中获得良好性能，那么 RAM/DB 大小比率非常重要。