3 ms·
Because it's horribly inefficient. It's using 49 bytes to encode 8 bytes worth of data. If your data set is a few hundred observations this likely doesn't mat
by keredson 10y ago
Because it's horribly inefficient. It's using 49 bytes to encode 8 bytes worth of data. If your data set is a few hundred observations this likely doesn't matter. But most users of timeseries data have millions or billions. (I come from a computational finance background.)
Even if they were wedded to JSON for some reason, they could have just used a list of observations, like:
[1458000000,63.422235],
That would have cut their data costs in half.
Or just use one of the many existing formats for transmitting time series data. It's not a new topic. https://github.com/mobileink/data.frame/wiki/What-is-a-Data-Frame%3F https://github.com/mobileink/data.frame/wiki/What-is-a-Data-...
- watty 10y agoThis is an API for very small datasets (daily time series data). The goal should be accessibility and readability over saving a few bytes. I'm not saying it's ideal, I just think the snark is unwarranted considering how common it is. I just checked InfluxDB and they follow a similar model (even more verbose). https://docs.influxdata.com/influxdb/v1.2/guides/querying_data/ https://docs.influxdata.com/influxdb/v1.2/guides/querying_da... Checked a few more and I believe they're the same - Microsoft IoT, Predix (GE), etc.
- keredson 10y agothat example you give does not follow a similar model. it defines the columns once (not repeated w/ every observation): "columns": [ "time", "value" ], and then the observations as a list of lists: "values": [ [ "2015-01-29T21:55:43.702900257Z", 2 ], [ "2015-01-29T21:55:43.702900257Z", 0.55 ], exactly as i suggested in the "even if they were wedded to JSON for some reason" section of my original explanation.