Tenant-Level Database Migration Via Shared Storage
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-tenant database architectures face inefficiencies in resource utilization and cost, particularly when managing multiple tenants with varying resource needs, as they often require dedicated database instances per tenant, leading to suboptimal resource sharing and increased costs.
Innovation Solution
A method for tenant-level moves within native multi-tenant database systems, where a target database instance is created with suitable resources, and the tenant's catalog and data are exported to a shared storage, then imported to the target instance, ensuring identical replication and switching access to the target instance, while maintaining customer-controlled encryption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a dedicated database instance is provisioned per tenant, then data separation and security are improved, but resource utilization efficiency deteriorates and costs increase
Solution Approach 1:
The patent segments the database instance into multiple isolated tenant environments, where each tenant operates with dedicated schemas, tables, and data spaces within the shared database. This segmentation provides strong data separation and security boundaries while allowing the underlying physical resources to be shared, thus resolving the contradiction between data isolation and resource efficiency.
Solution Approach 2:
The patent merges multiple tenant database instances into a single shared database instance, allowing multiple tenants to coexist in the same physical database infrastructure. This consolidation improves resource utilization efficiency by eliminating redundant resources while maintaining logical data separation through tenant-specific schemas and security policies.
2Productivity
If a single database instance manages multiple tenants, then resource sharing and cost efficiency are improved, but data isolation and security may be compromised
Solution Approach 1:
The patent implements logical segmentation within the shared database instance by creating separate schemas, tables, and data spaces for each tenant. This segmentation ensures that each tenant's data is isolated at the logical level, preventing unauthorized access while allowing physical resource sharing, thus maintaining both data isolation and resource efficiency.
Solution Approach 2:
The patent introduces tenant-specific schemas and security policies as intermediary layers between the shared database instance and individual tenant data. These intermediaries enforce data isolation rules and access controls, ensuring that tenants can share physical resources while their data remains securely isolated through the intermediary security mechanisms.
3Ease of manufacture
If the smallest database instance consumes 32 Gb of memory, then resource allocation is simplified, but computing resource waste increases for small tenants
Solution Approach 1:
The patent combines multiple small tenant workloads into a single shared database instance, allowing them to share the underlying memory and computing resources. This consolidation eliminates the need for each tenant to have a separate minimum-sized database instance, thereby reducing computing resource waste while maintaining ease of resource allocation through the shared infrastructure.
Solution Approach 2:
The patent creates a universal shared database instance that serves multiple tenants simultaneously, where the same physical resources (memory, CPU, storage) can be dynamically allocated and shared among different tenants based on their actual needs. This multi-functionality allows the system to efficiently serve both small and large tenants without requiring separate instances, reducing overall resource waste.
Data Source
AI summary
Systems and methods include reception of a request to move a first database tenant from a first database instance to a second database instance, the first database tenant comprising a first tenant object instance associated with a plurality of artifacts of the first database instance, the plurality of artifacts including a tenant-level catalog and data. In response to the request, the tenant-level catalog is exported from the first database instance to a shared storage system, the tenant-level catalog is imported to a second tenant of the second database instance from the shared storage system, the data is exported from the first database instance to the shared storage system, the data is imported to the second tenant of the second database instance from the shared storage system, and the first database tenant is dropped from the first database instance.