Multi-model data types

In OceanBase Database, semi-structured data types such as JSON, GIS, and XML are classified as multi-model data types.

Characteristics of multi-model data

• Standard composition: For example, RFC 8259 is a data interchange specification for JavaScript Object Notation (JSON), while Open Geospatial Consortium (OGC) provides a set of text markup language (WKT-CRS) to describe coordinate systems and inter-system conversions, and World Wide Web Consortium (W3C) defines Extensible Markup Language (XML).
• Direct access based on SQL: As semi-structured data, multi-model data uses basic internal data types that can be mapped to SQL types. Multi-model data adopts a cascading logical tree schema that organizes a series of basic SQL types into complex composite data types.
• Fixed computing functions: Multi-model data types adopt standardized formats, which not only define the data exchange formats but also contribute to the computing APIs.

Query and computing of multi-model data

Multi-model data features a flexible structure. OceanBase Database provides a wide range of functions to support the construction, query, and computing of multi-model data based on the standards of multi-model data.

• Data construction: For example, OceanBase Database provides aggregation functions that extract basic data from relational tables based on certain aggregation rules to construct JSON and XML objects.
• Data query: For example, for JSON and XML data, OceanBase Database allows you to access a subset of multi-model data objects or a specific basic SQL element based on paths.
• Data computing: For example, OceanBase Database allows you to use Geographic Information System (GIS) functions to compute the relationships between spatial objects.

Storage of multi-model data

As a type of composite data, multi-model data is generally at a variable length, and a multi-model data object can sometimes be quite large. For storage convenience, multi-model data generally inherits the storage characteristics of LOB data. Technically, the storage upper limit of LOB data also applies to multi-model data. However, as the computing and storage of a large multi-model data object is very inefficient, we recommend that you do not construct a large multi-model data object.

• CLOB or VARCHAR2 type: You can store multi-model data directly as the CLOB or VARCHAR2 type in the database based on the standard text format. The disadvantage of this method is that each query of multi-model data requires parsing. Therefore, we recommend that you do not use this method to store multi-model data.
• Native multi-model type: The format of the stored data is optimized for database parsing. Once multi-model data is stored in the database, it will not be parsed again in the next query, and the storage space is also optimized. We recommend that you use the native multi-model type for storage.

Multi-model data interchange

Multi-model data is interchanged between different systems based on the standard format specifications.