5 ms·
Over the last 10 years, I've gradually moved from ASCII to Thrift/ProtocolBuffers to JSON. Here are some random thoughts: 1) As others said, you should definit
by lpolovets 15y ago
Over the last 10 years, I've gradually moved from ASCII to Thrift/ProtocolBuffers to JSON. Here are some random thoughts:
1) As others said, you should definitely use a library for JSON reading/writing.
2) JSON is simple and surprisingly fast to read/write. In one large benchmark (http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking http://code.google.com/p/thrift-protobuf-compare/wiki/Benchm...), the Jackson JSON library (for Java) comes in somewhere between Thrift and Protocol Buffers.
3) JSON feels friendlier than protocol buffers and Thrift because it's human readable instead of binary.
4) JSON is more convenient than multi-line formats like XML because you can grep for things easily. For example, if you have {time:015128752, event:"authentication error", user:"bob smith", details: "..."}, then I can take do the following:
cat log.json | grep 'user:"bob smith"'
It's hard to do that with XML because even if you find the right user, the entire log message/object spans multiple lines.
5) JSON is not as compact as binary, but it gets surprisingly close if you gzip it. All of those repeated descriptive attribute names are great for humans, but compression algorithms love them as well.
6) The format is fairly universal, but if you ever come across a language without JSON parsing libraries, the format is not so hard that you couldn't write your own parser (compare that to Thrift, XML, etc)
- LeafStorm 15y agoFun fact: `user:"bob smith"` is invalid JSON because object keys must always be quoted. The JSON spec is very precise, you can find it right on the front page of http://json.org/ http://json.org/.
- tim_sw 15y agoYou can also use tools like recordStream, which allow you to do grep, etc. on individual json fields. https://github.com/benbernard/RecordStream https://github.com/benbernard/RecordStream (It has a lot of other features as well) Sidenote: benbernard worked on Amazon dev tools team
- deno 15y ago> JSON is more convenient than multi-line formats like XML because you can grep for things easily. Only if the text representation is pretty-printed in a certain way. > It's hard to do that with XML because even if you find the right user, the entire log message/object spans multiple lines. XML tooling makes grepping obsolete. cat log.xml | xpath //log[@user="bob smith"]
- seanp2k2 15y ago+1 for XML. It gets lots of hate, but if you're doing integrations or API work, it's almost everywhere. Check out xmllint too, ESP the "shell" feature in it (basically a REPL for xpath and other useful XML spelunking.)
- matan_a 15y agoJust please consider that XPath needs to store the items in a tree structure first (XML needs to be parsed and loaded into memry) before it can be useful. Running that on a large log file would be an interesting performance experiment.
- deno 15y agoNonsense, XPath works very well with streamed content, and there are even implementations of XPath engines for FPGA and GPGPU, all of which have very strict memory limitations. DOM is completely optional, and you only need it for convenience or to observe the modifications, e.g. the way browsers make use of it. Just think how you would compile any XPath expression — it’s very similar to REGEX, only for structured data.
- empthought 15y agoI think you're overstating the capabilities and implementation of common XPath processors here, and silently implying the use of a subset or modified version of XPath as specified. Arbitrary XPath will likely require loading the entire document in the worst case, because it allows navigation to any portion of the tree.
- deno 15y agoNavigation to any portion of the tree does not imply any need to keep the entire document in memory at once. Worst case scenario XPath expression will not yield any results before traversing the entire tree. However any XPath 1.0 (and I imagine 2.0 is no different in that regard) can be compiled into a deterministic state machine (DFA), which only needs to keep tabs on how many elements it has seen and what conditions has been met. What XPath 1.0 specifically doesn’t allow are arbitrary sub-expressions in predicates. Those would be problematic in certain conditions. The only potential issue with performance is when running a large number of XPEs against a single stream. So there are various techniques to remedy that, including merging state machines for branching expression etc.
- sant0sk1 15y agoOT and pedantic, but common enough that I thought I'd point it out: there's no need to cat and pipe a file into grep, because grep takes a file name as an argument, eg - grep 'user:"bob smith"' log.json
- chrisbroadfoot 15y agoI often use cat and pipe to grep, it's nicer to have a left -> right flow.
- lindvall 15y agoEnds up that passing the file directly to grep will allow it to use tricks to make processing faster than reading from a pipe.
- ralph 15y agoI don't like it, but you can do <foo grep bar | ... if you really want L-to-R whilst avoiding the redundant cat and its overhead. That doesn't allow grep to do its speed-ups though, because it's still reading stdin, not a filename.
- squarecog 15y agoJSON is a good choice if you have very tight coupling between producers and consumers of your logs. Twitter (disclosure: I manage/was early engineer on the analytics infra team) used Json initially, and it quickly turned into a mess because JSON does not enforce schemas or type safety. There is no way for your consumers to find out what you are logging, other than to sample records. This makes evolving logging, deprecating fields, and doing sanity checking very complex (you basically have to build a separate metadata discovery system). Use Thrift or Avro. Avro is extra nice because not only does it have a schema, it keeps the schema together with the data; however, the support for it is not as mature/wide. It's improving fast, though. Thrift, and, I think, Avro, have JSON protocols if you really love JSON -- you get the human-readable debugging mode, the metadata, the type safety, and compact binary representation.. happiness ensues.
- calibraxis 15y agoExcellent point. People should read your coworker Nathan Marz's book _Big Data_, for a lucid discussion of schemas.
- CurtHagenlocher 15y agoJSON is no more inherently single-line than XML; both can be formatted to either single-line or multi-line and still be valid.