嘿。我將要建立一個真正非常巨大的數據庫。分佈式數據庫解決方案？
我一直在使用標準的MySQL的大部分我的東西，但這個特殊的問題將得到高達TB的，我會希望能夠做到幾百個查詢的第二個。
所以從設計我的數據庫架構使得它不會突突和快速的硬盤速度，什麼是我最大的瓶頸，什麼樣的解決方案預留建議在此。
是否有意義散佈到多臺計算機的數據庫上我的內聯網，因此可以與CPU/RAM等比例如果是這樣的軟件有這個或數據庫解決方案呢？
感謝您的幫助！ 我搜索了與此相關的問題，但如果已經詢問過，則找不到任何內容。
數據庫可伸縮性是一個非常複雜的問題;整個過程中都會遇到很多問題。
首先，考慮最低的水果;你有單獨的表（或列）將包含大量的數據嗎？包含每個大於4MB的BLOB的列？這些可以從數據庫中提取並存儲在平面文件存儲系統中，並且僅從數據庫引用;就在那裏，這可能會將許多難以實施的解決方案降到可管理的水平。
如果沒有，你有沒有表的不同子組深感不同的使用模式？如果是這樣，那麼就有機會將您的數據庫分割成不同的功能數據庫，這些數據庫可以分割到不同的服務器上。這方面的一個很好的例子就是大多數讀取數據，比如web服務器，很少生成（認爲用戶特定的主頁數據），但頻繁讀取;該類型的數據可以分離到與用戶數據的其餘部分分離的數據庫中（或者，再次，帶有引用的flatfile）。
考慮你的數據庫的事務性要求;你能清楚地隔離你的交易界限，還是會有數據庫中存在深度混合的交易？如果你能夠隔離你的交易界限，那麼還有另一個潛在的有用邊界。
這只是觸及了一些參與這樣的事情的問題。值得考慮的一件事是，你是否真的需要一個實際上會很龐大的數據庫，或者你只是想將數據庫用作持久層。如果您僅將數據庫用作持久層，那麼您可能會重新考慮是否實際上需要數據庫的關係特性，或者是否可以在較簡單的持久層之上使用較小的關係覆蓋層。 （我這樣說是因爲解決方案的大量看起來他們可以逃脫過大的持久層薄薄的關係層，這是值得考慮的。）
好吧，首先，我需要你點here.我不不認爲MySQL會像你想要的那樣執行。我有一種不好的感覺，當我說你需要看看甲骨文的安裝時，你會說，「我們沒有現金。」但是，當我說得到最新/最好的SQL Server時，你會說，「我們沒有實現它的硬件。」恐怕TB級數據纔會粉碎你的MySQL安裝。
鑑於他在上面對我的回答的評論中作了澄清，我覺得你可能是對的;你對甲骨文的觀點是完全正確的。甲骨文非常適合作爲一個收銀機，一旦你和他們在一起，就沒有回頭路;那就是說，他們真的是城裏唯一的遊戲，當他們專注於可擴展性的類型時...... – 2010-11-05 19:25:21
正在構建新一代的NewSQL數據庫，以準確解決在多個服務器上分配資源的問題。數據庫（從頭開始構建爲MySQL替代品）是一個提供近線性規模的示例 - 當CPU /內存耗盡時，您可以簡單地添加節點。
數據庫可伸縮性是一個棘手的問題，您應該考慮可以爲您解決的解決方案。我相信MySQL可以作爲解決問題的基礎。
水平可伸縮性;能夠水平擴展數據庫的能力（又稱向外擴展）是解決非常大的表和數據庫問題的好技術。
給你一些關於手頭實際問題的更多信息，我們將從大量數據源中提取大量數據，並從每個條目中解析大量統計數據。每天數據庫將處理100,000個新條目，每條條目都有100個統計數據。每個條目的實際文件大小爲prob <1KB，並且一旦其解析不需要使用。我們將在每個不斷增長的數據集上實時運行大量不同的查詢，並最終爲其他人提供相同的平臺。 – 2010-11-05 18:38:36
@nextgenneo：是的，你在那裏有點問題。我仍然建議您儘可能地合理分區數據庫;是否有某種你不會穿越的時空視界，或者類似的？因爲如果你真的有一個龐大的，不可分區的關係數據集，你可能需要結束一個（非常昂貴的）商業解決方案。我不是甲骨文的粉絲（至少可以這麼說），但他們比任何人都更瞭解史詩級的擴展。 – 2010-11-05 19:22:57