從上面的描述中，我假設(shè)您每秒5000次查詢完全是讀取操作 . 這基本上就是我們所說的數(shù)據(jù)倉庫用例 . 您的可用性要求是什么？它是否必須托管在AWS和朋友上，或者您是否可以購買自己的硬件以在內(nèi)部運(yùn)行？你的數(shù)據(jù)是什么樣的？消耗這些數(shù)據(jù)的邏輯是什么樣的？

您可能會感覺到這里確實(shí)沒有足夠的信息來明確回答這個問題，但我至少可以提供一些建議 .

首先，如果您的數(shù)據(jù)相對較小并且您的查詢很簡單，請節(jié)省一些麻煩，并確保適當(dāng)?shù)卣{(diào)整內(nèi)存參數(shù)，因?yàn)殚_箱即用的配置旨在運(yùn)行在非常微薄的硬件上 . 如果必須使用NoSQL選項(xiàng)，則根據(jù)數(shù)據(jù)的結(jié)構(gòu)，Redis可能是一個不錯的選擇(它需要了解更多關(guān)于您運(yùn)行的數(shù)據(jù)結(jié)構(gòu)的信息 . )

如果查詢歸結(jié)為 SELECT * FROM table WHERE primary_key = {CONSTANT} - 不要打擾使用NoSQL - 只需使用RDBMS并學(xué)習(xí)如何調(diào)整dang事物 . 如果您可以在自己的硬件上運(yùn)行它，那么這是真的 . 如果連接計數(shù)很高，請使用讀取從站來 balancer 負(fù)載 .

Long-after-the-fact Edit (5/7/2013) ：我應(yīng)該付出一些代價，你的I / O性能會很糟糕 . 您可以選擇為配置的IOPS支付大筆資金，將一堆EBS卷配合在一起，或者在將WAL同步到S3或類似設(shè)備時依賴短暫的存儲 . 所有這些選擇都很昂貴且難以維護(hù) . 所有這些選項(xiàng)都有不同程度的性能 .

我在最近的一個項(xiàng)目中發(fā)現(xiàn)了這個，所以我切換到了Rackspace . 那里的性能大大增加，但我注意到，當(dāng)我真正需要快速I / O時，我為CPU和RAM資源付出了很多 . 現(xiàn)在我主持Digital Ocean . 所有的事情都令人難以置信地受到了I / O的束縛，所以我只是很好地哼著 .

故事的道德：簡介，調(diào)整，重復(fù) . 問自己什么是問題，并不斷驗(yàn)證你的假設(shè) .

Another long-after-the-fact-edit (11/23/2013) ：作為我在這里描述的一個示例，請查看以下文章，了解使用帶有InnoDB memcached插件的MySQL 5.7實(shí)現(xiàn)1M QPS的示例：http://dimitrik.free.fr/blog/archives/11-01-2013_11-30-2013.html#2013-11-22

總結(jié)

以上是生活随笔為你收集整理的mysql mongodb qps_极高的QPS - DynamoDB与MongoDB相比其他noSQL？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。