Guide to choose best caching strategy

8/14/2019 Guide to choose best caching strategy

1/15

CSQL CacheWhite-paper to help you choose the best caching

strategy for your application


2/15

CSQL Cache Whitepaper

LAKSHYA 2 / 15


Disclaimer

Copyright @ LAKSHYA 2008

The information being shared in this whitepaper document is purely for technical and / orproduct reference. This document and any information enclosed within this documentcontains restricted and / or limited information and you must not disseminate, modify,copy/plagiarize or take any action in reliance upon it, unless permitted to by Lakshya

Solutions Limited. None of the material in the document can be reproduced in any form.

Lakshya Solutions Limited is in no way liable for any actions taken by the reader basedupon the contents of this document.

All rights reserved

All other brands, logos and products are trademarks or registered trademarks of theirrespective companies.

Compiled by T Prabakaran

Go to www.csqldb.com for more information

Published in 16th March 2009

By Arindam Chakravorty for LAKSHYA Solutions Limited

India.


3/15


LAKSHYA 3 / 15


Publishing History

Version number Release Date1.0 16th MARCH 2009

List of Acronyms

DSN - Data Source NameMMDB - Main Memory DatabaseJDBC - Java Database ConnectivityODBC - Open Database ConnectivitySQL - Structured Query Language

URL - Uniform Resource Locator


4/15


5/15


LAKSHYA 5 / 15


Introduction

With the increase in the speed of doing business, and with the ever-increasing volume of

information that enterprises must process, businesses in every industry domain has toimplement methods & systems to manage & use real time data in order to survive,compete & win.

The catch is, even though there is huge demand for speed, enterprises are reluctant tomigrate their applications, as they do not want to give up the existing database systemsthey have been using for many years and that are proven to be stable in theirenvironment.

With the ever growing gamut of Web and real time applications which are mostly readintensive even though some are read/write intensive, a massive performance boost canbe realized by caching frequently accessed tables at the application tier, it will reduce

load on the backend databases and reduce network calls, thereby resulting in very highthroughput. Hence a caching solution on top of your enterprise database can givedisruptive performance benefits to your real time processing jobs.

What is CSQL Cache?

CSQL Cache is a generic database-caching platform to cache frequently accessedtables from your existing open source or commercial database management system(Oracle, MySQL, etc) close to application tier. It uses the fastest Main Memory Database(CSQL MMDB) designed for high performance and high volume data computing tocache the table and enables real time applications to provide faster and predictiveresponse times with higher throughput.

CSQL Caching uses transactionlog based replication schemeusing TCP/IP, to deliver higherperformance withoutcompromising on the consistencyof cached data and the originaltable in the existing database.CSQL provides applicationtransparent caching usinggateway module that takes careof providing unified interface toboth cached and non-cachedtables.

CSQL supports two transactionpropagation modes for updateable cache tables namely synchronous andasynchronous modes. This enables CSQL to enable applications to optimise betweenhigh throughput and high consistency


6/15


LAKSHYA 6 / 15


In case of synchronous mode, transaction commit returns only after the transaction iscommitted at cache instance and target database, whereas in case of asynchronousmode, source site transaction commit return immediately after the transaction iscommitted at the cache. Caching process takes care of applying these transactions attarget database.

Benefits

Performance

CSQL Cache delivers 100x faster response times for cached tables as it uses thefastest MMDB for caching and there is no network overhead involved for accessingcached tables.

Load balancing database operations on multiple cache instances improves throughputmultifold. Most of the real time applications are read intensive and by employing clusterwith multiple CSQL cache instances, load can be distributed among all of them toimprove the overall application throughput.

Consistency

Tables cached using CSQL are by default updateable. Transactions, which modifycache tables, are applied at the target database so as to keep the cache consistent withthe target database. CSQL also supports bi-directional caching in which any directupdates on the target databases are automatically propagated to cache.

Ease of use

CSQL Cache is simple to use and requires minimal setup to get the data cached.Requires no changes to application and minimal administration as CSQL has inbuilt self-healing mechanisms to tolerate faults.

Applications shall access cached tables at CSQL MMDB as well as non-cached tables attarget database, which makes sure that no code changes are required in application(Checking whether the table is cached or not and divert queries to existing database orCSQL MMDB cache based on that).

Scalability

Leverages multi core and processor architecture machines as it uses highly concurrentCSQL MMDB. For more information refer CSQL MMDB data sheet.

CSQL supports distributed caching in which multiple cache nodes shall be employed for

load balancing, still preserving the cache coherence in all cache instances and targetdatabase. There is no limit on the total number of cache instances in the quorum.

Stability

Enterprises traditionally are averse to taking risks in trying out newer / alternatedatabase management systems. CSQL works in conjunction with existing database andimproves performance of hot tables, without any requirement of replacing the existingDBMS.


7/15


LAKSHYA 7 / 15


Reduces development effort

Through its standard interface support (ODBC and JDBC), it reduces the learning curvefor developers to adopt CSQL in their applications. It requires no DBA and completelyeliminates requirements for performance tuning.

By its inherent transparent caching mechanism, applications shall access cached tablesat CSQL MMDB as well as non-cached tables at target database, which makes sure thatno code changes are required in application. This reduces huge development andtesting effort.

Feature Summary

Cache Granularity

CSQL supports updateable caching at multiple granular levels

o Table level caching, caches all the records from the original table whereas,

o Partial table caching allows applications to choose what fields and whatrecords needs to be cached. This is useful in cases where the original tableis too big that it cannot be fit in the available memory.

Bi-directional Transaction Propagation

When there are direct updates on the target database (application updates the originaltable in target database), CSQL cache server automatically receives updates from targetdatabase and applies them on cached table periodically to keep the cache consistentwith the original table.

Transaction Propagation Modes

Transactions that affect cached tables are applied at original tables in target database intwo modes namely, Synchronous and Asynchronous.

In case of multi node caching, these transactions are also applied in all the other nodes,which cache that table. The mode between two cache instances need not be same. Forexample for two cache instances instance1 and instance2, instance1 can

propagate transactions to instance2 in synchronous mode and instance2 can

propagate to instance1 in asynchronously or choose not to propagate at all.


8/15


9/15


LAKSHYA 9 / 15


As CSQL maintains redo log records and checkpoint for cached tables, recoverybecomes faster as it retrieves only the incremental changes from the target databaseand other instances in the cluster.

Data Consistency

CSQL employs transaction consistent caching, if transaction fails at target databaseconnected using synchronous propagation mode fails, the transactions fails at the cachealso. This ensures that two parallel conflicting transactions (For example deductingbalance from account) running in cache and original table to fail and ensure consistencyof data between cache and the original table.

For asynchronous mode propagation, transaction conflicts are detected and logged intofile so that the administrator can resolve conflicts. Conflict resolution could be additive,subtractive or replacing based on the data on which conflict occurred. For Example incase of conflicting deposit, conflict resolution is additive whereas for withdrawal, it issubtractive.

CSQL Cache provides tools to check for consistency between cache and original tableconnected in asynchronous mode to assist application for ensuring and maintaining dataconsistency between cache and original table.

Interface supportCSQL cache provides JDBC and ODBC driver. Existing applications require changes toDSN name in case of ODBC driver and database URL in case of JDBC to adaptcaching. It also provides PHP-ODBC interface for applications written in PHP.

Supported Database PlatformsCSQL supports any database management system, which provides standard ODBCdriver. CSQL caching is tested with Oracle, MySQL and Postgres. Testing for otherDBMS are underway based on the priorities. If you are using any other database, andwant to cache tables with CSQL Cache, send us a mail to [email protected] to getit tested and certified at priority.

Platform Supported

Linux x86Linux x86_64 and Solaris are under development

Deployment Options

Active Result Set Cache

In result set based caching strategy adopted by applications, one of the majordrawbacks 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 CSQLactive result set caching mode, applications are allowed to update result set eitherdirectly in CSQL MMDB or on the target database in which case it is automaticallypushed to cached table at CSQL MMDB. Another advantage of CSQL Cache is that italso allows querying on the cached result set (as it is stored in MMDB) using SQLqueries.


10/15


LAKSHYA 10 / 15


In this architecture, there will be one CSQL MMDB and target database. The applicationtalks to CSQL cache through the standard JDBC or ODBC interface. The tables to becached say customer_info (from telephone billing database) is loaded from thetarget database into CSQL MMDB. If this table is updated in the target database bysome other backend application, the updated/inserted record is automatically pushed toCSQL cache by employing bi-directional mode. This mode is suited for developing newapplications and requires code changes for existing applications.

Transparent Caching with Gateway

In this model, CSQL gateway module provides a unified interface to applications throughthe standard JDBC or ODBC interface. Existing application just changes the DSN namefor ODBC application or connection URL for JDBC applications to employ transparentcaching.

Frequently accessed tables are cached from target database into CSQL MMDB andgateway component enables access/modifications to cached tables in CSQL MMDB andnon-cached tables, which reside only in the target database.

If the application sends a select query, requesting some records from the tablecustomer_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 gatewayreturns the records from the target database. If our application inserts/updates anyrecord in the cached table, that operation is effected in both cache and the targetdatabase 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.


11/15


12/15


LAKSHYA 12 / 15


informs another internal process (applier) to perform the same operation in the targetdatabase. Commit operation returns immediately after updating the cache, therebydelivering high throughput for modification operations.

Write Intensive Cache

CSQL MMDB performs write operations faster than disk-based databases. If you haveperformance bottleneck on write operations, then applications can use this deploymentoption to improve throughput for write intensive transactions.

Here the application, Gateway and CSQL MMDB lie in one machine and anotherprocess applier executes in the host where target database is running. Updates oncached tables are propagated to another applier process, which runs in the targetdatabase host and it takes care of executing the operations on behalf of CSQL MMDB.This reduces the computing cycles on the host where the application runs.

Multi Node Cache

Applications can scale up by employing multiple cache instances to cache tables. Thisarchitecture consists of many CSQL gateways, each having its own CSQL cache. All thegateways are connected to a single target database. Applications shall be connected toany one of the gateways through the standard JDBC/ODBC interface.


13/15


LAKSHYA 13 / 15


In this configuration, each CSQL MMDB shall cache complete table at all nodes or asubset 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 details. In this way, we can add any number of nodes, thus improving the performanceof the entire system. All the gateways are then connected to a centralized server inwhich the original customer_info table resides. In a typical telecom scenario, eachzone or circle (Bangalore, Chennai, Delhi, Mumbai etc.) contains CSQL cache with onlytheir respective customer details and all these servers are connected to a centralizeddatabase server (target database) which contains information about all the customers inIndia.

By enabling bi-directional caching at all cache nodes, updates on any of the cacheinstances will be propagated to other cache nodes automatically. In the abovedeployment scenario, provisioning application and the reporting application talk directlyto the target database. The provisioning application inserts/updates the original table intarget database, which is then pushed into the corresponding CSQL MMDB only. Forexample, new customer added to Chennai zone will be available only in the ChennaiZone CSQL Instance.


14/15


LAKSHYA 14 / 15


Coherent Multi Node Cache

This deployment option is useful for application with stringent cache consistencyrequirements. When update operation is performed on one cache node, it should bereflected in all the other cache nodes as well before it returns to the application. This canbe used for banking applications to cache account table for accessing balance amount

before performing any withdrawal. When the withdrawal transaction completes, thebalance amount should be updated in all the other cache nodes as well.

Each cache server can communicate to the other caches instances either synchronouslyor asynchronously. In synchronous communication, when application updates thecached table, the updates are applied to all the cache instances before returning to theapplication. In asynchronous communication, when application updates the table, theupdates are applied to CSQL MMDB and returns to the application. Another processapplier takes care of applying these updates on other cache instances asynchronouslythereby improving the throughput of updates.


15/15



Conclusion

We are in the Information age even though its an oft repeated clich but nowhere itstruer than in the growing demands of businesses the world over for even faster accessto information from ever increasing volumes of data. Its like a black hole and

businesses which do not have systems in place that can feed this informationrequirement at the required speeds will not survive.

CSQL Cache coupled with CSQL Main Memory Database is the ideal solution to helpbusinesses meet their information needs at speeds and volumes that are the norm todayand in the coming days.

If the solution looks interesting, do write to us with your queries to [email protected] we would be glad to be of help.

For more information, visit Product web site at http://www.csqldb.com

Company web site at http://www.lakshyasolutions.comLAKSHYA Solutions Limited, 1st Floor, #73&74 Margosa Road, ABMGPBuilding, 17th Cross, Malleshwaram, Bangalore 560055, Karnataka, India.Call +91.80.4242.5757

Copyright @ LAKSHYA 2008The information being shared in this document is purely for technical and / or product reference. This document and anyinformation enclosed within this document contains restricted and / or limited information and you must not disseminate,modify, copy/plagiarize or take any action in reliance upon it, unless permitted to by Lakshya Solutions Limited. None ofthe material in the document can be reproduced in any form.

Guide to choose best caching strategy

Documents

Transcript of Guide to choose best caching strategy