极高的QPS - DynamoDB vs MongoDB与其他noSQL？

Question

我们正在建立一个系统，从第一天起就需要处理大量的小请求。所谓“加载”，是指每秒5,000个查询。对于每个查询，我们需要从noSQL数据库中检索~20条记录。将有两批读取- 3-4记录，然后16-17立即读取(根据第一次读取的结果)。这将是10万个对象的读取每秒。

到目前为止，我们还在考虑使用DynamoDB来实现这一点，因为它很容易开始。

存储不是我会担心的事情，因为物体会非常小。我担心的是阅读的成本。DynamoDB每100小时花费0.0113美元，最终保持一致(这对我们来说很好)每秒读取数据。这对我们来说是每小时11，3美元，前提是所有的对象都有1KB的大小。按16小时/天平均使用量计算，每月为5424美元。

所以..。每月5424美元。

我会考虑其他的选择，但我担心维护问题，费用等。我从来没有与这样的机构工作过，所以你的建议将是非常有价值的。

对于这种读写密集的应用程序，什么是最具成本效益(但仍然没有麻烦)的解决方案？

Answer 1

从上面的描述中，我假设每秒5,000个查询完全是读取操作。这就是我们所称的数据仓库用例。您的可用性要求是什么？它是否必须由AWS和朋友托管，或者您可以购买自己的硬件来进行内部运行？你的数据是什么样子的？消耗这些数据的逻辑是什么样子的？

你可能会觉得这里确实没有足够的信息来明确地回答这个问题，但我至少可以给出一些建议。

首先，如果您的数据相对较小，并且您的查询很简单，请省去一些麻烦，并确保您正在从RAM而不是磁盘中查询。任何支持内存缓存/表空间的现代RDBMS都能做到这一点。Postgres和MySQL都有这方面的特性。在Postgres的情况下，请确保您已经适当地调优了内存参数，因为开箱即用的配置设计为在相当简陋的硬件上运行。如果必须使用NoSQL选项，则取决于数据的结构，Redis可能是一个不错的选择(它主要是内存中的)。然而，为了说明哪种风格的NoSQL最适合，我们需要更多地了解您正在查询的数据的结构，以及您正在运行的查询。

如果查询归结为SELECT * FROM table WHERE primary_key = {CONSTANT} --不要麻烦地处理NoSQL --只需使用关系数据库管理系统，并学习如何调优这件事。如果您可以在自己的硬件上运行它，则这是双重事实。如果连接计数较高，则使用读从负载来平衡负载。

长期事实编辑(5/7/2013)：我之前应该提到的一点: EC2是衡量自管理数据库节点性能的一个非常糟糕的地方。除非你付了钱，否则你的I/O待遇会很糟糕。您的选择是，要么为提供的IOPS支付大笔费用，要么将一系列EBS卷进行RAID，或者依赖于短暂的存储，同时将WAL同步到S3或类似设备。所有这些选择都是昂贵和难以维护的。所有这些选项都有不同程度的性能。

我在最近的一个项目中发现了这个，所以我转到了Rackspace。性能在那里有了很大的提高，但我注意到我花了很多钱购买CPU和RAM资源，而实际上我只需要快速的I/O，现在我用Digital托管。所有DO的存储都是SSD。与其他产品相比，他们的CPU性能有点差，但我是难以置信的I/O绑定，所以我只是不在乎。在把Postgres‘s的random_page_cost降到2之后，我很好地哼着歌。

故事的寓意:简介，调子，重复。问问自己--如果问题不断地证明你的假设。

另一个经过事实的长时间编辑(11/23/2013)：作为我在这里描述的一个例子，请参阅下面的文章，了解如何在InnoDB memcached插件中使用MySQL 5.7来实现1M QPS：11-30-2013.html#2013-11-22

Answer 2

所谓“加载”，是指每秒5,000个查询。

啊，没那么多，就连SQL也能处理。因此，您已经很容易在大多数现代DB所能处理的范围内。但是，他们只能通过以下权限来处理这一问题：

• 索引
• 查询
• 服务器硬件
• 大数据的分割(您可能需要大量的数据碎片，每个碎片的数据相对较低，因此我说“可能”)

这将是10万个对象的读取每秒。

现在，这更像是一个高负载的场景。你一定要以这样零碎的方式读这些吗？如果是这样的话(就像我说的那样)，您可能需要研究如何在复制的碎片之间传播负载。

存储不是我会担心的事情，因为物体会非常小。

Mongo在磁盘分配方面非常吃力，所以即使是小对象，它也会预先分配大量的空间，这是需要考虑的事情。

所以..。每月5424美元。

哦，是的，亚马逊:\的计费刺激。

我会考虑其他的选择，但我担心维护问题，费用等。我从来没有与这样的机构工作过，所以你的建议将是非常有价值的。

现在你遇到了这一切的障碍。您可以设置您自己的集群，但是您最终可能会为服务器、人员、管理员和您自己的维护时间付出那么多的金钱和时间(或更多)。这就是为什么DynamoDB真的在这里发光的原因之一。对于那些想要承担服务器管理的负担、痛苦和压力的大型机构来说(相信我，这真的很痛苦，如果你的开发人员，你最好从现在起把你的职位改为服务器管理员)离开公司。

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

• 相当数量的EC实例(依赖于数据和索引大小，但我可以说接近30个？)
• 服务器管理员(可能是2，也许是自由职业者？)

这两种方法都可能使你每年节省100英镑，如果这符合你的需要和预算的话，我个人会把赌注押在管理的方法上。当您的需求超出了所管理的Amazon所能提供的范围时，那么就转移到您的基础设施上。

编辑

我应该修正一下，成本效益是用相当多的黑洞做的，例如：

• 我不确定你有多少数据
• 我对写作不太确定

这两方面都有助于我提出一种设想：

• 大量的写作(大约和你读的一样多)
• 大量数据(大量)

Answer 3

以下是我依次推荐的内容。

1. 标识用例并选择正确的数据库。我们定期测试各种工作负载(OLTP、Analytics等)的MySQL和MongoDb。在我们测试过的所有情况下，MySQL的性能都优于MongoDb，并且比MongoDb便宜($/TPS)。MongoDb还有其他的优势，但那是另一个故事.因为我们说的是表演。
2. 尝试在RAM中缓存查询(通过提供足够的RAM)。
3. 如果您是瓶颈在RAM上，那么您可以尝试一个SSD缓存解决方案，利用短暂的SSD。如果您的工作负载是对缓存友好的，这是可行的。您可以节省大量金钱，因为短暂的SSD通常不由云提供商收费。
4. 尝试PIOPS/RAID或组合为您的应用程序创建足够的IOPS。