sombochea/system-design-primer
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add Caching at the database query level vs obj level sections

Browse Source
This commit is contained in:
Donne Martin 2017-03-01 20:37:12 -08:00
parent e161b29eb1
commit 1945024e5b
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
README.md
View File

@ -1252,3 +1252,24 @@ There are multiple levels you can cache that fall into two general categories: *
* Fully-rendered HTML * Fully-rendered HTML
Generaly, you should try to avoid file-based caching, as it makes cloning and auto-scaling more difficult. Generaly, you should try to avoid file-based caching, as it makes cloning and auto-scaling more difficult.
### Caching at the database query level
Whenever you query the database, hash the query as a key and store the result to the cache. This approach suffers from expiration issues:
* Hard to delete a cached result with complex queries
* If one piece of data changes such as a table cell, you need to delete all cached queries that might include the changed cell
### Caching at the object level
See your data as an object, similar to what you do with your application code. Have your application assemble the dataset from the database into a class instance or a data structure(s):
* Remove the object from cache if its underlying data has changed
* Allows for asynchronous processing: workers assemble objects by consuming the latest cached object
Suggestions of what to cache:
* User sessions
* Fully rendered web pages
* Activity streams
* User graph data