CSQL Cache Deployment Scenarios
<< Overview Of CSQLCache System - TOC - CSQL Cache Installation >>
Active Result Set Cache
In result set based caching strategy adopted by applications, one of the major drawbacks is changes to the source table will not be reflected in the cached result set. This limits the strategy to be used only for tables, which are never updated. In active result set caching, applications are allowed to update result set either directly in CSQL MMDB or on the target database in which case it is automatically pushed to cache table at CSQL MMDB. It also allows querying on the cached result set (as it is stored in MMDB) using SQL queries.
Fig : Active Resultset Caching
In this architecture, there will be one CSQL MMDB and one target database. The application talks to CSQL cache through the standard JDBC or ODBC interface. The tables to be cached say “customer_info” (from telephone billing database) is loaded from the target database into CSQL MMDB. If this table is updated in the target database by some other backend application, the updated/inserted record is pushed to CSQL cache by employing bi-directional mode.
Transparent Caching with Gateway
In this architecture also, CSQL gateway module provides a unified interface to applications through the standard JDBC or ODBC. Application changes the DSN name for ODBC application or connection URL for JDBC applications to employ caching.
Fig : Gateway Cache
Frequently accessed tables are cached from target database into CSQL MMDB and gateway component enables access/modifications to cached tables in CSQL MMDB and non-cached tables, which reside only in the target database.
If the application sends a select query, requesting some records from the table “customer_info”, the gateway checks whether the table resides in the CSQL cache. If it is so, it returns records from CSQL. If the table is not found in the Cache, the gateway returns the records from the target database. If our application inserts/updates any record in the cached table, that operation is effected in both cache and the target database by the gateway.
This gateway cache can be configured in three ways. They are read intensive cache, read/write intensive cache and write intensive cache.
Read Intensive Cache
This deployment mode is useful when the reads are more than writes on cached tables. In flight booking management system, flight schedules are read-only and are not updated frequently. They shall be cached in CSQL cache, so that applications accessing these timetables will get ultra-fast response.
Fig : Read intensive cache
Application connected to gateway fetches records from either CSQL MMDB (in case of cached table) or from target database (in case of non-cached table). If application does updates (which happens very rarely as the application is read intensive) in the cached table, CSQL MMDB will do the same operation on target database before the commit operation returns. So in this architecture, reads are ultra fast and writes are comparatively slow as it involves updating both cache and target database before commit returns.
Read/Write Intensive Cache
This deployment is suitable for applications, which have equal probability for read and write operations to database.
Fig : Read Write Intensive Cache
Here everything is same as the read intensive cache except the update propagation mode between CSQL MMDB and target database. If a transaction tries to update the cached table, CSQL MMDB carries out the operation in its cached table and then just informs another internal process (applier) to perform the same operation in the target database. Commit operation returns immediately after updating the cache, it delivers better performance for modification operations.
Write Intensive Cache
CSQL MMDB performs write operations faster than disk-based databases. If there is any performance bottleneck on write operations, then applications can use this deployment option to improve write operations.
Fig : Write Intensive Cache
Here the application, Gateway and CSQL MMDB lies in one machine and another applier process runs in the host where target database is running. Updates on cached tables are propagated to another process called (applier) which runs in target database host and that process takes care of executing the operations on behalf of CSQL MMDB. This reduces the computing cycles for the application, as it does not perform execution at the host where application resides.
Multi Node Cache
Applications can scale up by employing multiple cache nodes to cache tables. This architecture consists of many CSQL gateways, each having its own CSQL cache. All the gateways are connected to a single target database. Applications shall be connected to any one of the gateways through the standard JDBC/ODBC interface.
Fig : Multi Node Cache
In this configuration, each CSQL MMDB shall cache complete table at all nodes or a subset of records in each node. For example, for caching ‘customer_info’ table using this architecture, all the zone 1 customer details will be cached in the first CSQL cache, the second one caches the zone 2 customer details and the last one caches the zone 3 customer details. In this way, any number of nodes could be added, thus improving the performance of the entire system. All the gateways are then connected to a centralized server in which the actual ‘customer_info’ table resides. In case of telecom domain, each zone (Bangalore, Chennai, Delhi, Mumbai etc.,) contains CSQL cache with only their zone customer details and all these servers are connected to a centralized database server (target database), which contains information about all the customers in India.
By enabling bi-directional caching at all cache nodes, updates on any of the cache instances will be propagated to other cache nodes automatically. In the above deployment scenario, provisioning application and the reporting application talk directly to the target database. The provisioning application inserts/updates the original table in target database, which is then pushed into the corresponding CSQL MMDB only. For example, new customer added to Chennai zone will be available only in the Chennai Zone CSQL Instance.
Coherent Multi Node Cache
This deployment option is useful for application with stringent cache consistency requirements. When update operation is performed on one cache node, it should be reflected in all the other cache nodes as well before it returns to the application. This can be used for banking applications to cache account table for accessing balance amount before performing any withdrawal. When the withdrawal transaction completes, the balance amount should be updated in all the other cache nodes as well.
Fig : Coherent Multi Node Cache
Each cache server can communicate to the other caches instances either synchronously or asynchronously. In synchronous communication, when application updates the cached table, the updates are applied to all the cache instances before returning to the application. In asynchronous communication, when application updates the table, the updates are applied to CSQL MMDB and returns to the application. Another process “applier” takes care of applying these updates on other cache instances asynchronously thereby improving the throughput of updates.
<< CacheGuide/OverviewOfCSQLCacheSystem - TOC - CSQL Cache Installation >>