Database Partitioning via Business Dependency Graphs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database partition solutions are limited by additional constraint conditions, such as the constrained tree schema (CTS) requirement, which restricts their adaptability to various types of databases, leading to inefficiencies in managing complex business processes and data access.
Innovation Solution
A method and apparatus that analyze business dependencies between database tables to generate a dependency graph, which is then cut into sub-graphs, allowing for vertical partitioning of databases into parts that correspond to these sub-graphs, eliminating the need for additional constraint conditions and enhancing database response performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If existing vertical partition solutions are applied to databases, then data amount in single data node is reduced, but additional constraint conditions (CTS) are imposed that limit adaptability
Solution Approach 1:
The patent changes the fundamental parameter of partitioning methodology from constraint-based (CTS schema requirements) to dependency-based (business process relationships). By transforming the partitioning criterion from structural constraints to functional dependencies, the system achieves adaptability across diverse database types while effectively reducing data volume per node through intelligent table grouping.
Solution Approach 2:
The patent creates a universal partitioning framework that can handle various database types (relational, NoSQL, hybrid) and schemas without requiring specific constraint conditions. The dependency graph approach serves multiple functions: analyzing table relationships, determining partition groups, and guiding data distribution, making the solution applicable to any database structure regardless of its specific type or schema constraints.
2Device complexity
If all tables are stored in the same data node, then database structure is simple, but response time becomes lengthy and outages occur due to excess accesses
Solution Approach 1:
The patent segments the database by grouping tables into different partition groups based on their business process dependencies. Tables that are frequently accessed together or have strong dependency relationships are placed in the same partition, while tables with weak or no dependencies are separated. This segmentation distributes access load across multiple data nodes, reducing response time and preventing outages without requiring complex manual configuration.
Solution Approach 2:
The patent introduces a dependency graph as an intermediary structure that analyzes and represents the relationships between tables. This dependency graph serves as a mediator that automatically determines optimal table groupings for partitioning, eliminating the need for manual configuration and reducing the complexity of managing distributed database structures while improving access performance.
3Speed
If current partition solutions are used, then data access performance is improved, but they cannot adapt to databases that do not conform to CTS requirements
Solution Approach 1:
The patent implements a dynamic partitioning approach where the dependency graph is constructed and analyzed based on the specific characteristics of each database instance. Rather than requiring static constraint conditions like CTS, the system dynamically adapts to the actual table relationships and business processes present in the database, enabling high-performance access patterns for any database schema type while maintaining adaptability to changing requirements.
Data Source
AI summary
A method for partitioning a database includes obtaining business dependency between data in a plurality of tables in the database on the basis of a business process associated with the database; generating, on the basis of the business dependency, a dependency graph describing a dependency relationship between the plurality of tables; cutting the dependency graph into at least two sub-graphs; and vertically partitioning the database into at least two parts corresponding to the at least two sub-graphs respectively.