我正在編寫一個腳本，該腳本從數(shù)據(jù)庫日志文件中解析和繪制信息。一些示例日志行可能是：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）日志級別（例如警告、錯誤、信息、調(diào)試等）日志組件（例如存儲、日志、命令、索引等）操作類型（例如查詢、插入、刪除等）命名空間總?cè)罩疚募ǔＯ喈?dāng)大（幾百 MB 到幾 GB）。目前，該腳本是在 Python 中編寫的，除了字段之外，它還存儲原始原始日志行以及標(biāo)記化版本——盡管由此產(chǎn)生的內(nèi)存消耗實際上是原始日志文件大小的幾倍。因此，內(nèi)存消耗是我想要改進的主要事情之一。為了好玩/學(xué)習(xí)，我想我可能會嘗試在 Go 中重新做這個，看看我們是否可以使用更緊湊的數(shù)據(jù)結(jié)構(gòu)。許多字段是枚舉（enums）——對于其中一些字段，值集是預(yù)先知道的（例如，日志級別、日志組件）。對于其他（例如線程名稱、連接號、命名空間），我們將在運行時解析日志文件時計算出該集合。計劃變更首先，這些枚舉中的許多都存儲為字符串。所以我猜一個改進將是使用類似 an 的東西uint8來存儲它，然后使用 consts（對于我們事先知道的那些），或者有某種映射表回到原始字符串（對于那些我們解決了。）或者有沒有其他原因我更喜歡常量而不是某種映射結(jié)構(gòu)？其次，不是將原始日志行存儲為字符串，我們可能可以將偏移量存儲回磁盤上的原始文件。問題您是否發(fā)現(xiàn)上述兩個計劃更改中的任何一個存在任何問題？這些是一個好的起點嗎？對于優(yōu)化我們?nèi)绾未鎯θ罩拘械膬?nèi)存消耗，您還有其他提示/建議嗎？我知道對于位圖，有像 Roaring Bitmaps ( http://roaringbitmap.org/ )這樣的東西，它們是壓縮的位圖，您在壓縮時仍然可以正常訪問/修改。顯然，此類事物的總稱是簡潔的數(shù)據(jù)結(jié)構(gòu)。但是，除了枚舉之外，是否有任何等效于咆哮位圖的方法？或者任何其他巧妙的方式來緊湊地存儲它？我還想到了布隆過濾器，也許使用它們來存儲每個日志行是否在一個集合中（即日志級別警告、日志級別錯誤）——但是，它只能在這些集合中，所以我不知道那講得通。另外，不確定如何處理誤報。想法？
1 回答
蕪湖不蕪
TA貢獻1796條經(jīng)驗 獲得超7個贊
您是否發(fā)現(xiàn)上述兩個計劃更改中的任何一個存在任何問題？這些是一個好的起點嗎？
兩者都沒有問題。如果日志肯定是行分隔的，您可以只存儲行號，但存儲字節(jié)偏移量可能更健壯。標(biāo)準(zhǔn)io.Reader接口返回讀取的字節(jié)數(shù)，因此您可以使用它來獲得偏移量。
對于優(yōu)化我們?nèi)绾未鎯θ罩拘械膬?nèi)存消耗，您還有其他提示/建議嗎？
這取決于您想將它們用于什么目的，但是一旦它們被標(biāo)記化（并且您已經(jīng)從該行獲得了您想要的數(shù)據(jù)），為什么要在內(nèi)存中保留該行？它已經(jīng)在文件中，您現(xiàn)在有一個偏移量可以快速再次查找它。
除了枚舉之外，是否有任何等效于咆哮的位圖？或者任何其他巧妙的方式來緊湊地存儲它？
我傾向于將每個枚舉類型定義為一個 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)
}
產(chǎn)生&{2009-11-10 23:00:00 +0000 UTC 10s query1 1000 0 1 2 ns1}.
操場
您可以打包一些結(jié)構(gòu)體字段，但是您需要為每個字段定義位范圍，并且您會失去一些開放性。例如，將 LogLevel 定義為前 2 位，將 Component 定義為下 2 位等。
我還想到了布隆過濾器，也許使用它們來存儲每個日志行是否在一個集合中（即日志級別警告、日志級別錯誤）——但是，它只能在這些集合中，所以我不知道那講得通。另外，不確定如何處理誤報。
對于您當(dāng)前的示例，布隆過濾器可能有點矯枉過正。為每個枚舉或其他一些跟蹤行號到（例如）日志級別關(guān)系的主“索引”設(shè)置一個 []int 可能更容易。正如您所說，每個日志行只能在一組中。事實上，根據(jù)枚舉字段的數(shù)量，使用打包的枚舉作為標(biāo)識符可能更容易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的例子。
- 1 回答
- 0 關(guān)注
- 237 瀏覽
添加回答
舉報
0/150
提交
取消