Column-Oriented Database Storage with Adaptive B-Tree

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current database systems, especially those using the LAMP stack or NoSQL models, face performance and programming complexities when scaling, particularly in storing data for networked gaming applications, due to the need for caching layers and variable access times, which are not as predictable as native data types like integers or arrays.

Innovation Solution

The implementation of a database system that uses a packed, column-oriented storage with a recursive adaptive array B-tree structure, allowing for direct integration of ACID properties into programming languages, eliminating the need for caching layers and providing O(log n) reads and writes with low constant overhead, by storing data compactly in a processor cache-friendly fashion.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If row-oriented storage is used, then data creation and modification are efficient, but read operations become slower

Engineering Contradiction:
Improvedata creation and modification efficiencyVSAvoidread speed
Core Design Contradiction:
ProductivityVSSpeed

Solution Approach 1:

The patent segments data storage into row storage and column storage components, allowing different storage orientations for different operations. Row storage handles write operations while column storage handles read operations, resolving the contradiction between write efficiency and read speed.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a dual-dimension storage approach by maintaining both row-oriented and column-oriented representations of the same data. This dimensional transformation allows the system to optimize for different operation types without sacrificing performance in either dimension.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Speed

If column-oriented storage is used, then read times are reduced, but write accesses increase

Engineering Contradiction:
Improveread speedVSAvoidwrite operation efficiency
Core Design Contradiction:
SpeedVSProductivity

Solution Approach 1:

The patent segments the storage system into distinct row and column storage components, each optimized for specific operation types. Column storage handles read operations efficiently while row storage handles write operations, resolving the contradiction between read speed and write efficiency.

Inventive Principle:
Principle #1Segmentation

3Speed

If caching layers are added to improve performance, then data access speed increases, but system complexity increases

Engineering Contradiction:
Improvedata access speedVSAvoidsystem architecture complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The patent merges the database storage engine directly with the programming language runtime environment, eliminating the need for separate caching layers. This integration achieves high data access speed while reducing system complexity by removing intermediate components.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent introduces a new intermediary layer that directly integrates database operations into the programming language, replacing traditional caching layers. This mediator provides both speed improvement and complexity reduction by unifying data access patterns.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Reliability

If multiple tiers of servers are used, then database capabilities are enhanced, but programming complexity increases

Engineering Contradiction:
Improvedatabase capabilityVSAvoidprogramming complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent merges database functionality directly into the programming language runtime, consolidating multiple server tiers into a unified system. This integration maintains enhanced database capabilities while reducing programming complexity by providing native database support.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent creates a universal database interface that is natively integrated into the programming language, allowing the system to perform multiple database operations through a single unified mechanism rather than requiring separate tiers for different operations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS10942915B2Method and apparatus for database
Publication Date: 2021.03.09 MONGODB INC
  • US10942915B2 patent drawing
  • US10942915B2 patent drawing
  • US10942915B2 patent drawing

AI summary

A method for representing a database in a computer readable medium. Accessing a first table in the database. The first table has rows of data, each row of data having one or more columns. Storing a first representation of the first table in a volatile computer memory in a column-oriented format, the column-oriented format comprising at least one B-tree for at least one column, wherein the B-tree is composed of at least one array and the at least one B-tree includes references to a plurality of arrays, each array of the plurality of arrays comprised of data corresponding to the rows of one column of the table, wherein the storing further comprising storing data corresponding to the rows in a packed format. Storing a second representation of the database on the computer-readable medium, the second representation substantially identical to the first representation.