Add Caching at the database query level vs obj level sections
parent
e161b29eb1
commit
1945024e5b
21
README.md
21
README.md
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue