用于绘制趋势随时间变化的数据结构

Question

给定包含时间戳和文本的连续到达项目的数据流（例如搜索引擎的查询日志），您将如何存储数据，以便随着时间的推移有效地检索总计以绘制每个项目的趋势线？

具有元组（如术语，日期，计数）的面向行的数据库可以工作，但不会使用大量不同的术语进行扩展。在此上下文中应考虑哪些替代数据结构（例如，面向列的存储）？快速插入是一项重要的要求。

Answer 1

你的断言是错误的，面向列的DBMS比面向行的DBMS更有效，这恰恰相反。在您的方案中，单行插入到面向列的DBMS中的性能将非常糟糕 - 它们不针对插入性能进行优化，而是针对只读查询。绝对不适用于单行插入。

'快'有多快？如果有足够的I / O（快速硬盘驱动器），那么每秒数百次写入绝对不是什么大问题。整体数据是否足够小以适应RAM？普通的RDBMS仍然是最安全的选择，但现在也有内存引擎可用，它们大大优于传统的基于磁盘的引擎

对于聚合和后续报告，您可以使用汇总表，也可以使用名为Materialized Views的常用内置功能。<​​/ p>

Answer 2

这可能不会立即有用（因为这些技术尚不可用），但这里有关于面向流的数据库的an interesting podcast。演讲者（Michael Stonebraker）当然试图出售他的产品，但它仍然值得倾听，特别是因为Stonebraker是RDBMS的创始人之一。他的主要观点似乎是传统的基于磁盘的架构对于他需要做的事情来说是一个数量级（或更多）太慢，而（冗余）内存中的解决方案是这里的方法。

此外，Hadoop应该非常适合批量处理大型日志文件。但我不认为这会给你实时数据。

Answer 3

由于OP（在评论中）说“数据量非常高，每秒可能有数百个条目。它高于磁盘写入速度”，这听起来好像数据是从一些数据聚合而来的。服务器。我的建议是将存储任务分配给各个服务器。

您使用的是哪些前端Web服务器？ Apache有一个用于记录到数据库的模块。或者使用日志循环并定期获取文件。

当您想要查看和分析数据时，使用Hadoop或者可能更好的猪聚合。除非你真的需要，否则不要试图把它变成一个巨大的数据。

猪：http://hadoop.apache.org/pig/

猪培训视频：http://www.cloudera.com/hadoop-training-pig-introduction

Answer 4

一些想法：

如果确实数据量超过了磁盘写入速度，那么您将不得不提高磁盘写入速度（例如：RAID，更快的磁盘，ram磁盘）或在多个服务器之间分配负载。如果可扩展性是您的主要关注点，那么分发是关键。不幸的是，我无法在这个问题上提供更多的智慧（拉里K有一些可能有帮助的链接）。

我可以在没有非常努力的情况下获得30英寸/秒的持续写入2.5英寸7200转驱动器，所以我怀疑你需要比“每秒数百”更多的搜索引擎查询来超过它。例如，大多数关系数据库在很多单行写入方面表现不佳。以下是一些替代方案：

1. 调查您的DBMS是否支持某种批处理或批量插入选项（SQL Server的BulkCopy类可显着提高插入性能）。将一些项目缓冲到一个批次中并在后台写入。

2. 从表中删除索引，外键。这些减慢插入。

3. 最大限度地减少需要编写的数据量。也许每天半小时有一张桌子，那么你就不需要保存时间戳（如果你的聚合只需要半小时的分辨率）。压缩搜索字符串（使用gzip甚至只是UTF8可能有帮助）。看看使用一些棘手的位混搭是否可以让您在更小的空间中存储更多数据。

4. 完全抛弃DBMS。独占打开文件并附加固定长度记录。每半小时旋转一次文件。然后获取一些其他进程（甚至其他服务器）来读取这些文件并根据需要对它们进行共享。由于类型检查，解析，事务等，所有DBMS都会因普通文件而失去一些性能。如果性能是您的首要任务，那么您将不得不做DBMS提供的所有功能。