我有一些巨大的二进制驱动程序日志（每个大约2-5GB，在将它们转换为可读形式后大概是10倍左右），我需要编写一个工具来让我按顺序浏览，排序，搜索和过滤它们（以便找到并解决错误）。用于处理大量数据的库/数据结构
每个日志条目都有几个属性，如：时间戳，类型，消息，某些GUID。条目是同质的，没有关系，在“检查”之后不需要存储数据。
我真的不知道如何处理这么多的数据。将所有内容保存在内存中将是愚蠢的，同样也可以将数据保存在平面文件中。我想过使用像SQLite这样的小型DBMS，但我不确定它是否足够快，而且我不需要DMBS的许多功能 - 只有排序和搜索。如果可能的话，我会在这种情况下热切地为了速度而交换空间。
是否有任何库（或可能是数据结构），可以帮助我处理这些数据量？
“服务”RDBMSs如Postgre，MSSQL，MySQL是不存在的问题，该工具应该很容易在任何地方使用，没有任何麻烦。
编辑： 哦，有没有人知道SQLite的“：内存”模式是否对数据库的大小有任何限制，或者它只是填充虚拟内存，直到它完全填满？
结账STXXL - 超大型数据集的标准模板库。 “STXXL的核心是用于外部存储器（out-of-core）计算的C++标准模板库STL的实现，即STXXL实现的容器和算法可以处理大量只适合磁盘的数据虽然与STL的兼容性支持易用性和与现有应用程序的兼容性，但另一个设计优先级是高性能。“
此外，如果您可以将多台计算机专用于此任务，请检查Hadoop。特别是HBase，Hive和MapReduce。
这看起来很有趣;有关大数据操作时间的任何信息？ – kurczak 2010-08-17 08:21:50
STXXL在http://algo2.iti.kit.edu/dementiev/stxxl/report/node11.html有关于表现的一些信息。恐怕我不能告诉你更多。 – 2010-08-17 08:42:57
我认为在DBMS中存储这是合适的方法。排序和搜索是DB擅长执行的任务 - 使用这些数据，使用专为此目的设计的工具将是一个巨大的优势。
SQLite可以很好地工作，尽管非关系型数据存储可能会占用较少的空间。但是，如果您想搜索多个“条目”，则数据库绝对是您的选择。
从[SQLite的合适用途]（http://www.sqlite.org/whentouse.html）看来，处理大数据集似乎并不像SQLite的特长。 – quantumSoup 2010-08-09 18:32:51
@quantumSoup：SQLite的页面引用的数据库接近2 ** tebibytes ** - 方式，比这里的规范更多。当然，大型数据库可以通过企业级DBMS处理得更好，但是，SQLite应该能够处理多GB数据库。 – 2010-08-09 18:36:40
SQLite将整个数据库存储在一个文件中，因此您可能会遇到文件系统对最大文件大小的限制。 – quantumSoup 2010-08-09 18:42:53
如何使用某种内存映射I/O，如Java的MappedByteBuffer和滚动自己的工具？
要从套用在MBBs SO回答，
基本上，这种机制使用操作系统的虚拟内存分页系统“地图”文件和programmaticly它们作为字节的缓冲区。操作系统将管理将磁盘和内存的字节自动地以非常快速的方式移动到磁盘和内存中。
对于您为每个日志文件创建这样的文件来读取它们是有意义的。警惕的是，你应该在64位，因为这会给你的文件一个TB限制，而不是GB。
浏览，筛选和排序 在某些层次就显示文件，并使用类似的文件名或时间戳的指标排序，当你处理他们的MBB应该是用自己的代码简单。你的过滤标准是什么？
搜索 现在，如果你想通过它们搜索 - 在这之上运行的Lucene会给你一个很好的方法来索引文件。你也可以采用不同的方法 - 像其他人所说的那样使用hadoop和Map/Reduce将任务分配到多台机器上。
关于this网站的性能提示很棒。
日志解析器。我建议你看看msft日志解析器。这包含在iis资源工具包中，并提供了许多您正在寻找的内容。也许最有用的功能是在平面文件上执行SQL查询等功能。这甚至可以跨文件完成。
一个选项可能是Berkeley DB或某种类似的可嵌入数据库管理器。
我还没有使用过Berkely DB，但是从一个简单的例子来看，我猜它与几年前大量的ISAM数据库管理器相似 - 基本上是一个用于处理磁盘上的键 - >数据索引的库数据结构。唯一的警告 - 我看到了散列表的提及，所以它可能不会做ISAM的顺序部分，但我期望它 - 最新版本甚至有SQL支持。
您不一定需要将完整的二进制日志转换为可读格式。您可以执行初始索引构建扫描，将偏移量保存到原始文件中。一个有用的索引可能仅仅是从行号到字节范围，所以您可以快速显示特定的行范围 - 当然，只有当日志记录长度可变时。
如果是像Btrieve（我多年前使用了一段时间）之类的东西，它应该很容易。
您没有声明语言。所以只需提供一个模块，允许您以一种有效的方式对文件进行随机访问：http://perldoc.perl.org/Tie/File.html
“时间戳，类型，消息，某些GUID。条目是同类的，没有关系，不需要存储数据在“检查”之后。“
您是否考虑过将离散条目作为独立文件存储在目录中？
如果你只需要做简单的排序，然后从排序字段构造文件名，并将其他文件中的其他文件。如果您知道您想要哪些字段，选择会很快。
最重要的是，api内置于OS中。
..
很显然，如果你需要的东西比这更灵活，那么你将需要一个适当的数据库，但它可能会根据您的要求工作。
在某些情况下，它会超过6000万个文件，我想这对FS来说会有点压力。 （？） – kurczak 2010-08-24 06:26:27
你为什么要排除PgSQL和MySQL之类的东西？它不需要很多努力来设置它们。 – quantumSoup 2010-08-09 18:30:50