No, it stores them with binary metadata, rather than ASCII metadata. "Plaintext" needs to be parsed, which is expensive. You don't really think binary RPC formats like protobuf are slower than JSON because it's "structured format" compared to "plaintext" I hope. Or SQL databases are slower than CSV files.
> And no, I don't want to use the structured features.
I don't see why you'd prefer having to figure out different time formats to parse from different software logs compared to a standard time format.
I'm searching for "service name" and I don't care if it comes from "service" or mentions "service". That's unstructured.
The rest of your comment doesn't even apply. Search is not parsing and not structured data transfer (which is what binary RPC formats are for), and unless you have a fulltext index, there is no faster way to do it than the usual algorithms, which work at 100+ MB/s. With log files, the text is right there ready to be searched. With journald, it needs to be assembled first, and it's pretty slow in practice.
No, it stores them with binary metadata, rather than ASCII metadata. "Plaintext" needs to be parsed, which is expensive. You don't really think binary RPC formats like protobuf are slower than JSON because it's "structured format" compared to "plaintext" I hope. Or SQL databases are slower than CSV files.
> And no, I don't want to use the structured features.
I don't see why you'd prefer having to figure out different time formats to parse from different software logs compared to a standard time format.