9

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

但情况是这样的：

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

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

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

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

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

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

你怎么看？

4

5 回答 5

2

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

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

于 2010-06-19T23:33:28.760 回答
2

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

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

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

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

于 2010-06-20T11:19:10.883 回答
2

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

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

  • InnoDB 在其峰值时每秒插入 43,000 条记录*；
  • TokuDB 在其峰值时每秒插入 34,000 条记录*；
  • 这个 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几次也无妨！

有关详细信息，请参阅此内容（他们还将其与 进行比较Tokyo Cabinet）。

于 2011-02-05T19:37:10.803 回答
1

在这里查看作者运行测试比较 MongoDB 和 MySQL 性能的系列博客文章，并通过 MySQL 性能调整混乱进行斗争。MongoDB 每秒执行约 100K 行读取，c/s 模式下的 MySQL 最大执行 43K，但使用嵌入式库，他设法使其每秒读取高达 172K 行。

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

writes/second 问题有点难，但这仍然可能会给你一些关于配置的想法来尝试。

于 2012-08-28T17:59:05.860 回答
0

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

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

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

然后尝试优化它。

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

许多人将某些事情与缓慢联系起来，例如 SQL、RELATIONAL、JOINS、ACID 等。

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

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

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

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

于 2019-04-18T20:20:31.093 回答