使用MySQL作为键/值数据库的可伸缩性

Question

我很想知道使用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具有“Meta”模型，它只是键/值，因此您可以向可以搜索的对象添加任意属性。

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

你有什么看法？

Answer 1

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

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

Answer 2

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

考虑到这一点，这些人在这里做了相当多的考验：

• InnoDB每秒插入43,000条记录AT ITS PEAK *;
• TokuDB每秒插入34,000条记录AT ITS PEAK *;
• 此KV每秒可插入1亿条记录（2,000多次）。

要回答您的问题，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进行比较）。

Answer 3

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

• 要存储在此KV表中的数据大小
• 您希望实现的并行度
• 到达MySQL实例的现有查询数

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

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

Answer 4

查看一系列博客文章here，其中作者运行比较MongoDB和MySQL性能的测试，并通过MySQL性能调优混乱。 MongoDB每秒执行大约100K行读取，而c / s模式下的MySQL最多可以执行43K，但是使用嵌入式库，他设法将其达到每秒172K行读取。

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

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

Answer 5

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

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

一旦有了，就进行测量，测试。您可以采取不同的方法。有些测试可能很简单，但可能不太现实。测量吞吐量和延迟。

然后尝试对其进行优化。

MySQL对KV有一个特别的限制，那就是具有针对范围查找而优化的持久性使用索引的标准引擎，而不是针对KV的标准引擎，这可能会带来一些开销，尽管由于诸如此类的原因，由于持久存储的原因而使散列工作难以实现重新整理。内存表支持哈希索引。

许多人将某些事物与缓慢的事物相关联，例如SQL，RELATIONAL，JOINS，ACID等。

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

尽管联接因其速度慢而声誉不佳，但这通常归因于对联接的误解。人们通常只写不好的查询。由于SQL是声明性的，因此这变得更加困难，它可能会出错，尤其是对于通常具有多种执行联接方式的JOIN。在这种情况下，人们实际上要摆脱NoSQL是必须的。 NoDeclaritive会更准确，因为这是很多人所面临的SQL问题。人们经常只是缺乏索引。这不是赞成加入的论据，而是要阐明人们在哪里可能会在速度上出错。

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

相比之下，

首先，NoSQL解决方案倾向于设计为支持各种开箱即用的扩展模式。单个节点的性能可能与您期望的不一样。 NoSQL解决方案也因许多具有非常不同寻常的性能特征或有限的功能集而难以通用。