本用例的最佳數據庫和硬件選擇

-2

我將擁有一個具有uuids，年齡，性別，家庭收入和12個此類字段的用戶表數據庫。其中約有四千萬到五千萬。我需要根據年齡範圍，收入範圍等進行查詢，並獲取uuid的列表。如果連接，每行應該大約400個字符。乘以400字節乘以50Mil得到17 - 18 GB大約。它會增長，但會慢慢。本用例的最佳數據庫和硬件選擇

這將是最好的數據庫系統來保存這些數據，並執行快速查詢。 Mongo或MySQL？另外什麼樣的硬件應該最好保持。

而且，誰能告訴查詢時MySQL或Mongo的將採取基於經驗。我需要在此基礎上設計整個系統的其他一些組件的體系結構。

來源

2012-06-02 Aditya Singh

我會說蒙戈，似乎毫無意義的使用關係數據庫爲一個表 –

我不喜歡用這條線（陳詞濫調警報），但：「我有指數比做大」。此外，如果關閉主題，[堆棧溢出不是推薦引擎]（http://meta.stackexchange.com/a/128562/179419）。 – Ben

毫無意義的問題 –

我不會說40-50萬條記錄或17-18GB將被視爲「大」。任何關係數據庫都應該足夠。

任何現代服務器就足夠了。 Windows，Linux - 選擇你最瞭解的人。我會說64位是必需的。加上enough RAM，你就可以把整個事情放在記憶裏。

沒有人能告訴你查詢的時間，因爲它取決於太多的因素：硬件，架構，索引等做的最好的事情是一次自己看看。

我認爲你最大的問題是按範圍查詢。這聽起來不像交易數據庫，更像是數據挖掘倉庫。也許一個具有時間，地點，收入等維度的星型模式可能更適合你想要做的事情。

來源

2012-06-02 18:37:55 duffymo

沒有理由你應該存儲在一個表中的所有的這些信息，尤其是與多行。對於這麼大的項目，我強烈建議學習關係數據庫如何工作以及索引如何工作。你要實現這一點的方式，在你投入的任何數據庫或硬件上都會變慢。就像您將它設計爲關係數據庫一樣，您可以使用幾個單獨的表來存儲事物並使用外鍵訪問其他表，然後您將大大提高您的性能。

This is very dry，但必不可少。你應該真的試圖很好地理解它。

此外，你應該閱讀有關indexing。每個數據庫的做法都略有不同，因此如何實現它取決於您選擇的數據庫。

我的意思是你會大大提高你的表現。我已經看到並重新設計了耗時15-20分鐘的不完整查詢，並通過關係數據庫設計，索引和最佳查詢設計對它們進行了優化，並將其縮短到毫秒。

來源

2012-06-02 18:55:35 mawburn

數據從不同來源傳輸到數據庫的方式使得難以存儲在多個相關的表中。 –

本用例的最佳數據庫和硬件選擇

回答

相關問題