Browse Prior Art Database

Method and System for Designing Database for High-Performance Melding of Document-Oriented and Relational Models

IP.com Disclosure Number: IPCOM000257038D
Publication Date: 2019-Jan-12
Document File: 5 page(s) / 64K

Publishing Venue

The IP.com Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Method and System for Designing Database for High-Performance Melding of Document-Oriented and Relational Models

Techniques for storing and accessing sets of key-value pairs in a document-oriented database often do not scale in relational model, and vice-versa. This leads to statements such as, you need to think of how you approach the application in a document oriented way. For relational databases, a schema is usually developed in advance of importing data, whereas in a document oriented database the schema is typically determined on the fly. A synergistic melding of the two major database models (document-oriented and relational) can set the stage for highly flexible and configurable systems where the schema becomes the norm, even for relational databases. Sharding, distributed caching, and streaming operations that already apply in both worlds may be even better leverageable than before in a combined model that handles sparse tabular data. Disclosed is a method and system for designing database for high-performance melding of document-oriented and relational models. The method and system enables both document-oriented and relational data to have properties that set forms of tabular data apart from random data. For document-oriented data, a skip list of keys is stored, where the skip list level for each key is chosen based on the number of values associated with each key and / or based on the frequency of access to those values. Likewise, relational data can be represented as key/value pairs and stored in the set of skip lists and multiple tables can be related by keys. In accordance with the method and system, for each key, a skip list of values can be stored. Each entry in the skip list of values includes links to an entry in a further skip list of unique row identifiers. Entries in the skip list of row identifiers can include links back to each of the values representing the row. The entire set of skip lists forms a sparse table in which every value is associated with both a key and a row. Additionally, range-limited queries (where) can be performed by finding a first skip list entry representing a range and walking bottom-level links to retrieve every entry in the range. A column in a table can contain keys that represent rows in other tables, each key can be represented by a pointer in a skip list entry representing a row or value in one table to a skip list entry representing a row or value in another table. Joins can be performed by following these links. The set of skip lists are stored, sharded, and /or distributed either as a list at time or as a partial list at a time. For storage to a sparse data store, e.g. HBase, a reader/writer routine pair can transfer the key/value data from an in-memory table in a format such as XML, JSON, or BSON. For each value stored this say, an offset to other elements in the XML / JSON / BSON stream, or an ordinal or other unique identifier reflecting those other elements, can represent the skip lis...

Processing...
Loading...