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

Question

我正在编写一个脚本，该脚本从数据库日志文件中解析和绘制信息。一些示例日志行可能是：Tue Dec  2 03:21:09.543 [rsHealthPoll] DBClientCursor::init call() failedTue Dec  2 03:21:09.543 [rsHealthPoll] replset info example.com:27017 heartbeat failed, retryingThu Nov 20 00:05:13.189 [conn1264369] insert foobar.fs.chunks ninserted:1 keyUpdates:0 locks(micros) w:110298 110msThu 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 137msThu 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 186msThu 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（对于我们事先知道的那些），或者有某种映射表回到原始字符串（对于那些我们解决了。）或者有没有其他原因我更喜欢常量而不是某种映射结构？其次，不是将原始日志行存储为字符串，我们可能可以将偏移量存储回磁盘上的原始文件。问题您是否发现上述两个计划更改中的任何一个存在任何问题？这些是一个好的起点吗？对于优化我们如何存储日志行的内存消耗，您还有其他提示/建议吗？我知道对于位图，有像 Roaring Bitmaps ( http://roaringbitmap.org/ )这样的东西，它们是压缩的位图，您在压缩时仍然可以正常访问/修改。显然，此类事物的总称是简洁的数据结构。但是，除了枚举之外，是否有任何等效于咆哮位图的方法？或者任何其他巧妙的方式来紧凑地存储它？我还想到了布隆过滤器，也许使用它们来存储每个日志行是否在一个集合中（即日志级别警告、日志级别错误）——但是，它只能在这些集合中，所以我不知道那讲得通。另外，不确定如何处理误报。想法？

Answer 1

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

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

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

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

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

我倾向于将每个枚举类型定义为一个 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}.

操场

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