我应该如何储存大量的流量数据以方便检索？

我需要存储大量有关通过我们的网关路由器（包含时间戳，用户ID，目的地或源IP，字节数等）发送的互联网数据包的数据集。我应该如何储存大量的流量数据以方便检索？

这个数据必须存储一段时间，至少几天。容易检索也应该是可能的。

这样做的好方法是什么？我已经有一些想法：

为每个用户和每天创建一个文件并将每个数据集附加到它。
- 优点：它可能非常快，并且在给定一致的文件布局的情况下数据很容易找到。
- 缺点：不容易看到例如所有用户的所有UDP流量。
使用数据库
- 优势：这是很容易找到与正确的SQL查询的具体数据。
- 缺点：我不确定是否有一个数据库引擎可以有效地处理可能有数亿个数据集的表。
也许可以将两种方法结合使用：对每个用户使用SQLite数据库文件。
- 优点：一个用户在他的文件上使用SQL查询将很容易获得信息。
- 缺点：获取整体信息仍然很困难。

但也许别人有一个非常好的主意？

非常感谢。

来源

2010-02-26 Christoph Wurm

我认为正确的答案真的取决于“数据集”的定义。正如你在你的问题中提到的，你正在为每条记录存储单独的信息集;时间戳，用户ID，目的IP，源IP，字节数等..

SQL Server是完全有能力，没有任何实际困难与数以亿计的记录交给该类型的数据存储的。当然，这种类型的日志记录需要一些好的硬件来处理，但它不应该太复杂。

在我看来，任何其他解决办法将会使报告很辛苦，从它的声音是一个重要的要求。

来源

2010-02-26 18:12:29

你说得对，用户必须能够检查他们造成的流量。不幸的是，我无法使用SQL Server，因为我们所有的服务器都运行Debian Linux。前段时间，我在我们的PostgreSQL数据库上写了一个查询来查找没有合同的用户。看起来很简单，找到一个表中的所有条目在另一个表中都没有匹配的条目，这两个表都有5000行以下。但是，生成的查询需要五秒钟才能执行。这就是为什么我担心数以亿计的数据集的查询。 – 2010-02-26 18:19:05

这听起来像是有人忘了索引你的Postgre数据库！像这样的一个简单的查询这样一个微小的数据集应该采取适当设计的数据库milleseconds。 – HLGEM 2010-02-26 19:13:18

首先，让The Data Warehouse Toolkit你做任何事情之前。

你正在做一个数据仓库的工作，你需要解决它像一个数据仓库的工作。你需要阅读正确的设计模式。

[注：数据仓库并不意味着疯狂大或昂贵或复杂。这意味着星型模式和智能的方式来处理，但从不更新大量的数据。]

SQL数据库慢，但慢有利于灵活的检索。
文件系统很快。更新是一件可怕的事情，但你没有更新，你只是在积累。

一个典型的DW方法是这样做的。

为您的数据定义“星型模式”。可衡量的事实和这些事实的属性（“维度”）。你的事实似乎是＃字节。其他一切（地址，时间戳，用户标识等）都是这个事实的一个维度。
在主维数据库中构建维数据。它相对较小（IP地址，用户，日期维度等）。每个维度都会包含您可能想知道的所有属性。这种增长，人们总是增加维度的属性。
创建一个“加载”进程，它将处理日志，解析维度（时间，地址，用户等）并将维度键与度量值（字节数）合并。这可能会更新维度以添加新用户或新地址。一般来说，您正在阅读事实行，进行查找并编写具有与其相关的所有正确FK的事实行。
将这些加载文件保存在磁盘上。这些文件不会更新。他们只是积累。使用简单的符号，如CSV，这样您可以轻松地批量加载它们。

当有人想分析时，建立它们的数据集市。

对于所选的IP地址或时间范围或其他，请获取所有相关事实，以及关联的主维度数据并批量加载数据集市。

您可以在此商城中执行所有需要的SQL查询。大多数查询将分为SELECT COUNT(*)和SELECT SUM(*)以及各种GROUP BY和HAVING和WHERE条款。

来源

2010-02-26 18:15:32

因此，您处于其中一种情况，其中有多写活动多于阅读，你希望你的写作不要阻止你，你希望你的阅读“相当快”，但不是关键。这是一个典型的商业智能用例。

您应该使用数据库并将数据存储为“非规范化”模式，以避免每条记录的复杂连接和多次插入。把你的表看作一个巨大的日志文件。在这种情况下，一些“新颖和奇特”的NoSQL数据库可能是你要找的东西：它们提供了轻松的ACID约束，在这里你不应该非常在意（在发生崩溃的情况下，你可以放松您的日志的最后一行），但它们在插入时表现更好，因为它们不必在每次交易时同步磁盘上的日记帐。

来源

2010-02-26 18:19:19 Zorglub

我应该如何储存大量的流量数据以方便检索？

回答

相关问题