App Server Multiplexing for Database Resource Utilization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database environments are limited in operational flexibility and resource utilization, as they typically require separate application servers for each database instance, leading to inefficiencies and the need for frequent database splits when storage thresholds are reached, such as at 30 TB, which can result in operational unmanageability and suboptimal processor utilization.
Innovation Solution
The proposed solution redesigns app server architecture to allow any given app server to serve requests for multiple database instances and multiple database servers within a single pod, enabling multiple logical databases to be hosted without provisioning additional application servers, allowing for improved resource utilization and horizontal scaling beyond traditional limits by splitting databases by data files and partitions rather than moving data or creating new pods.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If separate application servers are provisioned for each database instance, then database service reliability is improved, but device complexity and resource utilization efficiency deteriorate
Solution Approach 1:
The application server is designed to service multiple database instances simultaneously, transforming it from a dedicated single-function server to a universal multi-functional server. This allows one application server to handle requests across multiple database instances, reducing the total number of servers needed while maintaining service reliability through distributed database access.
Solution Approach 2:
Multiple database instances are merged into a single pod that can be serviced by shared application servers. Instead of having separate dedicated infrastructure for each database instance, the system combines multiple databases into a unified environment that shares computational resources, thereby reducing overall system complexity.
2Adaptability or versatility
If database storage threshold is increased to avoid splits, then operational flexibility is improved, but resource utilization efficiency deteriorates
Solution Approach 1:
The system implements dynamic database splitting capability that allows databases to be divided into multiple instances based on storage requirements. When a database reaches a storage threshold, it can be automatically or manually split into multiple instances within the same pod, providing operational flexibility without requiring fixed storage allocation planning.
Solution Approach 2:
Databases can be segmented into multiple instances when storage thresholds are reached. Instead of preventing splits by increasing storage limits, the system allows segmentation into multiple database instances that share the same application server infrastructure, maintaining resource efficiency while providing operational flexibility.
3Ease of manufacture
If database splits are performed frequently to maintain storage thresholds, then storage management is improved, but operational manageability deteriorates
Solution Approach 1:
The application server's ability to service multiple database instances universally simplifies the management of split databases. Whether a database is single-instance or split into multiple instances, the same application server infrastructure handles all requests, eliminating the need for separate management procedures for different database configurations.
4Quantity of substance
If additional application servers are provisioned to handle increased data capacity, then data capacity is improved, but device complexity and cost deteriorate
Solution Approach 1:
Application servers are designed with universal capability to service multiple database instances, allowing the same server infrastructure to handle increased data capacity through database splitting rather than requiring additional servers. This maintains data capacity expansion while avoiding increased infrastructure complexity.
Data Source
AI summary
Techniques for database multiplexing. Within a group of two or more logical databases, each having a plurality of database nodes, the group of logical databases being part of a multitenant database environment that stores data for multiple client entities each identified by a tenant identifier (ID) having one of one or more users associated with the tenant ID, wherein users of each of multiple client entities can only access data identified by a tenant ID associated with the respective client entity, and wherein the multitenant database is a hosted database provided by an entity separate from the client entities, and provides on-demand database service to the client entities, the tenant ID is used to determine a mapping between the tenant ID and one of the plurality of logical databases. A plurality of application servers coupled with two or more of the logical databases are used to service requests received from remote client device using the mapping to access a selected logical database corresponding to the tenant ID.