<< TOC - CSQL Cache Deployment Scenarios >>
Overview of CSQL Cache System
CSQL Cache is employed in real time applications for accelerating and speeding up access to disk-based databases such as Oracle, Sybase, MySQL or Postgres. It comprises a high performance main-memory database (performs 20-40X faster than traditional disk database management systems), which provides microsecond response times for data manipulation operations.
Architectural Overview
CSQL Cache is a high performance, bi-directional updateable data-caching infrastructure that sits between the clustered application process and back-end data sources. It provides unprecedented high throughput to your application by offloading the computing cycles from expensive backend systems along with reduction in costly network calls, thereby enabling real time application to provide faster and predictive response time.
CSQL Cache uses the fastest Main Memory Database (CSQL MMDB) designed for high performance and high volume data computing for caching the table and provides most flexible and cost-effective way to cache and manage enterprise information without compromising on transactional and indexed access to the data. This main memory database is 20-40 times faster than traditional disk based database system as the database completely resides in main memory and developed to be used on real time high computing data platforms.
Fig : Architectural Overview
Caching happens at table level granularity in CSQL, which means that the tables, which are frequently accessed by the applications, shall be cached in CSQL MMDB. Once these tables are loaded, they are treated like normal CSQL tables and any DML operation is allowed on these tables.
The difference between normal CSQL table and cached table is that, the CSQL server propagates DML operations INSERT, UPDATE, DELETE on cached tables to target database automatically. These updates can be propagated to target database in two modes, SYNC and ASYNC from CSQL. In SYNC modes, execute( ) returns after performing the operation at both cache and original table. In case of ASYNC mode, execute( ) returns immediately after inserting into the cache; this operation is propagated to original table in target database by another process. ASYNC mode is also called write behind mode.
Apart from caching tables from target database, CSQL Cache also acts as a transparent gateway, which allows the application to access the tables, which are not cached in CSQL. Application is completely unaware of this caching as CSQL Cache provides a unified interface to the applications and it does not need to deal with the location of the table, making the underlying database caching architecture transparent to the application layer. This minimizes the code changes for existing applications to adapt CSQL caching.
Main Features
The following are some of the features of CSQL Cache
Updateable Cache Tables
Most of the existing cache solutions are read only which limits their usage to small segment of the applications, i.e. non-real time applications. In CSQL, updates are allowed on cached tables and these updates are automatically applied on the original table in the target database.
Bi-Directional Updates
For updateable caches, updates that happen directly on the original table on the target database come to cache automatically.
Synchronous and Asynchronous update propagation
The updates on cache table shall be propagated to target database in two modes. Synchronous mode makes sure that after the database operation completes the updates are applied at the target database as well. In case of Asynchronous mode the updates are delayed to the target database providing better performance for modification operations.
Synchronous mode gives high cache consistency and is suited for real time applications. Asynchronous mode gives high throughput and is suited for near real time applications where applications can tolerate inconsistency of records at cache and original table for few milliseconds.
Multiple cache granularity
CSQL supports Table level and Result-set caching. Major portions of corporate databases are historical and infrequently accessed. But, there is some information that should be instantly accessible like premium customer’s data, records of one zone, etc.
Recovery for cached tables
In case of system or power failure, during the restart of caching platform all the committed transactions on the cached tables can be recovered.
Tools to validate the coherence of cache
In case of asynchronous mode of update propagation, cache at different cache nodes and target database may diverge. This needs to be resolved manually and the CSQL Cache provides tools to identify the mismatches and take corrective measures if required.
Horizontally Scalable
Clustering is employed in many solutions to increase the availability and to achieve load balancing. CSQL Cache works in a clustered environment spanning to multiple nodes and also keeps the cached data coherent across the nodes.
Transparent access to non-cached tables reside in target database
CSQL Cache keeps track of queries and intelligently route to the database cache or to the origin database based on the data locality without any application code modification.
Transparent Fail over
There will not be any service outages, incase of caching platform failure. Client connections are automatically routed to the target database.
Minimal Code Change to adapt caching
No or very minimal changes to application for the caching solution.
Support for standard interfaces
Caching is supported for standard interfaces including JDBC and ODBC that will make the application to work seamlessly without any application code changes. It intelligently routes all stored procedure calls to target database so that they don’t need to be migrated.
Support for caching from any target database
CSQL can cache tables from any DBMS provided they have ODBC driver to access the data. Though CSQL can cache tables from any database, it is tested for MySQL, PostgreSQL, Sybase, DB2 and Oracle databases currently.
<< TOC - CSQL Cache Deployment Scenarios >>