Adaptive Database Cache with Janus Query Plans
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database caching techniques struggle to maintain consistency and adaptiveness in dynamic transactional web applications, particularly due to limitations in static HTML caching, full-table caching difficulties, and the restrictive nature of materialized views, which hinder efficient access to frequently updated data.
Innovation Solution
A system and method providing transparent, adaptive caching functionality through cache tables defined by a database cache model, utilizing two-headed query plans and dynamic population based on query characteristics, allowing seamless routing between local and remote database servers without altering the database schema, and enabling declarative and dynamic settings for cache management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If full-table caching is implemented, then data access speed is improved, but replication and maintenance costs increase significantly
Solution Approach 1:
The patent segments the caching approach by implementing view-based caching instead of full-table caching. Materialized views cache only specific query results and data subsets that are actually needed, dividing the cache into manageable, purpose-specific segments rather than caching entire tables. This reduces cache data volume while maintaining data access speed for critical queries.
Solution Approach 2:
The patent applies partial action by caching only the necessary portions of data through materialized views. Instead of caching complete tables (excessive action), the system caches only specific views and query results that are frequently accessed, achieving adequate data access speed without the overhead of full-table caching.
2Ease of manufacture
If materialized views are used for sub-table caching, then maintenance complexity is reduced, but adaptability to changing workloads is limited
Solution Approach 1:
The patent implements dynamics by enabling runtime switching between cached views and backend databases. The system can dynamically adapt to changing workloads by selecting whether to serve queries from materialized views or directly from the database, providing flexibility that static materialized view approaches lack while maintaining ease of implementation through standardized view mechanisms.
Solution Approach 2:
The patent applies parameter changes by allowing the system to adjust caching behavior based on workload characteristics. Query optimization can change parameters such as cache validity periods, refresh frequencies, and view selection criteria to adapt to varying workload demands, combining the simplicity of materialized views with improved adaptability.
3Productivity
If caching is implemented at multiple levels in the application infrastructure, then scalability is improved, but response time deteriorates due to cache invalidation and consistency maintenance
Solution Approach 1:
The patent extracts the cache consistency problem by implementing view-based caching that naturally isolates cache validation. Materialized views can be independently validated and refreshed without affecting other cache layers, removing the complex interdependencies that cause consistency maintenance delays in multi-level caching architectures.
Solution Approach 2:
The patent introduces materialized views as intermediaries between the database and application layers. These views act as mediators that can be independently managed, validated, and refreshed, simplifying consistency maintenance across multiple caching levels by providing clear boundaries and validation points.
4Speed
If static HTML caching is used, then response time is improved for static content, but effectiveness decreases for dynamic and personalized content
Solution Approach 1:
The patent applies local quality by implementing caching at the view level rather than the page level. Different materialized views can be optimized for different types of content (static vs. dynamic), allowing each cache to have properties tailored to its specific data characteristics and access patterns, improving both response time and dynamic content support.
Data Source
AI summary
A local database cache enabling persistent, adaptive caching of either full or partial content of a remote database is provided. Content of tables comprising a local cache database is defined on per-table basis. A table is either: defined declaratively and populated in advance of query execution, or is determined dynamically and asynchronously populated on-demand during query execution. Based on a user input query originally issued against a remote DBMS and referential cache constraints between tables in a local database cache, a Janus query plan, comprising local, remote, and probe query portions is determined. A probe query portion of a Janus query plan is executed to determine whether up-to-date results can be delivered by the execution of a local query portion against a local database cache, or whether it is necessary to retrieve results from a remote database by executing a remote query portion of Janus query plan.