2010-06-05 64 views
2

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

謝謝。

+0

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

回答

5

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

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

編輯:

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

+0

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

+0

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

1

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

3

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

  1. 捕獲數據。做不是加載數據庫。

  2. 設計一個合適的星型架構架構。

  3. 寫程序來做尺寸一致性;那些程序只會將維度更改加載到數據庫。

  4. 編寫程序,將選定的平面文件記錄加載到帶有維度副本的數據集市中。

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

0

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

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