我们正在 Build 一个系统，需要从第一天开始提供大量小额请求 . 通过“加载”我的意思是每秒约5,000次查询 . 对于每个查询，我们需要从noSQL数据库中检索~20条记录 . 将有两个批次读取 - 首先是3-4个记录，然后是16-17之后立即读取（基于第一次读取的结果） . 那将是每秒读取约100,000个对象 .
到目前为止，我们一直在考虑使用DynamoDB，因为它很容易入手 .
存储不是我会担心的东西，因为对象会非常小 . 我担心的是读取成本 . DynamoDB每小时每小时成本为0.0113美元，最终一致（这对我们来说很好）每秒读取数 . 这是我们每小时11,3美元，前提是所有对象的大小都是1KB . 根据16小时/天的平均使用量，这将是每月5424美元 .
所以... $5424 per month .
我会考虑其他选择，但我担心维护问题，成本等 . 我之前从未使用过这样的设置，所以你的建议真的很有 Value .
对于这种读/写密集型应用程序，最具成本效益（但仍然无障碍）的解决方案是什么？
3 回答
从上面的描述中，我假设您每秒5000次查询完全是读取操作 . 这基本上就是我们所说的数据仓库用例 . 您的可用性要求是什么？它是否必须托管在AWS和朋友上，或者您是否可以购买自己的硬件以在内部运行？你的数据是什么样的？消耗这些数据的逻辑是什么样的？
您可能会感觉到这里确实没有足够的信息来明确回答这个问题，但我至少可以提供一些建议 .
首先，如果您的数据相对较小并且您的查询很简单，请节省一些麻烦，并确保适当地调整内存参数，因为开箱即用的配置旨在运行在非常微薄的硬件上 . 如果必须使用NoSQL选项，则根据数据的结构，Redis可能是一个不错的选择（它需要了解更多关于您运行的数据结构的信息 . ）
如果查询归结为
SELECT * FROM table WHERE primary_key = {CONSTANT}- 不要打扰使用NoSQL - 只需使用RDBMS并学习如何调整dang事物 . 如果您可以在自己的硬件上运行它，那么这是真的 . 如果连接计数很高，请使用读取从站来 balancer 负载 .Long-after-the-fact Edit (5/7/2013) ：我应该付出一些代价，你的I / O性能会很糟糕 . 您可以选择为配置的IOPS支付大笔资金，将一堆EBS卷配合在一起，或者在将WAL同步到S3或类似设备时依赖短暂的存储 . 所有这些选择都很昂贵且难以维护 . 所有这些选项都有不同程度的性能 .
我在最近的一个项目中发现了这个，所以我切换到了Rackspace . 那里的性能大大增加，但我注意到，当我真正需要快速I / O时，我为CPU和RAM资源付出了很多 . 现在我主持Digital Ocean . 所有的事情都令人难以置信地受到了I / O的束缚，所以我只是很好地哼着 .
故事的道德：简介，调整，重复 . 问自己什么是问题，并不断验证你的假设 .
Another long-after-the-fact-edit (11/23/2013) ：作为我在这里描述的一个示例，请查看以下文章，了解使用带有InnoDB memcached插件的MySQL 5.7实现1M QPS的示例：http://dimitrik.free.fr/blog/archives/11-01-2013_11-30-2013.html#2013-11-22
啊，那不是那么多，甚至SQL都可以解决这个问题 . 因此，您已经轻松地处于大多数现代数据库可以处理的范围内 . 但是他们只能用右边的方式处理这个：
索引
查询
服务器硬件
拆分大数据（你可能需要大量的碎片，每个碎片的数据相对较低，因此我所说的"might"）
现在这更像是高负荷情况 . 你必须以这种支离破碎的方式阅读这些内容吗？如果是这样（如我所说），您可能需要考虑在重复的分片上分散负载 .
Mongo对磁盘分配很有侵略性，所以即使是小对象，它仍然会预先分配很多空间，这是值得考虑的事情 .
哦亚马逊
:\的计费惊险刺激 .现在你遇到了这一切 . 您可以设置自己的群集，但最终可能会为服务器，人员，管理员和您自己的维护时间花费更多的金钱和时间（或更多） . 这就是为什么DynamoDB真的在这里闪耀的原因之一 . 对于那些希望承担服务器管理的负担和痛苦以及压力的大型设置（相信我，如果您的开发人员可能会从现在开始将服务器管理员的职位改名为公司，那真的很痛苦） .
考虑自己设置，你需要：
相当数量的EC实例（取决于数据和索引大小，但我会说接近30？）
服务器管理员（也许2，也许是自由职业者？）
这两者都可以让你每年减掉100英镑，如果符合你的需求和预算，我个人会打赌管理方法 . 当您的需求超出托管Amazon DB可以为您提供的需求时，请转移到您的基础架构 .
编辑
我应该修改成本效益是用很多黑洞完成的，例如：
我不确定您拥有的数据量
我不确定写作
这些都有助于我设置一个场景：
大量写（大约与你的阅读一样多）
海量数据（批量）
这是我按顺序推荐的内容 .
确定您的用例并选择正确的数据库 . 我们定期测试MySQL和MongoDb的各种工作负载（OLTP，分析等） . 在我们测试过的所有情况下，与MongoDb相比，MySQL的性能优于MongoDb并且更便宜（$ / TPS） . MongoDb还有其他优点，但这是另一个故事...因为我们在这里讨论性能 .
尝试将查询缓存在RAM中（通过配置足够的RAM） .
如果您在RAM上瓶颈，那么您可以尝试利用短暂SSD的SSD缓存解决方案 . 如果您的工作负载是缓存友好的，则可以您可以节省大量资金，因为短暂的SSD通常不会由 Cloud 提供商收取费用 .
尝试使用PIOPS / RAID或组合为您的应用程序创建足够的IOPS .