哪個數據存儲最適合我的場景

Question

我正在研究涉及數據庫中更新/選擇查詢的高執行的應用程序。

我有一張基本表（A），每天將有一個實體約500條記錄。對於系統中的每個用戶，根據用戶的一些偏好創建該實體的變體，並將它們存儲在另一個表（B）中。這是通過每天午夜運行的cron作業完成的。

因此，如果在表A中有10,000個用戶和500個記錄，那麼表B中將有5M記錄在那天。我始終在這些表格中保存數據一天，並在午夜將歷史數據存檔到HBase。此設置工作正常，迄今爲止我沒有任何性能問題。

最近業務需求發生了一些變化，現在基表A中的一些屬性（對於15-20條記錄）將每20秒更改一次，並基於此我必須重新計算所有這些變化記錄的一些值在表B中爲所有用戶。即使只有20個主記錄發生更改，我需要重新計算並更新20萬個用戶記錄，這需要20多秒，然後進行下一次更新，最終導致所有Select查詢排隊。我收到來自在線用戶的3個獲取請求/ 5秒鐘，這導致了6-9個選擇查詢。要通過API請求的響應，我一直使用的字段表B.

我可以買更多的處理能力和解決這一情況，但我感興趣的是有正確縮放系統，該系統甚至可以處理100萬用戶。

這裏有人可以提出一個更好的選擇嗎？ nosql +關係數據庫能幫助我嗎？是否有任何平臺/數據存儲可以讓我無需鎖定就可以頻繁更新數據，同時還能讓我靈活地在實體的各個字段上運行選擇查詢？

乾杯 罐子

Answer 1

我建議在內存數據庫管理系統，充分實現了MVCC，看着一個以消除阻塞問題。如果您的應用程序當前正在使用SQL，那麼沒有理由將其轉移到nosql。您所描述的性能需求當然可以通過內存中支持SQL的DBMS來滿足。

Answer 2

我的理解是，你每20秒就會更新200K條記錄。然後就像在10分鐘內你會更新幾乎所有的數據。在那種情況下，爲什麼要將這些狀態寫入數據庫（如果這種情況經常更新）。我對您的要求一無所知，但爲什麼不使用表A中的數據按需計算呢？