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的coupe）。目前该脚本是Python，以及字段，它还存储原始原始日志以及标记化版本 - 虽然产生的内存消耗实际上是原始日志文件大小的几倍。因此，记忆消耗是我想要改进的主要内容之一。

为了娱乐/学习，我想我可能会尝试在Go中重新执行此操作，并考虑是否可以使用更紧凑的数据结构。

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

计划更改

首先，许多这些枚举都存储为字符串。所以我猜测一个改进将转移到使用uint8之类的东西来存储它，然后使用consts（对于我们事先知道的那些），或者使用某种映射表回到原始字符串（对于我们制定的字符串。）或者是否有任何其他重要性我更喜欢consts而不是某种映射结构？

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

问题

您是否看到上述两项计划更改中的任何一项出现任何问题？这些是一个很好的起点吗？
您是否有任何其他提示/建议可以优化我们存储日志的内存消耗？
我知道对于位图，有像Roaring Bitmaps（http://roaringbitmap.org/）之类的东西，它们是压缩的位图，在压缩时你仍然可以正常访问/修改。显然，像这样的事情的总体术语是简洁的数据结构。但是，是否有任何等效的咆哮位图，但对于枚举？或者其他任何巧妙存储这种紧凑的方式？
我还想过布隆过滤器，也许可以使用那些来存储每个日志是否在一个集合中（即日志级别警告，日志级别错误） - 但是，它只能在其中一个集合中，所以我不＃ 39;不知道这是否有意义。此外，不知道如何处理误报。

思想？

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}。

Playground

你可以打包一些struct字段，但是你需要为每个字段定义位范围，你会失去一些开放性。例如，将LogLevel定义为前2位，将Component定义为接下来的2位等。

我还想到了布隆过滤器，并且可能使用那些来存储每个日志是否在一个集合中（即日志级别警告，日志级别错误） - 但是，它只能在其中一个套，所以我不知道这是否有意义。此外，不确定如何处理误报。

对于您当前的示例，布隆过滤器可能过度。对于每个枚举或其他一些主＆＃34;索引＆＃34;可能更容易有[] 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以获取完整的，虽然是黑客的例子。

用于在Go中存储已解析的日志行的紧凑数据结构（即Go中多个枚举的紧凑数据结构）

1 个答案: