1
我正在努力尋找如何聚集大量數據的正確方法。 考慮一個數據庫的平均檢測速度爲每秒大約200（500個峯值）新行，我們將在前三個月內達到1億行。預期至少保存10年的數據。表將是非常靜態的，沒有更新，沒有刪除，只是插入。 真的希望PostgreSQL服務器（具有適當的硬件和配置）能夠管理如此大量的數據以進行查詢嗎？或者它是個壞主意？通過PostgreSQL數據庫聚合大量（行數）的數據集
現在需求是每個客戶都能夠爲他的交易生成彙總報表（可能是幾十甚至幾億，具體取決於他的標準），包括最近添加的報表。
我可以考慮一些諸如視圖，物化視圖，直接查詢，預先計算使用觸發器到另一個表的特性方法。這些都有其影響，積極，消極。例如，我甚至無法想象刷新物化視圖。
有沒有人有這些任務的經驗？任何見解都是值得肯定的。即使基礎設施技巧，第三方工具，任何有用的。我現在最關心的是創建軟件解決方案，而不是硬件擴展。
乾杯。
以每秒200條記錄的速度，您將在10年內獲得630億行記錄。在10年的時間裏，你是否真的很關心交易級別粒度？至少您需要使用[分區]（http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html）分隔您的數據，但在單個分區中有630億行無法管理。這樣，你的分區大小將達到53.5萬行，雖然還是很多，但是比單個分區更容易管理。 – GarethD
接下來你想考慮一個OLAP環境。如果您可能需要報告相當高的規模級別，然後將數據存儲在較高級別，請將其與分區結合使用，例如，假設您的數據按時間順序插入，按月對數據進行分區，然後一旦分區完成（在下個月初），將上個月的摘要添加到倉庫。如果您需要第二次準確的報告，您可以將來自倉庫的查詢結合起來以獲取歷史數據，併爲最近的數據提供最新的分區。 – GarethD
我同意，分區是必須的。劃分到最近的和歷史的部分是我們得到的第一個想法。現在我們正在討論在我們的數據庫之上使用Solr並將所有描述的報告移動到Solr和簡單數據庫角色的可能性，以作爲爲Solr提供源數據的普通存儲。不幸的是，我們對Solr解決方案還沒有太多經驗。 – Kousalik