极高的QPS - DynamoDB vs MongoDB vs 其他NoSQL？

Question

我们正在构建一个系统，从一开始就需要处理大量的小请求。所谓“大量”，我指的是每秒约5,000个查询。对于每个查询，我们需要从NoSQL数据库中检索大约20条记录。将有两次批量读取——首先是3-4条记录，然后根据第一次读取的结果立即进行16-17次读取。这将导致每秒读取约100,000个对象。

到目前为止，我们正在考虑使用DynamoDB，因为它真的很容易入手。

存储不是我担心的事情，因为对象非常小。 我担心的是读取成本。 DynamoDB每小时每100次一致性（对我们来说没问题）读取的费用为0.0113美元。对于我们而言，这是每小时11.3美元，前提是所有对象都不超过1KB。根据平均每天16小时的使用，这将是每月5424美元。

所以……每月5424美元。

我会考虑其他选择，但我担心维护问题、成本等。我以前没有处理过这种设置，所以您的建议将非常有价值。

对于这种读/写密集型应用程序，最具成本效益（但仍然无麻烦）的解决方案是什么？

- sPaul

---

必须使用NoSQL吗？它是100%只读吗？我打赌你可以通过使用一些经过良好调整的Postgres设置和几个只读从库来完成这个任务。 - Ben Burns

最重要的是它必须是无模式的。否则，将会有大量的SQL连接、多对多表等。我们可以考虑简单地将记录存储在一个具有ID和DATA的表中，并将对象作为JSON字符串存储在DATA下面，但是...你真的认为这可能是一种更快、更经济的解决方案吗？而且我们会遇到其他问题，例如要更新每个记录，我们需要先读取它，然后修改完整的字符串，然后将其写回。而不是告诉数据库引擎使用新值更新记录X（原子增量更新对我们很友好）。 - sPaul

现在这个问题已经有一段时间了，我很想知道你最终做了什么。 - Ben Burns

我也开始有点好奇了，太强了。 - ChaseMoskal

嘿，大家好！当时我们选择了基于MySQL的解决方案，效果不错（@BenBurns - 你是对的），尽管我们从未达到过那么高的QPS值。但该系统现在已不存在——业务失败了 :) - sPaul

Answer 1

根据您上面的描述，我假设每秒5,000个查询完全是读操作。这本质上是我们所说的数据仓库用例。您的可用性要求是什么？是否必须在AWS和友情服务上托管，还是可以购买自己的硬件在内部运行？您的数据是什么样子的？消费这些数据的逻辑是什么样子的？

您可能会感到这里真的没有足够的信息来明确回答问题，但我至少可以提供一些建议。

首先，如果您的数据相对较小且查询很简单，请节省一些麻烦，并确保从RAM而不是磁盘查询。任何支持内存缓存/表空间的现代RDBMS都可以胜任。Postgres和MySQL都具有此功能。在Postgres的情况下，请确保已适当调整了内存参数，因为开箱即用配置旨在在相当低端的硬件上运行。如果您必须使用NoSQL选项，则根据数据结构，Redis可能是一个不错的选择（它也主要是内存中的）。但是，为了确定哪种NoSQL可能是最合适的选择，我们需要了解更多有关您正在查询的数据结构以及正在运行的查询的信息。

如果查询归结为`SELECT * FROM table WHERE primary_key = {CONSTANT}`-不要麻烦使用NoSQL-只需使用RDBMS并学习如何调整它。如果连接数很高，请使用读取从机来平衡负载。

长期而言的编辑（2013年5月7日）：

我应该在之前提到的东西：EC2是测量自我管理数据库节点性能的非常糟糕的地方。除非你花大钱，否则你的I/O表现将是可怕的。您的选择要么是支付大量IOPS，将一堆EBS卷RAID在一起，或依靠临时存储同时将WAL同步到S3或类似服务中。所有这些选项都很昂贵且难以维护。所有这些选项都具有不同程度的性能。

我最近在一个项目中发现这个问题，所以我转向了 Rackspace。那里的性能大大提高，但我注意到我为 CPU 和 RAM 资源支付了很多钱，而实际上我只需要快速的 I/O。现在我改用 Digital Ocean 托管。DO 的所有存储都是 SSD，虽然与其他服务相比，CPU 性能不是很好，但我非常受 I/O 限制，所以我根本不介意。将 Postgres 的random_page_cost 降至 2 后，我可以顺畅地运行。

故事的寓意：剖析、调整、重复。反复验证你的猜测，不断问自己假设的前提是否正确。

另一则过后编辑（11/23/2013）：作为我所描述的例子，请查看以下文章，其中介绍了使用 MySQL 5.7 与 InnoDB memcached 插件实现 100 万次每秒查询的示例：http://dimitrik.free.fr/blog/archives/11-01-2013_11-30-2013.html#2013-11-22

- Ben Burns

---

我认为NoSQL的整个意义就在于处理这种东西，不是吗？ - Chet

恐怕这比那要复杂一些。简单来说，如果您需要通用数据存储，应该使用SQL数据库。NoSQL通常只有在您知道只想以非常特定的方式查询数据，并且当您有一种非常特定类型的负载时才有意义，这种负载难以扩展传统的关系型数据库管理系统，并且某个特定的NoSQL解决方案非常适合。结果发现这不是一个很常见的情况，所以我倾向于在项目早期阶段不建议使用NoSQL。对于现代RDBMS来说，5K QPS并不是非常重的读取负载。 - Ben Burns

有趣。我有点困惑为什么我被引入了歧途。我一直在使用NoSQL来处理所有非关系型的事务... - Chet

我不会过于纠结于此。正确的解决方案几乎总是解决你今天面临的问题的方案。 - Ben Burns

Answer 2

“loads” 的意思是每秒约 5,000 次查询。哦，并不算太多，即使 SQL 也能处理。所以您已经轻松地在大多数现代数据库的限制范围内。但是，它们只有在具备正确的以下条件时才能处理此类负载：

- 索引 - 查询 - 服务器硬件 - 分裂大数据（您可能需要大量分片，每个分片相对较少的数据，这取决于具体情况，因此我说“可能”）

那将是每秒读取约 100,000 个对象。那就是更高负载场景了。您必须以这种分散的方式读取吗？如果是这样，那么（如我所说）您可能需要考虑在复制分片之间分摊负载。

存储不是我担心的问题，因为对象将非常小。Mongo 对磁盘分配很激进，因此即使是很小的对象，它仍然会预先分配很多空间，这是需要注意的事情。

所以...每月 $5424。哦，是亚马逊的计费惊喜。

我会考虑其他选项，但我担心维护问题、成本等等。我以前从未使用过这样的设置，所以您的建议将非常有价值。

现在你遇到了这一切的难题。您可以设置自己的集群，但是您可能会为服务器、人员、管理员以及您自己的维护时间支付那么多的钱和时间（或更多）。这就是 DynamoDB 在这里真正闪耀的原因之一。对于那些希望摆脱公司的服务器管理负担（相信我，这真的很痛苦，如果你是一个开发者，你可能会从现在开始将你的职位从开发者变成服务器管理员），并承受大规模负载和压力的企业。

考虑到要自己设置，您需要：

- 相当数量的 EC 实例（取决于数据和索引大小，但我会说接近 30 个？） - 一个服务器管理员（也许是 2 个，也许是自由职业者？）

这两个都可能花费您数百万英镑，如果符合您的需求和预算，我个人会赞成托管方法。当您的需求超出托管 Amazon DB 能够提供的范围时，请转移到您自己的基础架构。

我应该补充说明，成本效益性是基于以下一些漏洞：

- 我不确定您拥有的数据量 - 我不确定写入量

这两者都导致我提出以下场景：

- 大量写入（与您的阅读量大致相同） - 大量数据（很多）

- Sammaye

Answer 3

以下是我建议的步骤。

1. 确定您的用例并选择正确的数据库。我们定期测试MySQL和MongoDb以处理各种工作负载（OLTP、分析等）。在我们测试过的所有情况下，MySQL的性能优于MongoDb，并且比MongoDb便宜（每TPS美元）。MongoDb有其他优点，但那是另一回事...因为我们在这里谈论的是性能。

2. 尝试通过提供足够的RAM来将查询缓存到RAM中。

3. 如果RAM不足，则可以尝试使用SSD缓存解决方案，该解决方案利用短暂的SSD。如果您的工作负载适合缓存，则此方法有效。您可以节省大量资金，因为云提供商通常不会收取短暂的SSD费用。

4. 尝试PIOPS / RAID或组合以为应用程序创建足够的IOPS。

- mnagaraj