使用 MySQL 作为键/值数据库的可扩展性答案

【问题标题】：Scalability of Using MySQL as a Key/Value Database使用 MySQL 作为键/值数据库的可扩展性
【发布时间】：2010-06-19 23:03:50
【问题描述】：

我很想知道使用 MySQL 作为键值数据库与 Redis/MongoDB/CouchDB 相比对性能的影响。我过去使用过 Redis 和 CouchDB，因此我非常熟悉它们的用例，并且知道在 NoSQL 和 MySQL 中存储键/值对会更好。

但情况是这样的：

我们的大部分应用程序已经拥有大量 MySQL 表
我们在 Heroku 上托管所有内容（只有 MongoDB 和 MySQL，每个应用程序基本上是 1-db-type）
我们不想在这种情况下使用多个不同的数据库。

所以基本上，我正在寻找有关在 MySQL 中拥有键/值表的可扩展性的一些信息。也许在三个不同的任意层：

每天 1000 次写入
每小时 1000 次写入
每秒 1000 次写入
每小时读取 1000 次
每秒读取 1000 次

一个实际的例子是构建类似MixPanel's Real-time Web Analytics Tracker 的东西，这需要根据流量经常写入。

Wordpress 和其他流行的软件一直在使用它：Post 具有“元”模型，它只是键/值，因此您可以向可以搜索的对象添加任意属性。

另一种选择是将可序列化的哈希存储在 blob 中，但这似乎更糟。

你的看法是什么？

【问题讨论】：

bret.appspot.com/entry/how-friendfeed-uses-mysql

标签： sql mysql performance nosql key-value-store

【解决方案1】：

毫无疑问，使用 NOSQL 解决方案会更快，因为它更简单。
NOSQL 和关系不是相互竞争，它们是不同的工具，可以解决不同的问题。
也就是说，对于每天或每小时 1000 次写入，MySQL 没有问题。
对于每秒 1000 次，您需要一些花哨的硬件才能到达那里。对于 NOSQL 解决方案，您可能仍需要一些分布式文件系统。

这还取决于您存储的内容。

【讨论】：

没有任何调整，我在我的 celeron 1.8ghz 上每秒向 innodb 插入 4000 次

【解决方案2】：

我会说您必须运行自己的基准测试，因为只有您知道以下重要方面：

要存储在这个 KV 表中的数据的大小
您想要达到的并行度
到达您的 MySQL 实例的现有查询数

我还要说，根据对这些数据的持久性要求，您还需要测试多个引擎：InnoDB、MyISAM。

虽然我确实希望某些 NoSQL 解决方案更快，但根据您的限制，您可能会发现 MySQL 的性能足以满足您的要求。

【讨论】：

【解决方案3】：

SQL 数据库越来越多地用作持久层，计算和交付缓存在Key-Value 存储库中。

考虑到这一点，那些家伙在这里做了相当多的测试：

InnoDB 在其峰值*处每秒插入 43,000 条记录；
TokuDB 在其峰值*处每秒插入 34,000 条记录；
此 KV 每秒插入 1 亿条记录（超过 2000 倍）。

要回答您的问题，Key-Value 存储库很可能比 MySQL 高出几个数量级：

处理100,000,000项目：

kv_add()....time:....978.32 ms
kv_get().....time:....297.07 ms
kv_free()....time:........0.00 ms

好的，您的测试是每秒1,000 操作，但能够多做1,000 倍也无妨！

请参阅this 了解更多详情（他们还将其与Tokyo Cabinet 进行比较）。

【讨论】：

链接已失效，网络存档也没有它的副本。有其他选择吗？

【解决方案4】：

查看系列博客文章here，作者在其中运行测试比较 MongoDB 和 MySQL 性能，并解决 MySQL 性能调整的混乱局面。 MongoDB 每秒执行约 100K 行读取，c/s 模式下的 MySQL 最大执行 43K，但通过嵌入式库，他设法将其提高到每秒 172K 行读取。

在单个节点上获得这么高听起来有点复杂，所以 ymmv。

写/第二个问题有点难，但这仍然可能会给你一些关于配置的想法。

【讨论】：

【解决方案5】：

您应该首先以最简单的方式实现它，然后进行比较。总是测试东西。这意味着：

创建一个代表您的用例的架构。
创建代表您的用例的查询。
创建大量代表您的用例的虚拟数据。
在包括随机访问和顺序访问在内的各种循环中，对其进行基准测试。
确保您使用并发（运行许多进程随机地使用代表您的用例的各种查询冲击服务器）。

一旦你有了，测量，测试。你可以通过不同的方式来解决它。有些测试可能很简单，但可能不太现实。测量吞吐量和延迟。

然后尝试优化它。

MySQL 对 KV 有一个特殊限制，即具有持久性的标准引擎使用针对范围查找优化的索引，而不是针对 KV，这可能会引入一些开销，尽管由于持久性存储也很难使用诸如哈希之类的东西重新散列。内存表支持哈希索引。

许多人将某些事情与速度慢相关联，例如 SQL、RELATIONAL、JOINS、ACID 等。

当使用支持 ACID 的关系数据库时，您不必一定使用 ACID 或关系。

虽然联接因速度慢而臭名昭著，但这通常归咎于对联接的误解。人们通常只是简单地编写错误的查询。由于 SQL 是声明性的，因此这变得更加困难，它可能会出错，尤其是对于通常有多种执行连接方式的 JOIN。在这种情况下，人们实际上从 NoSQL 中得到了什么是势在必行的。 NoDeclaritive 会更准确，因为这是很多人遇到的 SQL 问题。很多时候人们只是缺乏索引。这不是支持加入的论据，而是说明人们在速度上可能会出错的地方。

如果您为此做一些特殊的事情，例如忽略数据完整性或在其他地方处理它，传统数据库可能会非常快。您不必等待硬盘驱动器刷新写入，您不必强制执行关系，您不必强制执行唯一约束，您不必使用事务，但是如果您确实用速度代替了安全性你需要知道你在做什么。

相比之下，NoSQL 解决方案首先倾向于支持各种开箱即用的扩展模式。单个节点的性能可能与您期望的不太一样。 NoSQL 解决方案也难以用于一般用途，其中许多具有非常不寻常的性能特征或有限的功能集。

【讨论】：