我應該使用哪個DB？

Question

我現在正在構建一個應該存儲和處理大量數據的應用程序。 所以現在我正在努力解決這個問題 - 我應該使用哪個DB。

我的要求是：

• 每秒處理多達~100,000個插入命令（有時來自不同線程的幾個）。 100,000是最高峰; 大多數情況下，金額將介於數百到數千之間。
• 存儲數百萬條記錄。
• 盡快查詢數據。
• 每個實體的部分數據屬性都會發生變化，這比非關系數據庫行為更適合非關系數據庫行為。 但是，可能屬性的總和並不大，因此它可以在關系數據庫中顯示為列（如果它以這種方式更快）。
• 很少會發生更新命令。

你建議我使用哪個DB？

謝謝！

更新：我使用的操作系統不是Windows。 我認為如果SQL Server是最推薦的數據庫，那么我可能會從您的響應切換，但事實並非如此。

關於預算 - 我將從最便宜的選項開始，我想一旦公司有更多的錢和更多的用戶，這將改變。

沒有人推薦過no-sql數據庫。 他們真的對這種要求不好嗎？

Answer 1

答案取決於提出其他問題，例如您想花多少錢，您正在使用什么操作系統以及您在內部擁有哪些專業知識。

我所知道的可以處理如此大規模的數據庫包括：DB2，Oracle，Teradata和SQL Server。 MySQL也可能是一個選項，但我不確定它的性能。

我敢肯定，還有其他一些設計用於處理您建議的大規模數據，您可能還需要查看這些數據。

因此，如果您的操作系統不是Windows，則可以排除SQL Server。

如果你的便宜，MySQL可能是你的選擇。

DB2和Oracle都是成熟的數據庫系統。 如果您的系統是大型機（IBM 370），我建議使用DB2，但對於基於Unix的系統可能是一種選擇。

我對Teradata了解不多，但我知道它是專為大量數據而設計的，因此可能更貼近您所尋找的內容。

可以在此處找到更完整的選擇列表： http ： //en.wikipedia.org/wiki/List_of_relational_database_management_systems

這里有一個體面的數據庫比較： http ： //en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

每秒100000+次插入是一個巨大的數字，無論你選擇什么，你都在尋找在硬件上花大錢來處理這個問題。

Answer 2

這不是關於選擇什么數據庫的問題，而是關於您的技能和經驗的問題。

如果您認為使用一台物理機器是可行的 - 那么您就錯了。 如果您知道應該使用多台機器 - 那么為什么要詢問DB？ 數據庫並不像您使用它那樣重要。

從一台服務器上的只寫DB開始，現在垂直擴展。 使用幾個只讀服務器並水平擴展（這里幾乎可以安全地選擇文檔數據庫）。 CQRS概念可以詢問您即將提出的問題。

Answer 3

“每秒處理多達~100,000個插入命令” - 這是高峰還是正常操作？ 如果正常運行，你的“存儲的數百萬條記錄”很可能是數十億......

對於這樣的問題，我認為進一步理解業務“問題”是有用的 - 因為這些都是非平凡的要求！ 問題在於這個問題是否證明了這種“蠻力”方法，或者是否有其他方法可以實現同樣的目標。

如果需要，那么您可以考慮是否存在聚合/轉換數據的方法（批量加載數據/將多個更新丟棄到同一記錄/加載到多個數據庫，然后將下游聚合為ETL的組合）它更容易管理這個卷。

Answer 4

我要擔心的第一件事是你的磁盤布局，你有一個混合工作負載（OLTP和OLAP），所以如果你的IO子系統可以'，為了實現這個吞吐量，你的磁盤大小和放置正確​​是非常重要的'處理負載然后無論你將使用什么數據庫都無關緊要

另外，也許那些100,000次插入每秒可以批量加載，在12小時內每秒100,000行等於72,000,000行所以你可能想存儲數十億行？

Answer 5

您可能無法每秒處理100k個單獨的插入操作，您肯定需要將它們批處理為更可管理的數字。

無論如何，單個線程無法執行那么多命令，所以我希望有100-1000個線程來執行這些插入。

根據您的應用程序，您可能還需要某種高可用性。 除非你做的事情像科學的應用程序。

我的建議是雇用一個對你有可靠答案的人 - 最好是之前做過的人 - 如果你不知道，你將無法開發應用程序。 聘請能夠回答這個問題的高級開發人員。 如果你願意，可以在面試中詢問他們。