Question

I have a application which has 200 tables – classified into 4 groups

1. Non Transactional (50 tables) – Tables like department, designation etc which are updated once a while sometime by admin (100000 reads : 1write ratio & 1write/month)

2. Less Transactional (50 tables) – tables like settings, product, tax rates which are read more and inserted very less often but write occurs everyday (1000 reads : 1 write ratio & 1 write/day)

3. Transactional (50 tables) -tables like orders, receipts etc which are written and read almost equally (10 reads : 1 write & 1 write/hr)

4. Heavy Transactional (50 tables) – tables like tasks, history etc which are written more and read less but used by services & reports (1 read : 1 writes & 1 write/minute)

I am using hibernate, struts2 & spring and looking for caching strategy to get best performance & efficiency.

If you observe i have more data in tables which are written & read most, so caching them in more critical.

Can I cache group 4 tables? If yes how ?

Can I cache group 3 tables? If yes how ?

Can I cache group 2 tables? If yes how ?

Can I cache group 1 tables? If yes how ?

Can I use in memory db for some tables?

Will view help me in some cases? Which cases?

Well what I want finally is a fast read access from in memory database, some thing that will update my in-memory database as database changes. Like say I have products list, orders list in memory but when any new product or order gets added this list must reload themselves. Typically all reads from some in-memory database while all writes to direct db with trigger to update list or list-item.

Answer 1

Lets start with the thumb rule of caching,

Cache the non-transactional data which are read frequently and change rarely.

Hibernate allows you to get there pretty safely. From this point even though still you can use caching it is not really recommended as you might run in to multiple problems with it. So it better to proceed with caution on this. Have a look at the below list of articles, it will give you more insight.

1. Hibernate: Truly Understanding the Second-Level and Query Caches
2. Understanding Caching in Hibernate – The Second Level Cache
3. Improving Hibernate’s Performance

So when we apply this rule to your scenario, Only the first set should get cached. Do that first, measure your application for performance improvement. If things are fine you can consider caching the second group also. It is not recommended to cache the transactional tables so the set 3 and 4 are ruled out.