Here is how one can access the data blobs from the SQuaSH API.
Blobs are stored on S3. If you retrieve a specific job you see the references to the s3_uri in there.
Example, for job id 885:
https://squash-restful-api-demo.lsst.codes/job/885
Each metric measurement can have several data blobs associated to it.
To retrieve a particular data blob one has to specify in addition to the job id, the metric name and the name of the data blob, like this:
https://squash-restful-api-demo.lsst.codes/blob/885?metric=validate_drp.AM1&name=MatchedMultiVisitDataset
the data access is optimized in the sense that we access the exact bit of data we need for a specific drill down plot.
GET /blob/885?metric=validate_drp.AM1&name=MatchedMultiVisitDataset => generated 491737 bytes in 1118 msecs (HTTP/2.0 200) 2 headers in 75 bytes (1 switches on core 1)
|
|
Here is how one can access the data blobs from the SQuaSH API.
Blobs are stored on S3. If you retrieve a specific job you see the references to the s3_uri in there.
Example, for job id 885:
https://squash-restful-api-demo.lsst.codes/job/885
Each metric measurement can have several data blobs associated to it.
To retrieve a particular data blob one has to specify in addition to the job id, the metric name and the name of the data blob, like this:
https://squash-restful-api-demo.lsst.codes/blob/885?metric=validate_drp.AM1&name=MatchedMultiVisitDataset
the data access is optimized in the sense that we access the exact bit of data we need for a specific drill down plot.
GET /blob/885?metric=validate_drp.AM1&name=MatchedMultiVisitDataset => generated 491737 bytes in 1118 msecs (HTTP/2.0 200) 2 headers in 75 bytes (1 switches on core 1)