Cache Pattern

キャッシュ・モードには、次の3つがあります.

No caching

Cache-Aside

Cache-Through

この3点を簡単にまとめたいと思います.

No Caching

これは、タイトル別にキャッシュを適用しない一般的な形式です.
アプリケーションはデータベースを直接要求し、キャッシュ履歴がないため、毎回データベースと通信する必要があります.
また、SQLが継続すると、データベースのI/Oに影響を与え、全体的なパフォーマンスが低下する可能性があります.

(出典:https://cla9.tistory.com/100)

Cache-Aside

アプリケーションはキャッシュを直接使用します.
これは、アプリケーション・コードがデータベースではなくキャッシュを最初に参照し、検索するデータがキャッシュに存在する場合、キャッシュはすぐに戻ります.
その後、同じリクエストを繰り返すと、キャッシュにデータが存在する場合、データベースをクエリーすることなく、すぐにデータを受信できます.
ただし、キャッシュ内のデータが存在しない場合、DBはデータを問合せ、キャッシュを再ロードします.

Pseudocode for reading values

v = cache.get(k)
if (v == null) {
  v = sor.get(k)
  cache.put(k, v)
}

Pseudocode for writing values

v = newV
sor.put(k, v)
cache.put(k, v)

(出典:https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)

Cache-Through

キャッシュ損失が発生すると、アプリケーションではなくキャッシュからデータが処理され、アプリケーションにデータが転送されます.
つまり、アプリケーションがデータの処理を担当する場合、キャッシュはキャッシュに委任されます.

Read-Through

アプリケーションがデータを要求するときにキャッシュ・ヒットに遭遇すると、キャッシュはデータを送信します.キャッシュがヒットしない場合、キャッシュはデータベースを問合せ、キャッシュにデータをロードします.

(出典:https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)

Write-Through

アプリケーションがデータの書き込みを要求すると、アプリケーションは書き込み要求のみをキャッシュに転送し、キャッシュ要求からデータベースにデータ書き込み要求をデータベースにロードします.

(出典:https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)

Write-Behind

アプリケーションがデータの書き込みを要求すると、データがキャッシュに反映され、キャッシュがデータベースにロードされるように非同期で要求されます.
書き込み-behindの場合、アプリケーションはデータの書き込みのパフォーマンスを向上させることができますが、キャッシュがオフになると、データが失われる可能性があります.

(出典:https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/)

リファレンス

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

https://www.ehcache.org/documentation/3.3/caching-patterns.html#cache-aside