Go中用于存储解析日志行的紧凑数据结构

Question

我正在编写一个脚本，该脚本从数据库日志文件中解析和绘制信息。一些示例日志行可能是：

Tue Dec  2 03:21:09.543 [rsHealthPoll] DBClientCursor::init call() failed

Tue Dec  2 03:21:09.543 [rsHealthPoll] replset info example.com:27017 heartbeat failed, retrying

Thu Nov 20 00:05:13.189 [conn1264369] insert foobar.fs.chunks ninserted:1 keyUpdates:0 locks(micros) w:110298 110ms

Thu Nov 20 00:06:19.136 [conn1263135] update foobar.fs.chunks query: { files_id: ObjectId('54661657b23a225c1e4b00ac'), n: 0 } update: { $set: { data: BinData } } nscanned:1 nupdated:1 keyUpdates:0 locks(micros) w:675 137ms

Thu Nov 20 00:06:19.136 [conn1258266] update foobar.fs.chunks query: { files_id: ObjectId('54661657ae3a22741e0132df'), n: 0 } update: { $set: { data: BinData } } nscanned:1 nupdated:1 keyUpdates:0 locks(micros) w:687 186ms

Thu Nov 20 00:12:14.859 [conn1113639] getmore local.oplog.rs query: { ts: { $gte: Timestamp 1416453003000|74 } } cursorid:7965836327322142721 ntoreturn:0 keyUpdates:0 numYields: 15 locks(micros) r:351042 nreturned:3311 reslen:56307 188ms

并非每个日志行都包含所有字段，但我们解析出的一些字段包括：

• 约会时间

• 查询时长

• 线程名称

• 连接号（例如 1234、532434、53433）

• 日志级别（例如警告、错误、信息、调试等）

• 日志组件（例如存储、日志、命令、索引等）

• 操作类型（例如查询、插入、删除等）

• 命名空间

总日志文件通常相当大（几百 MB 到几 GB）。目前，该脚本是在 Python 中编写的，除了字段之外，它还存储原始原始日志行以及标记化版本——尽管由此产生的内存消耗实际上是原始日志文件大小的几倍。因此，内存消耗是我想要改进的主要事情之一。

为了好玩/学习，我想我可能会尝试在 Go 中重新做这个，看看我们是否可以使用更紧凑的数据结构。

许多字段是枚举（enums）——对于其中一些字段，值集是预先知道的（例如，日志级别、日志组件）。对于其他（例如线程名称、连接号、命名空间），我们将在运行时解析日志文件时计算出该集合。

计划变更

首先，这些枚举中的许多都存储为字符串。所以我猜一个改进将是使用类似 an 的东西uint8来存储它，然后使用 consts（对于我们事先知道的那些），或者有某种映射表回到原始字符串（对于那些我们解决了。）或者有没有其他原因我更喜欢常量而不是某种映射结构？

其次，不是将原始日志行存储为字符串，我们可能可以将偏移量存储回磁盘上的原始文件。

问题

1. 您是否发现上述两个计划更改中的任何一个存在任何问题？这些是一个好的起点吗？

2. 对于优化我们如何存储日志行的内存消耗，您还有其他提示/建议吗？

3. 我知道对于位图，有像 Roaring Bitmaps ( http://roaringbitmap.org/ )这样的东西，它们是压缩的位图，您在压缩时仍然可以正常访问/修改。显然，此类事物的总称是简洁的数据结构。但是，除了枚举之外，是否有任何等效于咆哮位图的方法？或者任何其他巧妙的方式来紧凑地存储它？

4. 我还想到了布隆过滤器，也许使用它们来存储每个日志行是否在一个集合中（即日志级别警告、日志级别错误）——但是，它只能在这些集合中，所以我不知道那讲得通。另外，不确定如何处理误报。

想法？

Answer 1

您是否发现上述两个计划更改中的任何一个存在任何问题？这些是一个好的起点吗？两者都没有问题。如果日志肯定是行分隔的，您可以只存储行号，但存储字节偏移量可能更健壮。标准io.Reader接口返回读取的字节数，因此您可以使用它来获得偏移量。对于优化我们如何存储日志行的内存消耗，您还有其他提示/建议吗？这取决于您想将它们用于什么目的，但是一旦它们被标记化（并且您已经从该行获得了您想要的数据），为什么要在内存中保留该行？它已经在文件中，您现在有一个偏移量可以快速再次查找它。除了枚举之外，是否有任何等效于咆哮的位图？或者任何其他巧妙的方式来紧凑地存储它？我倾向于将每个枚举类型定义为一个 int，并使用iota. 就像是：package mainimport (&nbsp; &nbsp; "fmt"&nbsp; &nbsp; "time")type LogLevel inttype LogComponent inttype Operation intconst (&nbsp; &nbsp; Info LogLevel = iota&nbsp; &nbsp; Warning&nbsp; &nbsp; Debug&nbsp; &nbsp; Error)const (&nbsp; &nbsp; Storage LogComponent = iota&nbsp; &nbsp; Journal&nbsp; &nbsp; Commands&nbsp; &nbsp; Indexin)const (&nbsp; &nbsp; Query Operation = iota&nbsp; &nbsp; Insert&nbsp; &nbsp; Delete)type LogLine struct {&nbsp; &nbsp; DateTime&nbsp; &nbsp; &nbsp; time.Time&nbsp; &nbsp; QueryDuration time.Duration&nbsp; &nbsp; ThreadName&nbsp; &nbsp; string&nbsp; &nbsp; ConNum&nbsp; &nbsp; &nbsp; &nbsp; uint&nbsp; &nbsp; Level&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LogLevel&nbsp; &nbsp; Comp&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; LogComponent&nbsp; &nbsp; Op&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Operation&nbsp; &nbsp; Namespace&nbsp; &nbsp; &nbsp;string}func main() {&nbsp; &nbsp; l := &LogLine{&nbsp; &nbsp; &nbsp; &nbsp; time.Now(),&nbsp; &nbsp; &nbsp; &nbsp; 10 * time.Second,&nbsp; &nbsp; &nbsp; &nbsp; "query1",&nbsp; &nbsp; &nbsp; &nbsp; 1000,&nbsp; &nbsp; &nbsp; &nbsp; Info,&nbsp; &nbsp; &nbsp; &nbsp; Journal,&nbsp; &nbsp; &nbsp; &nbsp; Delete,&nbsp; &nbsp; &nbsp; &nbsp; "ns1",&nbsp; &nbsp; }&nbsp; &nbsp; fmt.Printf("%v\n", l)}产生&{2009-11-10 23:00:00 +0000 UTC 10s query1 1000 0 1 2 ns1}.操场您可以打包一些结构体字段，但是您需要为每个字段定义位范围，并且您会失去一些开放性。例如，将 LogLevel 定义为前 2 位，将 Component 定义为下 2 位等。我还想到了布隆过滤器，也许使用它们来存储每个日志行是否在一个集合中（即日志级别警告、日志级别错误）——但是，它只能在这些集合中，所以我不知道那讲得通。另外，不确定如何处理误报。对于您当前的示例，布隆过滤器可能有点矫枉过正。为每个枚举或其他一些跟踪行号到（例如）日志级别关系的主“索引”设置一个 []int 可能更容易。正如您所说，每个日志行只能在一组中。事实上，根据枚举字段的数量，使用打包的枚举作为标识符可能更容易map[int][]int。Set := make(map[int][]int)Set[int(Delete) << 4 + int(Journal) << 2 + int(Debug)] = []int{7, 45, 900} // Line numbers in this set.见这里为一个完整的，虽然hackish的例子。