使用 SQL 還是 NoSQL？
我正在設計一個系統來檢查給定網站是否存在任何安全漏洞。該系統包括一個客戶端（firefox 外掛）和一個伺服器。伺服器進行所有掃描，而客戶端只是將該資訊中繼給使用者。如果一個網站是危險的，它就會被列入黑名單；否則列入白名單。
假設系統必須能夠同時處理數千個請求和對數據庫的更新。
雖然預計數據庫的結構非常簡單，但我仍在考慮使用 NoSQL，因為我的理解是它可以處理更多的查詢。這是真的？哪種數據庫技術更適合我的系統？
從您所描述的內容中判斷還為時過早-沒有足夠的詳細資訊。有人說（可能是正確的）NoSQL 系統可以快速更新——甚至比 RDBMS 技術更快。然而，這樣的速度是有代價的（沒有 SQL/糟糕的索引）——這是人們應該意識到的關於 NoSQL的一件事。
它確實有案例，但恕我直言，一個設計得體的 RDBMS 可以應付給他們的大部分（絕大多數）工作。事實上，NoSQL 的一些參考使用者（例如 Google）一直在迴避它的好處，而不是使用索引和 SQL。看看 Brian Aker 在這裡的演講——他是 MySQL AB 的首席架構師。
您還應該意識到，NoSQL 代表了一系列技術，其中一些可能適合您的案例，但普通的 RDBMS 也可能適合。您應該使用 RDBMS 和 NoSQL 系統執行一些測試（或聘請顧問）。另外，考慮一下你自己的專業領域——也許你認識的魔鬼比你不認識的更好？如果您對 RDBMS 解決方案感到滿意，也許這比 5% 的性能提升更重要？
這個問題有兩個部分：
數據應該永久保存在哪裡？
讓我們推遲這部分，直到我們回答第二個，這更重要：
客戶應該在哪裡查詢以檢查漏洞？
一個記憶體層。您的客戶不應該首先訪問底層數據儲存。這裡不需要原子事務，您的查詢可以處理幾秒鐘、幾分鐘甚至幾小時前的數據。
對於該記憶體層，您可以使用 Redis、Memcached、Elasticache 或您選擇的雲提供商提供的任何記憶體儲存。
您的應用應首先檢查記憶體，如果所需的列表不在記憶體中，請從數據庫中查詢它，然後將其與過期日期一起填充到記憶體中。這個邏輯應該內置到您的應用程序中，而不是數據持久層或記憶體層中。
現在，回到第一個問題：數據應該永久保存在哪裡？一旦您設計了應用程序以首先檢查記憶體層，您就會明白為什麼持久層對於決策而言並不那麼重要。將記憶體層擴展到數千（或數十萬）個並發連接很容易。
答案是：使用您已經熟悉的數據庫，並開始熟悉記憶體層。