對大型數據庫的替代

我有一個數據庫，其中有一個表在一個表中有數十億行，我有過去5年的數據。我試圖以各種可能的方式優化數據，但延遲並沒有減少。我知道有一些解決方案，比如使用水平分割和垂直分割。但我不確定任何開源實現和開發所需的開發時間。有沒有人有使用這種系統的經驗？對大型數據庫的替代

謝謝。

來源

2010-06-05 Boolean

您能否描述您擁有的數據類型（單行有多大）以及您希望用作密鑰的每列的數量。 – 2010-06-06 10:58:41

沒有用例，沒有人可以提出任何建議。當你的數據量級爲「Sagan-esque」時，用例就非常重要，因爲正如你可能發現的那樣，根本沒有任何「通用」技術可行。這些數字太大了。

所以，你需要清楚你想要用這些數據做什麼。如果答案是「一切」，那麼你的表現會變慢，因爲你無法優化「一切」。

編輯：

那麼，這是什麼？ 2或3？結果集有多大？你需要訪問所有5年還是上個月？你真的需要所有的細節，還是可以總結？你需要分類嗎？鑰匙夠了嗎？數據多久更新一次？數據更新後需要在線多久？數據需要什麼樣的服務級別？ 24x7x7？ 9-5x5？一天的舊數據可以嗎？誰在使用這些數據？互動用戶？批量報告？向外部實體出口？

來源

2010-06-05 00:13:48

我想基於表中的兩個三鍵來優化讀取性能。 – Boolean 2010-06-05 00:22:00

「薩根式」。我想我可能不得不使用那個。 – 2010-06-05 22:47:25

Postgress支持partioning表。如果沒有別的閱讀他們的文檔。回答Hartung的問題對於達成解決方案將有很大幫助。在平面文件

來源

2010-06-05 01:19:05 BillThor

數據倉庫閱讀起來......

捕獲數據。做不是加載數據庫。
設計一個合適的星型架構架構。
寫程序來做尺寸一致性;那些程序只會將維度更改加載到數據庫。
編寫程序，將選定的平面文件記錄加載到帶有維度副本的數據集市中。

做不負載原始數據的數據庫。永遠。

來源

2010-06-05 01:34:46

這是多少GB的數據？這讓我想起LinkIn的故事，以及如何快速計算社交網絡，他們不得不在內存中運行所有內容。根據SO播客的說法，StackOver本身運行在擁有大量內存的服務器上，並且在任何時候都擁有內存中的大部分數據庫。

也讓我想起谷歌的問題，它需要定製軟件和大量廉價機器一起工作。

來源

2010-06-05 01:44:14 MatthewMartin

對大型數據庫的替代

回答

相關問題