DB2 for z/OS offers document storage support for both JSON and XML. It is not always apparent whether JSON or XML is most suitable for a particular application. This article provides guidelines for selecting XML or JSON, and provides illustrations for creating, querying, updating and managing JSON and XML in DB2 z/OS.
1 2 3 Lightweight not only saves time, but also saves battery juice on mobile device
Application developers are increasingly looking for solutions that allow nearly continuous integration of application changes…even to production Amazon.com allows 1000’s of their developers to check in product code changes daily… Developers resist solutions that require delays to sync up with DBA change windows
NoSQL JSON stores are appealing to these developers: JSON schema can be evolved rapidly without intervention by DBAs or data modelers. Objects like “shopping cart” in these applications really aren’t used outside the Web application, so there is no need to interlock closely with the rest of the enterprise data model. JSON offers a very simple and elegant model for persisting Java or JavaScript objects, without needing a heavy-weight persistence solution like OpenJPA or Hibernate. Performance and scalability is very good for JSON Store a single JSON document representing the object versus Store “n” rows in relational as a “normalized” object.
4 Strings: wrapped in double quotes. “\” is used for escapement and “/” can be escaped so JSON can be embedded in HTML , but JSON allows <\/, to produce the same result and not confuse HTML. Numeric: Integer, Real and Scientific point, like JavaScript numbers, Leading zero is not allowed. Nested Objects: Unordered set of (comma separated) name/value pairs, where a name can be any string, a value can be any JSON value, including arrays and objects. Objects can be nested to any depth, but in reality are kept relatively flat. Arrays: Ordered sequence of values, where a value can be any JSON value, including arrays and objects. Boolean True False Null 1 to 1 mapping between collection and DB2 table Table contains a BLOB column Each row contains single document (table name – collection name) Side column for primary ID field
User-defined Functions, scalar function to operate on fields inside the JSON document 3 ways to use JSON APIs. Customer can also use SQL APIs in DB2 11 for z/OS to do some simple manipulation of JSON. User can use both JSON APIs and SQL APIs to manipulate JSON data stored in DB2. There are special options that can be only enabled by JSON API, like “Fire and Forget” Under the covers – all Mongo DB APIs are converted to SQL and execute. For INSERT, JSON in text is converted into BSON before sending over to DB2. Different from XML index, we can create composite index on JSON data. The JSON index support rely on “index-on-expression” using JSON_VAL. All the limitation for IOE will apply to JSON index as well. DB2 provides more features on XML than JSON.
11 The JSON data is stored internally as INLINE BLOB of max length 16MB. The XML data is not stored inline in the base table. The max XML length is 2G.
12 To enable JSON in DB2 for z/OS, DB2 APARs, Accessories Suite, and Client side APIs. This diagram show how each piece fit into the whole picture. XML terms.
XML is helping firms really improve data exchange standards by making the data that's exchanged easier for application developers to consume and easier for application developers to maintain their applications when they are using XML data format. So this example happens to be financial application domain. It shows first on the top form using the old FIX protocol to send a message or to capture data about buying 1000 shares of IBM stock. And if you just look at that particular message that you are seeing up there, I think you will agree that not all aspects of this are not terribly intuitive. You would really have to know a little bit about the format to be able to go in and understand which things we are representing, what specific business elements that are trying to be captured in this data message. If you contrast that with the material that you see in the lower right hand corner, the XML version of the FIX protocol, it becomes much more easy for an application developer to be able to confirm that information and readily understand what the different data values are representing. It's also a much more extensible, a much easier to extend environment when we are using XML as oppose to this proprietary format but we are showing on top. And again, although this example that I'm covering here happens to be for securities trade and happens to focus on the financial industry, you can find comparable examples of proprietary data exchange format versus XML format in a variety of industries. And really you begin to see the same kind of pattern that the XML was simply easier to consume, easier to code against in a more flexible overall environment than many of the proprietary standards that has been out there in the market place. XML data is not stored “inline” with the base table. Some objects are created implicitly. Now this is the Multi-versioning format. The XML indicator column have a timestamp remembering the last update time. And the XML Table has two more columns, Start_TS (timestamp), and END_TS (timestamp) for the valid duration of the row. END_TS contains all FF's for the current rows. The NODEID index has two more columns: END_TS, and START TS.
XML value indexes are not changed. Lot of SQL and Utilities support for XML. Extract part of XML data using XMLQuery. Fitler documents using XMLEXISTS. XMLTABLE is used to transform XML data into a relational table format. XML publishing functions, and XQuery Constructor (not shown) can be used to construct XML document from relational data or XML data. XQuery – very powerful FLWOR Conditional expression : IF, THEN, ELSE Value and node comparsion Castable expresssion; fn:avg XQuery constructor XMLModify is really doing “sub-document” update – only update the records that need to be changed.
A purchase order in XML format: 2 items are purchased Corresponding JSON document. Major difference : 1. XML datatype; JSON is stored as INLINE BLOB 2. No schema validation for JSON 3. No composite index for XML When JSON API is used, the conversion from JSON to BSON is handled by API. For XML, parsing is handled by XMLSS. Similar searching function. The actual SQL for JSON search is using JSON_VAL. XMLModify is doing sub-document update.
JSON is for - something “small” (in term of the size of the data) -Quick : don’t need much processing power -Don’t need to conform to 3rd party schema XML is more suitable for exchanging data among multiple parties with schema well defined.
40 41
43 44 45