data-structures - 用于在 Go 中存储已解析日志行的紧凑数据结构(即 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)
• 日志级别(例如警告、错误、信息、调试等)
• 日志组件(例如存储、日志、命令、Indexin 等)
• 操作类型(例如查询、插入、删除等)
• 命名空间

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

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

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

计划的变更

首先，许多这些枚举都存储为字符串。所以我猜一个改进是使用类似 uint8 的东西来存储它，然后使用 consts(对于我们事先知道的那些)，或者有某种映射表回来到原始字符串(对于我们计算出的字符串。)或者是否有任何其他原因我更喜欢 const 而不是某种映射结构？

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

问题

1. 您是否发现上述两个计划更改中的任何一个有任何问题？这些是好的起点吗？
2. 对于优化我们存储日志行的内存消耗，您有任何其他提示/建议吗？
3. 我知道对于位图，有像 Roaring Bitmaps ( http://roaringbitmap.org/ ) 这样的东西，它们是压缩的位图，您在压缩时仍然可以正常访问/修改。显然，这样的事情的总称是简洁的数据结构。 但是，除了枚举之外，是否有任何与咆哮位图等效的东西？或任何其他巧妙的方式来紧凑地存储它？
4. 我还想到了布隆过滤器，也许使用它们来存储每个日志行是否在一个集合中(即日志记录级别警告、日志记录级别错误)——但是，它只能在其中一个集合中，所以我不不知道这是否有意义。另外，不确定如何处理误报。

想法？

Answer 1

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

两者都没有问题。如果日志肯定是行分隔的，您可以只存储行号，但存储字节偏移量可能更可靠。标准的 io.Reader 接口(interface)返回读取的字节数，因此您可以使用它来获得偏移量。

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

这取决于您要将它们用于什么目的，但是一旦它们被标记化(并且您已经从该行中获得了您想要的数据)，为什么还要在内存中保留该行？它已经在文件中，您现在有一个偏移量可以快速再次查找它。

除了枚举之外，是否有任何与咆哮位图等效的东西？或者任何其他巧妙的方式来紧凑地存储它？

我倾向于将每个枚举类型定义为一个 int，并使用 iota。像这样的东西:

package main

import (
    "fmt"
    "time"
)

type LogLevel int
type LogComponent int
type Operation int

const (
    Info LogLevel = iota
    Warning
    Debug
    Error
)

const (
    Storage LogComponent = iota
    Journal
    Commands
    Indexin
)

const (
    Query Operation = iota
    Insert
    Delete
)

type LogLine struct {
    DateTime      time.Time
    QueryDuration time.Duration
    ThreadName    string
    ConNum        uint
    Level         LogLevel
    Comp          LogComponent
    Op            Operation
    Namespace     string
}

func main() {
    l := &LogLine{
        time.Now(),
        10 * time.Second,
        "query1",
        1000,
        Info,
        Journal,
        Delete,
        "ns1",
    }
    fmt.Printf("%v\n", l)
}

生成 &{2009-11-10 23:00:00 +0000 UTC 10s query1 1000 0 1 2 ns1}。

Playground

您可以打包一些结构字段，但随后您需要为每个字段定义位范围，并且您失去了一些开放性。例如定义 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.

参见 here一个完整的，虽然有点老套的例子。