Multi-tenant Database Schema Conversion via Abstraction Layer
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current multi-tenant database deployment options lack the ability to convert between different isolation levels without manual data movement and system downtime, requiring recoding of applications and affecting hardware costs and scalability.
Innovation Solution
A method and system that utilize an abstraction layer to manage tenant-specific data sets by converting between different multi-tenant deployment options, allowing seamless data isolation changes without application recoding and maintaining system availability during conversion.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If tenant data is stored in separate databases, then data isolation is maximized, but hardware costs and backup costs increase
Solution Approach 1:
The patent segments data isolation at the schema level within a single database rather than creating separate databases for each tenant. Each tenant gets their own schema with tables, views, and stored procedures that are logically isolated but physically stored together, achieving strong data isolation with shared hardware resources.
Solution Approach 2:
The patent merges multiple tenant databases into a single database instance with multiple schemas. This allows the system to maintain separate logical data spaces for each tenant while sharing physical storage, indexing structures, and database engine resources, thereby reducing hardware costs while preserving data isolation.
2Quantity of substance
If multiple tenants are housed in the same database with separate schemas, then hardware costs decrease, but data isolation is reduced
Solution Approach 1:
The patent uses database schemas as logical containers to segment tenant data. Each schema acts as an independent namespace with its own tables, views, and stored procedures, ensuring that tenants can access only their own data even though all schemas reside in the same physical database instance.
Solution Approach 2:
The patent introduces an abstraction layer as an intermediary between applications and the physical database. This abstraction layer translates application queries into schema-specific queries, providing a layer of indirection that maintains data isolation while allowing efficient shared access to the underlying database resources.
3Loss of time
If conversion between deployment options is performed manually, then data movement is controlled, but system downtime occurs and application recoding is required
Solution Approach 1:
The patent makes the database schema dynamic by allowing runtime switching between different schema configurations. The system can dynamically create, drop, and switch between schemas based on deployment requirements, enabling seamless conversion between deployment options without manual intervention or application recoding.
Solution Approach 2:
The patent uses schema copying mechanisms to facilitate deployment conversions. When converting between deployment options, the system can copy existing schemas to new locations or create mirrored schemas, allowing data to be moved between deployment configurations without disrupting application access or requiring code changes.
4Quantity of substance
If the same database and tables host multiple tenants, then hardware costs are minimized, but data isolation is weakest
Solution Approach 1:
The patent segments the database into multiple schemas, where each schema contains tenant-specific tables and views. This logical segmentation ensures that even though all data resides in the same physical database, tenants cannot access each other's data through the shared table structure, maintaining strong data isolation with minimal hardware resources.
Data Source
AI summary
A method, computer program product and system for managing tenant-specific data sets in a multi-tenant system, by receiving a request to convert a data set in a physical data store from a first type of multi-tenant deployment to a second type of multi-tenant deployment, retrieving tenant identification metadata identifying a tenant making the request, modifying the data set in the physical data store based on the second type of multi-tenant deployment, and modifying metadata associated with an abstraction layer to allow the modified data set to be accessed.