我需要存儲大量有關通過我們的網關路由器（包含時間戳，用戶ID，目的地或源IP，字節數等）發送的互聯網數據包的數據集。我應該如何儲存大量的流量數據以方便檢索？
這個數據必須存儲一段時間，至少幾天。容易檢索也應該是可能的。
這樣做的好方法是什麼？我已經有一些想法：
爲每個用戶和每天創建一個文件並將每個數據集附加到它。
使用數據庫
也許可以將兩種方法結合使用：對每個用戶使用SQLite數據庫文件。
但也許別人有一個非常好的主意？
非常感謝。
我認爲正確的答案真的取決於「數據集」的定義。正如你在你的問題中提到的，你正在爲每條記錄存儲單獨的信息集;時間戳，用戶ID，目的IP，源IP，字節數等..
SQL Server是完全有能力，沒有任何實際困難與數以億計的記錄交給該類型的數據存儲的。當然，這種類型的日誌記錄需要一些好的硬件來處理，但它不應該太複雜。
在我看來，任何其他解決辦法將會使報告很辛苦，從它的聲音是一個重要的要求。
首先，讓The Data Warehouse Toolkit你做任何事情之前。
你正在做一個數據倉庫的工作，你需要解決它像一個數據倉庫的工作。你需要閱讀正確的設計模式。
[注：數據倉庫並不意味着瘋狂大或昂貴或複雜。這意味着星型模式和智能的方式來處理，但從不更新大量的數據。]
SQL數據庫慢，但慢有利於靈活的檢索。
文件系統很快。更新是一件可怕的事情，但你沒有更新，你只是在積累。
一個典型的DW方法是這樣做的。
爲您的數據定義「星型模式」。可衡量的事實和這些事實的屬性（「維度」）。你的事實似乎是＃字節。其他一切（地址，時間戳，用戶標識等）都是這個事實的一個維度。
在主維數據庫中構建維數據。它相對較小（IP地址，用戶，日期維度等）。每個維度都會包含您可能想知道的所有屬性。這種增長，人們總是增加維度的屬性。
創建一個「加載」進程，它將處理日誌，解析維度（時間，地址，用戶等）並將維度鍵與度量值（字節數）合併。這可能會更新維度以添加新用戶或新地址。一般來說，您正在閱讀事實行，進行查找並編寫具有與其相關的所有正確FK的事實行。
將這些加載文件保存在磁盤上。這些文件不會更新。他們只是積累。使用簡單的符號，如CSV，這樣您可以輕鬆地批量加載它們。
當有人想分析時，建立它們的數據集市。
對於所選的IP地址或時間範圍或其他，請獲取所有相關事實，以及關聯的主維度數據並批量加載數據集市。
您可以在此商城中執行所有需要的SQL查詢。大多數查詢將分爲SELECT COUNT(*)和SELECT SUM(*)以及各種GROUP BY和HAVING和WHERE條款。
因此，您處於其中一種情況，其中有多寫活動多於閱讀，你希望你的寫作不要阻止你，你希望你的閱讀「相當快」，但不是關鍵。這是一個典型的商業智能用例。
您應該使用數據庫並將數據存儲爲「非規範化」模式，以避免每條記錄的複雜連接和多次插入。把你的表看作一個巨大的日誌文件。在這種情況下，一些「新穎和奇特」的NoSQL數據庫可能是你要找的東西：它們提供了輕鬆的ACID約束，在這裏你不應該非常在意（在發生崩潰的情況下，你可以放鬆您的日誌的最後一行），但它們在插入時表現更好，因爲它們不必在每次交易時同步磁盤上的日記帳。
你說得對，用戶必須能夠檢查他們造成的流量。 不幸的是，我無法使用SQL Server，因爲我們所有的服務器都運行Debian Linux。 前段時間，我在我們的PostgreSQL數據庫上寫了一個查詢來查找沒有合同的用戶。看起來很簡單，找到一個表中的所有條目在另一個表中都沒有匹配的條目，這兩個表都有5000行以下。但是，生成的查詢需要五秒鐘才能執行。 這就是爲什麼我擔心數以億計的數據集的查詢。 – 2010-02-26 18:19:05
這聽起來像是有人忘了索引你的Postgre數據庫！像這樣的一個簡單的查詢這樣一個微小的數據集應該採取適當設計的數據庫milleseconds。 – HLGEM 2010-02-26 19:13:18