From 70ba8ef7195faa11b420accfd493c58cdec99c7b Mon Sep 17 00:00:00 2001
From: Roy Mayan <>
Date: Sun, 15 Jun 2025 17:53:14 +0300
Subject: [PATCH] Translating - Cache

---
 README-he.md | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/README-he.md b/README-he.md
index 9beac113..a101d449 100644
--- a/README-he.md
+++ b/README-he.md
@@ -1579,8 +1579,85 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני
 
 
 
-## Cache
+## מטמון (Cache)
 
 <div dir="rtl">
 
+<p align="center">
+  <img src="images/Q6z24La.png", width="60%">
+  <br/>
+  <i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Source: Scalable system design patterns</a></i>
+</p>
+
+שמירת נתונים ב-cache משפרת את זמן טעינת הדפים, ומפחיתה את העומס על השרתים ועל ה-DBים. 
+במודל זה, השרת מחפש האם הבקשה שהגיעה כבר נעשתה בעבר, ומנסה למצוא תוצאה מוכנה, כדי לחסוך את זמן העיבוד על אותה ההודעה מחדש.
+
+מסדי נתונים לרוב מרוויחים מהתפלגות אחידה של קריאות וכתיבה על פני החלוקות שלהם (partitions). פריטים שניגשים אליהם הרבה יכולים ליצור זינוק בקריאות וכתיבה לחלוקה מסוימת וליצור צווארי-בקבוק. כאשר שמים שכבת cache לפני ה-DB, פיקים קיצוניים בתעבורה נספגים בזיכרון המהיר של המטמון ולא מעמיסים על ה-DB.
+
+### מטמון בצד לקוח
+
+מטמון יכול להיות ממוקם בצד הלקוח (מערכת ההפעלה או הדפדפן), [צד השרת](#reverse-proxy-web-server), או בשכבה נפרדת.
+
+### מטמון CDN
+
+ניתן להסתכל על [CDN](#content-delivery-network) גם בתור שכבה של מטמון.
+
+### מטמון בשרת
+
+[פרוקסי הפוך](#reverse-proxy-web-server) ומנגנוני cache כמו [Varnish](https://www.varnish-cache.org/) יכולים להנגיש תוכן סטטי ודינמי ישירות. שרתי web יכולים גם לבצע cache לבקשות כדי להחזיר תשובות בלי צורך להגיע עד לשרתי האפליקציה.
+
+### מטמון במסד נתונים
+
+ה-DB לרוב כולל רמה מסוימת של caching באופן דיפולטי, אשר מאופטמת למקרה הכללי. ביצוע כיוונון להגדרות האלה עבור תבניות שימוש ספציפיות יכול להאיץ את הביצועים.
+
+
+### מטמון באפליקציה
+
+מטמון in-memory כמו Memcached ו-Redis מהווים אחסון key-value בין האפליקציה ובין ה-DB. כיוון שהדאטא מוחזק ב-RAM, זה הרבה יותר מהיר מ-DB טיפוסי שם הדאטא נשמר על הדיסק.
+ה-RAM יותר מוגבל מהדיסק, לכן אלגוריתמים של [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) כמו [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)) עוזרים "לזרוק" את הפריטים שלא נגעו בהן זמן רב (cold) ולהשאיר את הנתונים הרלוונטיים (hot).
+
+ל-Redis יש את הפיצ'רים הבאים:
+
+<ul dir="rtl">
+  <li>אופציה פרסיסטנטית</li>
+  <li>מבני נתונים כמו sorted sets ו-lists</li>
+</ul>
+
+יש הרבה רמות שניתן לבצע בהן cache, והן מתחלקות לשתי קטגוריות עיקריות: **database queries** ו-**objects**:
+
+- Row level
+- Query-level
+- Fully-formed serializable objects
+- Fully-rendered HTML
+
+באופן כללי, עדיף להימנע מביצוע caching לקבצים, דבר המקשה על cloning - שכפול, ועל auto-scaling - הוספה או הורדה של מכונות.
+
+### מטמון ברמת שאילתה
+
+בכל פעם שמבצעים שאילתה ל-DB, נעשה hash על השאילתה בתור key, ונאחסן את התוצאה שלה ל-cache. הגישה הזאת סובלת מבעיות של תוקף:
+
+
+<ul dir="rtl">
+  <li>קשה למחוק תוצאה שמורה של שאילתה מורכבת (באילו טבלאות הוא משתמש)</li>
+  <li>שינוי קטן ב-DB מחייב מחיקה של כל השאילתות הרלוונטיות שנשמרו, התוצאות כבר לא מעודכנות</li>
+</ul>
+
+### מטמון ברמת אובייקט
+
+במקום לשמור תוצאה של שאילתה, נחשוב על הנתונים כמו על "אובייקט" בקוד. 
+האפליקציה שולפת את המידע מה-DB ומרכיבה ממנו מופע שמתאר אותו תוך שימוש ב-class כלשהו:
+
+
+<ul dir="rtl">
+  <li>יש להסיר את האובייקט מה-cache אם אחד מהשדות שלו השתנה</li>
+  <li>מאפשר עיבוד אסינכרוני: תהליכים ברקע יכולים להרכיב אובייקטים על ידי הדבר האחרון שנמצא ב-cache</li>
+</ul>
+
+הצעות לדברים שכדאי לבצע להם cache:
+
+* User sessions
+* Fully rendered web pages
+* Activity streams
+* User graph data
+
 </div>