適用於高讀取率的db解決方案

Question

我將首先解釋用例。

高讀取率（10000+ p/s），大型數據集（大量字符串代碼（想想promocodes）尋找匹配，字符串10-20個）。需要快速的響應時間。

首先想到的是memcached。然而，爲了防止宕機，如果memcache關閉，並開始重新填充緩存從一個數據庫像mysql ...我想Redis的自動重新填充緩存。

確實redis沒有保留到硬盤，而是需要調用flush來備份它？

我的希望是使用代碼字符串作爲快速查找的關鍵。值將是一個鏈接到api不需要的db記錄的id。

如果我不得不猜測有多少獨特的字符串將在幾個月後被存儲...... 10M +。

Iv也簡單地看了一下Cassandra和mongodb。我認爲MongoDB會不夠，因爲它沒有將整個列表存儲在內存中？

對這些系統的任何瞭解都非常有幫助。感覺就像我在圈子裏一樣。

api是在nodejs中製作的。 （如果有問題）

Answer 1

根據您的模式明智地完成，10K/s對於像Cassandra這樣的數據庫來說絕對不是一個高速率。我敢打賭，其他人也一樣。 每月10M獨特的字符串是現代大數據系統的花生。

無論您保留什麼大數據解決方案，您都必須根據數據類型和運營需求來設計架構。

海事組織，重要的有以下2個問題：

你的意思是「尋找配襯」什麼？

如果您需要使用子字符串或正則表達式進行索引和搜索，您需要一個搜索引擎：ElasticSearch或SOLR非常棒。警告E/S執行復制和分片，但它的分發模式仍然不是100％安全。

您提到的任何系統都不會提供您似乎尋找的反應性。

如果您將使用靜態字符串進行查詢：像Cassandra這樣的鍵值存儲或列式數據庫將會是最合適的。所以一切都很合適。

什麼是快速響應時間？

隨着選擇正確的技術和適當的架構，所有這些系統都會在幾百毫秒內爲您提供極佳的響應時間，但是對於您來說足夠快嗎？

REDIS和MemCached在內存中將提供更快的響應。

作爲結論，API在節點中。js與你的存儲和索引技術的選擇無關，除非你想堅持使用Javascript的所有東西，MongoDB對你更友好，它可以是一個體面的候選人，這取決於你的搜索用例。