REST, JSON, And DB2 - Some Initial Thoughts
MartinPacker 11000094DH Comments (2) Visits (5298)
I was fortunate enough to spend last week in IBM’s Silicon Valley Lab (SVL), both in formal sessions and talking to developers.
One topic - which isn’t really all that new - is DB2’s REST support, which is pretty comprehensive and good.
The basic idea with this support is you can call DB2 via a URI1, with a JSON payload, and get JSON back. It’s possible that only one acronym means anything to you in that past sentence. The one that really might need explaining is “JSON”.
REST stands for “Representational State Transfer”, another malformed acronym. So it goes.
There’s nothing mysterious about this: Parameter
The JSON representation is just
Anyway this isn’t really the point of this post, but it gives you some idea of what you can pass into DB2 via REST, using standard HTTP methods such as
I’m more interested in how it shows up in DB2, and particularly in the instrumentation.
So what follows are a couple of topics I discussed while in SVL. But first something I should mention. Otherwise the rest2 won’t make much sense.
REST Support Sits Atop DDF
It’s best to think of REST as a special kind of DDF work, with all the usual attributes. So it runs under an enclave in the DIST address space. And now we’re on familiar ground:
So let’s dive into the two topics.
When a service is invoked it is invoked by an externalised name. It’s a two-part name: Collection Name and Service Name. Unsurprising, but I want to confirm it to you, Collection Name maps onto Package Collection Name and Service Name maps onto Package Name.
These appear in the SMF 101 IFCID 239 Package Accounting record. So you can spot the use of specific services in Accounting Trace. And you can tell where the requests came from. Of course, you might want to identify “high CPU” services, and all that jazz.
Some time ago DB2 added support for 128-character Package Names which, of course, broke my code. At the time it might not have seemed all that significant but can you imagine being constrained to having 18-character REST Service Names? Of course the format of the IFCID 239 record was enhanced to handle this3. So you can see the long names.
JSON can get quite complex, with the example I gave above being about the simplest one you can get. More realistic JSON is a non-trivial tree structure. So parsing it might be non-trivial, or so I feared.
Unlike System XML, there is no “System JSON”. Furthermore JSON parsing isn’t necessarily zIIP-eligible, precisely because of that.
So, if parsing JSON could be complex, isn’t that going to be expensive?
So I spent a nice hour and a half talking “of cabbages and kings4 and REST and DDF” with my favourite DDF developer.
The important point is this: The JSON parsing happens entirely on the Enclave.5
Two things flow from this:
There is one element of REST work that is at the DIST address space’s dispatching priority: reading in the JSON. Imagine a video 64-Bit Encoded. In principle that’s perfectly valid in JSON. It could be gigabytes of payload and quite expensive to read in.
We discussed measuring this - to see if it’s an issue. The best way to do it is to subtract the Enclave CPU Time from the Total CPU Time - in the SMF 30 Interval record for the relevant DIST address spaces. Without REST I see this number as small - in all the customers I’ve ever looked at. But if it’s large it’s worth thinking about.
These Are Early Days
I’ve not seen any real data from a “REST into DB2” situation yet - and I’d love to. But I’m pretty sure some of the above will help me (and should help you) understand it and its effects. Certainly I have code that will do a decent job of analysing both SMF 30 and SMF 101 IFCID 239.
It’s early days for this technology - but already I like how DB2 supports REST. More when I get it.
And sorry folks for the, ahem, “brevity” but I was trapped on yet another long flight with only you for company…