17

My app currently connects to a RDS Multi-AZ database. I also have a Single-AZ Read Replica used to serve my analytics portal.

Recently there have been an increasing load on my master database, and I am thinking of how to resolve this situation without having to scale up my database again. The two ways I have in mind are

  1. Move all the read queries from my app to the read-replica, and just scale up the read-replica, if necessary.
  2. Implement ElastiCache Memcached.

To me these two options seem to achieve the same outcome for me - which is to reduce load on my master database, but I am thinking I may have understood some fundamentals wrongly because Google doesnt seem to return any results on a comparison between them.

chongzixin
  • 1,951
  • 4
  • 28
  • 55

1 Answers1

33

In terms of load, they have the same goal, but they differ in other areas:

Up-to-dateness of data:

  • A read replica will continuously sync from the master. So your results will probably lag 0 - 3s (depending on the load) behind the master.
  • A cache takes the query result at a specific point in time and stores it for a certain amount of time. The longer your queries are being cached, the more lag you'll have; but your master database will experience less load. It's a trade-off you'll need to choose wisely depending on your application.

Performance / query features:

  • A cache can only return results for queries it has already seen. So if you run the same queries over and over again, it's a good match. Note that queries must not contain changing parts like NOW(), but must be equal in terms of the actual data to be fetched.
  • If you have many different, frequently changing, or dynamic (NOW(),...) queries, a read replica will be a better match.
  • ElastiCache should be much faster, since it's returning values directly from RAM. However, this also limits the number of results you can store.

So you'll first need to evaluate how outdated your data can be and how cacheable your queries are. If you're using ElastiCache, you might be able to cache more than queries — like caching whole sections of a website instead of the underlying queries only, which should improve the overall load of your application.

PS: Have you tuned your indexes? If your main problems are writes that won't help. But if you are fighting reads, indexes are the #1 thing to check and they do make a huge difference.

xeraa
  • 10,456
  • 3
  • 33
  • 66
  • will research more based on your inputs, which are very valuable. thanks for pointing me towards the right direction! – chongzixin Jul 16 '14 at 11:07
  • @xeraa - which one will be cheaper for multiAZ? – Manish Jain Apr 09 '16 at 22:05
  • the prize is only determined by the instance size. with multi-AZ you need the same size on all instances, with RR they can differ – xeraa Apr 09 '16 at 22:15
  • for actual prices see https://aws.amazon.com/rds/pricing/ and https://aws.amazon.com/elasticache/pricing/ – xeraa Apr 09 '16 at 22:19
  • Does read replicas provide high availability for the application? – rinilnath Jan 15 '23 at 05:12
  • I'd start with a multi-AZ for that. While you can promote a read replica it's more of a complement (starting from the async vs sync replication mechanism) – xeraa Jan 15 '23 at 22:07