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
|
||||
|
||||
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