From 84d8463aa1c5f98b652bb5fe0d6700f2f3bacda1 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sat, 7 Jun 2025 14:53:52 +0300 Subject: [PATCH 01/43] Added raw hebrew README file --- README-he.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README-he.md diff --git a/README-he.md b/README-he.md new file mode 100644 index 00000000..e69de29b From bc9ebefad654e43cb2d3cd27e8fcf10d5c6f9494 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sat, 7 Jun 2025 16:16:12 +0300 Subject: [PATCH 02/43] Translating - Motivation --- README-he.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/README-he.md b/README-he.md index e69de29b..a90430ec 100644 --- a/README-he.md +++ b/README-he.md @@ -0,0 +1,51 @@ +*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)* + +**עזרו [לתרגם](TRANSLATIONS.md) את המדריך!** + +# המדריך לתכנון מערכות (The System Design Primer) + +

+ +
+

+ +## מוטיבציה + +
+ +> ללמוד איך לתכנן מערכות ב-scale גדול. +> +> להתכונן לראיונות ארכיטקטורה. + + +### ללמוד איך לתכנן מערכות ב-scale גדול + +ללמוד כיצד לתכנן מערכות סְקֵילָבִּילִיוּת יסייע לך להפוך למהנדס תוכנה טוב יותר. + +תכנון מערכות הוא נושא רחב. יש **כמות אדירה של משאבים ברחבי הרשת** על עקרונות של תכנון מערכות. + +ה-repo הזה הוא **אוסף מסודר** של משאבים שנועדו לעזור לך ללמוד איך לבנות מערכות ב-scale. + +### ללמוד מקהילת הקוד הפתוח + +מדובר בפרויקט קוד פתוח (open source) שמתעדכן באופן מתמשך. + +מוזמנים [לתרום!](#contributing) + +### להתכונן לראיונות ארכיטקטורה + +בנוסף לראיונות קידוד, ארכיטקטורה היא **רכיב נדרש** כחלק מתהליך **ראיונות טכניים** בהרבה חברות טכנולוגיות. + +**תוכל לתרגל שאלות ארכיטקטורה נפוצות** ואף **להשוות** את התוצאות שלך עם **פתרונות לדוגמה**: דיונים, קוד, ודיאגרמות. + +### נושאים נוספים להכנה לראיונות: + + + +
From e0a6ce9a815c3df97f10750b1d695f36bc1a145c Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sat, 7 Jun 2025 20:22:53 +0300 Subject: [PATCH 03/43] Translating - Anki flashcards --- README-he.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/README-he.md b/README-he.md index a90430ec..f8d4867f 100644 --- a/README-he.md +++ b/README-he.md @@ -49,3 +49,39 @@ + +## כרטיסיות Anki + +
+ +

+ +
+

+ +החבילות המוכנות של כרטיסיות [Anki](https://apps.ankiweb.net/) משתמשות בשיטת **חזרתיות מבוססת מרווחים (Spaced Repetition)** כדי לעזור לך לזכור מושגים חשובים בתכנון מערכות. + + + +מומלצות לשימוש בדרכים. + +### משאב לראיונות קידוד: אתגרי קידוד אינטראקטיביים + +מחפש משאבים שיעזרו לך להתכונן [**לראיונות קידוד**](https://github.com/donnemartin/interactive-coding-challenges)? + +

+ +
+

+ +תעיף מבט על ה-repo המקביל [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges), שמכיל חבילת Anki נוספת: + + + +
From 2404f072ca71db8d5f264c4926f954715b378288 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 12:53:00 +0300 Subject: [PATCH 04/43] Translating - Contributing --- README-he.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/README-he.md b/README-he.md index f8d4867f..09ed3e4f 100644 --- a/README-he.md +++ b/README-he.md @@ -85,3 +85,24 @@ + +## תרומה למדריך + +
+ +> ללמוד מהקהילה. + +אל תהסס להגיש pull requests כדי לעזור: + + + +תכנים שעדיין דורשים ליטוש מסומנים בתור תחת פיתוח. + +מומלץ לעיין בהנחיות לתרומה לפני התחלה. + +
From 56240af73ceb48e42dbccbf8d4c49379fe77b40c Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 17:50:46 +0300 Subject: [PATCH 05/43] Translating - Index of system design topics --- README-he.md | 152 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 152 insertions(+) diff --git a/README-he.md b/README-he.md index 09ed3e4f..bf5ca424 100644 --- a/README-he.md +++ b/README-he.md @@ -106,3 +106,155 @@ מומלץ לעיין בהנחיות לתרומה לפני התחלה. + +## אינדקס נושאים בתכנון מערכות + +
+ +> סיכומים של נושאים שונים בתכנון מערכות, כולל יתרונות וחסרונות. **כל החלטה כוללת פשרות (trade-offs)**. +> +> כל חלק מכיל קישורים להרחבה וללמידה מעמיקה יותר. + +

+ +
+

+ + + +
+ + From 9e6f1f4a1445c5544a8a5b75fa154056d14c7e76 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 17:59:58 +0300 Subject: [PATCH 06/43] Trying to fix rtl in list --- README-he.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/README-he.md b/README-he.md index bf5ca424..d4fad973 100644 --- a/README-he.md +++ b/README-he.md @@ -134,8 +134,8 @@ @@ -206,19 +206,19 @@
  • מטמון (Cache) @@ -232,10 +232,10 @@
  • תקשורת
  • אבטחה
    • From 3b761c568a519a51e1ae2e3b3d840b16d0a5c219 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 18:18:27 +0300 Subject: [PATCH 07/43] Translating - Study guide --- README-he.md | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) diff --git a/README-he.md b/README-he.md index d4fad973..880fcf7d 100644 --- a/README-he.md +++ b/README-he.md @@ -257,4 +257,92 @@ +## מדריך למידה +
    + +> נושאים מוצעים ללימוד לפי לוח הזמנים לריאיון שלך (קצר, בינוני, ארוך) + +![Imgur](images/OfVllex.png) + +**ש: עבור הראיונות, האם אני אמור לדעת כל מה שכתוב כאן?** + +**ת: לא, אתה לא צריך לדעת הכול כדי להתכונן לריאיון**. + +מה שאתה תישאל עליו בריאיון תלוי בדברים כגון: + + + +לרוב מצופה ממועמדים מנוסים יותר לדעת יותר על ארכיטקטורה ותכנון מערכות. ארכיטקטים או ראשי צוותים מצופים לדעת יותר מאשר עובדים בודדים. חברות טכנולוגיות מובילות לרוב יערכו ריאיון אחד או יותר של ארכיטקטורה. + +רצוי להתחיל רחב ולהעמיק במספר תחומים. זה עוזר לדעת קצת בנוגע למספר נושאי מפתח בתכנון מערכות. תתאים את המדריך לפי לוח הזמן שלך, הניסיון, המשרות שאתה מתראיין אליהן, והחברות שבהן אתה מתראיין. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    קצרבינוניארוך
    קרא את הנושאים בתכנון מערכות כדי לקבל הבנה כללית של איך מערכות עובדות:+1::+1::+1:
    קרא כמה מאמרים מתוך בלוגים של חברות שאתה מתראיין אליהן:+1::+1::+1:
    קרא על כמה ארכיטקטורות מהעולם האמיתי:+1::+1::+1:
    חזור על איך לגשת לשאלת ריאיון בתכנון מערכות:+1::+1::+1:
    תרגל שאלות ריאיון בתכנון מערכות עם פתרונותכמההרבהרוב
    תרגל שאלות ריאיון בתכנון מונחה עצמים עם פתרונותכמההרבהרוב
    חזור על שאלות ריאיון נוספות בתכנון מערכותכמההרבהרוב
    + +
    From 030f375d8b580f509116a01ba7cf4de2eb5580bd Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 18:21:17 +0300 Subject: [PATCH 08/43] Inserted index list into expandable details --- README-he.md | 253 ++++++++++++++++++++++++++------------------------- 1 file changed, 128 insertions(+), 125 deletions(-) diff --git a/README-he.md b/README-he.md index 880fcf7d..c9b95ba0 100644 --- a/README-he.md +++ b/README-he.md @@ -120,140 +120,143 @@

    - - From 29a4300f4219e6f8077bef5bb32b10d164fcd15b Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 19:18:56 +0300 Subject: [PATCH 12/43] Translating - Added first interview question --- README-he.md | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/README-he.md b/README-he.md index da245470..e935b00c 100644 --- a/README-he.md +++ b/README-he.md @@ -352,7 +352,7 @@ -## איך לגשת לשאלת ראיון ארכיטקטורה +## איך לגשת לשאלת ריאיון ארכיטקטורה
    @@ -435,3 +435,70 @@ * [System design template](https://leetcode.com/discuss/career/229177/My-System-Design-Template)
    + + +## שאלות ריאיון תכנון מערכות עם פתרונות + +
    + +> שאלות נפוצות בריאיון ארכיטקטורה עם הסברים פשוטים, קוד, ודיאגרמות. +> +> הפתרונות מפנים לתוכן שנמצא בתיקיית `solutions/`. + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    שאלהפתרון
    תכנן את Pastebin.com (או Bit.ly)פתרון
    תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק)פתרון
    תכנן סורק רשת (web crawler)פתרון
    תכנן את Mint.comפתרון
    תכנן את מבני הנתונים של רשת חברתיתפתרון
    תכנן אחסון key-value למנוע חיפושפתרון
    תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזוןפתרון
    תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWSפתרון
    הוסף שאלה לתכנון מערכתתרום
    + +### תכנן את Pastebin.com (או Bit.ly) + +[צפה בתרגיל ובפתרון](solutions/system_design/pastebin/README.md) + +

    + +
    +

    + + From 19be8b4e86728ced24070d247dc1d95107851631 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 19:22:47 +0300 Subject: [PATCH 13/43] Translating - System design interview questions with solutions --- README-he.md | 97 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 92 insertions(+), 5 deletions(-) diff --git a/README-he.md b/README-he.md index e935b00c..4f85e351 100644 --- a/README-he.md +++ b/README-he.md @@ -462,7 +462,7 @@ פתרון - תכנן סורק רשת (web crawler) + תכנן web crawler פתרון @@ -496,9 +496,96 @@ [צפה בתרגיל ובפתרון](solutions/system_design/pastebin/README.md) -

    - -
    -

    +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק) + +[צפה בתרגיל ובפתרון](solutions/system_design/twitter/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן web crawler + +[צפה בתרגיל ובפתרון](solutions/system_design/web_crawler/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן את Mint.com + +[צפה בתרגיל ובפתרון](solutions/system_design/mint/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן את מבני הנתונים של רשת חברתית + +[צפה בתרגיל ובפתרון](solutions/system_design/social_graph/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן אחסון key-value למנוע חיפוש + +[צפה בתרגיל ובפתרון](solutions/system_design/query_cache/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון + +[צפה בתרגיל ובפתרון](solutions/system_design/sales_rank/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    + +### תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS + +[צפה בתרגיל ובפתרון](solutions/system_design/scaling_aws/README.md) + +
    + הצג/הסתר דיאגרמה +

    + +
    +

    +
    From ab79c252698693f61f7d7ce283b7027b6b665e52 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 19:39:14 +0300 Subject: [PATCH 14/43] Pictures smaller --- README-he.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README-he.md b/README-he.md index 4f85e351..aac18966 100644 --- a/README-he.md +++ b/README-he.md @@ -499,7 +499,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -511,7 +511,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -523,7 +523,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -535,7 +535,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -547,7 +547,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -559,7 +559,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -571,7 +571,7 @@
    הצג/הסתר דיאגרמה

    - +

    @@ -583,7 +583,7 @@
    הצג/הסתר דיאגרמה

    - +

    From 2442bc411cbe3adc871d09e84d5708649aba0888 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 19:47:35 +0300 Subject: [PATCH 15/43] Translating - Object-oriented design interview questions with solutions --- README-he.md | 63 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 60 insertions(+), 3 deletions(-) diff --git a/README-he.md b/README-he.md index aac18966..cb9c1d9b 100644 --- a/README-he.md +++ b/README-he.md @@ -441,7 +441,7 @@
    -> שאלות נפוצות בריאיון ארכיטקטורה עם הסברים פשוטים, קוד, ודיאגרמות. +> שאלות נפוצות בריאיון ארכיטקטורה עם הסברים לדוגמה, קוד, ודיאגרמות. > > הפתרונות מפנים לתוכן שנמצא בתיקיית `solutions/`. @@ -454,7 +454,7 @@ - תכנן את Pastebin.com (או Bit.ly) + תכנן את pastebin.com (או bit.ly) פתרון @@ -492,7 +492,7 @@ -### תכנן את Pastebin.com (או Bit.ly) +### תכנן את pastebin.com (או bit.ly) [צפה בתרגיל ובפתרון](solutions/system_design/pastebin/README.md) @@ -589,3 +589,60 @@
    + + +## שאלות ריאיון בתכנון מונחה עצמים עם פתרונות + +
    + +> שאלות נפוצות בתכנון מונחה עצמים עם הסברים לדוגמה, קוד, ודיאגרמות. +> +> הפתרונות מפנים לתוכן שנמצא בתיקיית `solutions/`. + +>**הערה: החלק הזה עדיין בפיתוח** + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    שאלהפתרון
    תכנן Hash Mapפתרון
    תכנן מנגנון Cache בשיטת Least Recently Usedפתרון
    תכנן מרכז שירות טלפוני (Call Center)פתרון
    תכנן חפיסת קלפיםפתרון
    תכנן חניוןפתרון
    תכנן שרת צ'אטפתרון
    תכנן מערך מעגליתרום
    הוסף שאלה בעיצוב מונחה עצמיםתרום
    + +
    From 7987c20d03c1b8cfa5be94aae07f119c38ed22e7 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 21:25:16 +0300 Subject: [PATCH 16/43] Translating - System design topics: start here --- README-he.md | 71 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 59 insertions(+), 12 deletions(-) diff --git a/README-he.md b/README-he.md index cb9c1d9b..37067b2e 100644 --- a/README-he.md +++ b/README-he.md @@ -55,7 +55,7 @@

    - +

    @@ -74,7 +74,7 @@ מחפש משאבים שיעזרו לך להתכונן [**לראיונות קידוד**](https://github.com/donnemartin/interactive-coding-challenges)?

    - +

    @@ -367,21 +367,25 @@ אסוף דרישות והגדר את ה-scope של הבעיה. שאל שאלות כדי להבהיר את מקרי השימוש והאילוצים. דון בהנחות העבודה שאתה עושה. -* מי הולך להשתמש במערכת? -* איך הם הולכים להשתמש בה? -* כמה משתמשים יהיו? -* מה המערכת עושה? -* מה הקלטים והפלטים של המערכת? -* בכמה דאטא נצטרך לטפל? -* כמה בקשות לשניה מחכות לנו? -* מה היחס הצפוי בין קריאה לכתיבה? + ### שלב 2: כתוב תכנון במבט על (high level design) כתוב תכנון high level עם כל הרכיבים החשובים. -* שרטט את הרכיבים החשובים והקשרים ביניהם -* תצדיק את הרעיונות שלך + ### שלב 3: תכנן את הרכיבים המרכזיים @@ -646,3 +650,46 @@
    + +## נושאים בתכנון מערכות: התחל כאן + +
    + +חדש בתחום תכנון מערכות? + +ראשית, תצטרך לקבל הבנה בסיסית של העקרונות הנפוצים, ללמוד מה הם, איך משתמשים בהם, מה היתרונות והחסרונות של כל אחד מהם. + +### שלב 1: צפה בהרצאה על סקילביליות + +[Scalability Lecture at Harvard](https://www.youtube.com/watch?v=-W9F__D3oY4) + +* Topics covered: + * Vertical scaling + * Horizontal scaling + * Caching + * Load balancing + * Database replication + * Database partitioning + +### שלב 2: קרא מאמר על סקילביליות + +[Scalability](https://web.archive.org/web/20221030091841/http://www.lecloud.net/tagged/scalability/chrono) + +* Topics covered: + * [Clones](https://web.archive.org/web/20220530193911/https://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones) + * [Databases](https://web.archive.org/web/20220602114024/https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database) + * [Caches](https://web.archive.org/web/20230126233752/https://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache) + * [Asynchronism](https://web.archive.org/web/20220926171507/https://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism) + +### השלבים הבאים + +בהמשך, נסתכל על trade-offs ב-high level: + +* **Performance** vs **scalability** +* **Latency** vs **throughput** +* **Availability** vs **consistency** + +נזכור כי **הכול זה trade-off**. +לאחר מכן נצלול לנושאים ספציפיים יותר כמו DNS, CDN ו-load balancers. + +
    From 4abfe15cbda209924df338607293fbc12141d9dc Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 21:54:55 +0300 Subject: [PATCH 17/43] Translating - Trade-offs --- README-he.md | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/README-he.md b/README-he.md index 37067b2e..9235db4f 100644 --- a/README-he.md +++ b/README-he.md @@ -693,3 +693,80 @@ לאחר מכן נצלול לנושאים ספציפיים יותר כמו DNS, CDN ו-load balancers. + + +## ביצועים (performance) מול סקילביליות (scalability) + +
    + +שירות הוא **סקילבילי (scalable)** אם הוא משתפר **בביצועים (performance)** שלו באופן פרופורציונלי למשאבים שנוספו. באופן כללי, שיפור בביצועים פירושו היכולת לתת שירות ליותר יחידות עבודה, אך הוא יכול גם לבוא לידי ביטוי ביכולת להתמודד עם יחידות עבודה גדולות יותר, ככל שהדאטא גדל.1 + +דרך נוספת להסתכל על ביצועים מול סקילביליות + + + +### מקורות וקריאה נוספת + +* [A word on scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html) +* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) + +
    + +## שיהוי (latency) מול תפוקה (throughput) + +
    + +**שיהוי** הוא הזמן שנדרש כדי לבצע פעולה כלשהי או להפיק תוצאה כלשהי + +**תפוקה** היא מספר הפעולות או התוצאות ליחידת זמן. + +באופן כללי, כדאי לשאוף **לתפוקה מקסימלית** עם **שיהוי סביר**. + +### חומרים וקריאה נוספת + +* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput) + +
    + +## זמינות (availability) מול עקביות (consistency) + +
    + +### משפט CAP + +

    + +
    + Source: CAP theorem revisited +

    + +במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים: + + + +*ניתן לצאת מנקודת הנחה שרשתות לא אמינות - כך שנהיה חייבים לתמוך ב-״Partition tolerance״. +לכן, נצטרך לבחור אחד משני האחרים - זמינות או עקביות.* + +#### בחירה ב-CP - עקביות ויכולת חלוקה + +המתנה לתשובה מהמערכת (אשר סובלת מ-network partition) עלולה להסתיים בשגיאת timeout. לכן, CP הוא בחירה טובה במידה ויש הצדקה עסקית לקריאות וכתיבות אטומיות. + +#### בחירה ב-AP - זמינות ויכולת חלוקה + +תשובות לבקשות מהמערכת מחזירות את הגרסה הזמינה ביותר של הנתונים הזמינים בשרת הרלוונטי, שאינה בהכרח האחרונה. כתיבה עשויה לקחת זמן מסוים עד שתסתיים, עד אשר התקשורת הבעייתית תיפתר. + +לכן, AP הוא בחירה טובה במידה ויש הצדקה עסקית לעבוד במצב של [eventual consistency](#eventual-consistency) או במידה והמערכת צריכה להמשיך לשרת למרות שגיאות בלתי-תלויות. + +### חומרים וקריאה נוספת + +* [CAP theorem revisited](http://robertgreiner.com/2014/08/cap-theorem-revisited/) +* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem) +* [CAP FAQ](https://github.com/henryr/cap-faq) +* [The CAP theorem](https://www.youtube.com/watch?v=k-Yaq8AHlFA) From 649a69d5540b397ee3b1a5cde850311c3bf89d48 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 8 Jun 2025 21:55:53 +0300 Subject: [PATCH 18/43] Updated size --- README-he.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-he.md b/README-he.md index 9235db4f..8f5d1369 100644 --- a/README-he.md +++ b/README-he.md @@ -738,7 +738,7 @@ ### משפט CAP

    - +
    Source: CAP theorem revisited

    From e805e7b782e6d1484278bb1b4550cbd6e0d50080 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Mon, 9 Jun 2025 20:54:44 +0300 Subject: [PATCH 19/43] Translating - Consistency and Availability Patterns --- README-he.md | 140 ++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 133 insertions(+), 7 deletions(-) diff --git a/README-he.md b/README-he.md index 8f5d1369..5862cbbf 100644 --- a/README-he.md +++ b/README-he.md @@ -695,7 +695,7 @@
    -## ביצועים (performance) מול סקילביליות (scalability) +## ביצועים (Performance) מול סקילביליות (Scalability)
    @@ -715,7 +715,7 @@
    -## שיהוי (latency) מול תפוקה (throughput) +## שיהוי (Latency) מול תפוקה (Throughput)
    @@ -731,7 +731,7 @@
    -## זמינות (availability) מול עקביות (consistency) +## זמינות (Availability) מול עקביות (Consistency)
    @@ -746,10 +746,10 @@ במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים: +
  • עקביות (Consistency) – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.
    • +
  • זמינות (Availability) - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.
    • +
  • יכולת חלוקה (Partition Tolerance) - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.
    • + *ניתן לצאת מנקודת הנחה שרשתות לא אמינות - כך שנהיה חייבים לתמוך ב-״Partition tolerance״. לכן, נצטרך לבחור אחד משני האחרים - זמינות או עקביות.* @@ -770,3 +770,129 @@ * [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem) * [CAP FAQ](https://github.com/henryr/cap-faq) * [The CAP theorem](https://www.youtube.com/watch?v=k-Yaq8AHlFA) + +
    + + +## דפוסי עקביות (Consistency Patterns) + +
    + +כאשר קיימים מספר עותקים של אותם נתונים, עלינו להחליט כיצד לסנכרן ביניהם כדי שלקוחות יקבלו תצוגה עקבית של המידע. +ניזכר בהגדרה של עקביות מתוך [משפט CAP](#cap-theorem): כל קריאה מקבלת את הכתיבה העדכנית ביותר או שגיאה. + +### עקביות חלשה (Weak Consistency) + +לאחר כתיבה, קריאות עשויות לראות או לא לראות את הערך החדש שנכתב. הגישה כאן היא של best effort - המאמץ הטוב ביותר. + +גישה זו נפוצה במערכות כמו memcached. עקביות חלשה מתאימה למקרים של מערכות זמן-אמת, כמו VoIP, שיחות וידאו, ומשחקים מרובי משתתפים. +לדוגמה, אם אתה בשיחת טלפון ומאבד קליטה לכמה שניות, כשאתה חוזר אתה לא שומע מה שנאמר בזמן שלא הייתה קליטה. + +### עקביות לא מיידית (Eventual Consistency) + +לאחר כתיבה, הקריאות יראו בסופו של דבר את מה שנכתב (בדרך כלל תוך מספר מילישניות). הנתונים משוכפלים באופן אסינכרוני. + +גישה זו נפוצה במערכות כמו DNS ומייל. עקביות לא מיידית מתאימה למערכות ששומרות על זמינות גבוהה במיוחד. + +### עקביות חזקה (Strong Consistency) + +לאחר כתיבה, הקריאות יראו תמיד את הערך החדש שנכתב. השכפול מתבצע באופן סינכרוני. + +גישה זו נפוצה במערכות קבצים ובמסדי נתונים רלציוניים (RDBMS). עקביות חזקה מתאימה למערכות שדורשות טרנזקציות. + +### מקורות וקריאה נוספת + +- [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html) + +
    + +## דפוסי זמינות (Availability Patterns) + +
    + +קיימים שני דפוסים משלימים לתמיכה בזמינות גבוהה: **מעבר אוטומטי (fail-over)** ו-**שכפול (replication)**. + +### גיבוי בזמן כישלון (Fail-Over) + +#### אקטיבי-פסיבי (Active-Passive) + +במבנה אקטיבי-פסיבי, נשלחים heartbeat-ים בין השרת הפעיל לשרת הרזרבי (הפסיבי). אם ה-heartbeat נקטע, השרת הפסיבי לוקח את כתובת ה-IP של הפעיל וממשיך את השירות. + +משך זמן ההשבתה תלוי אם השרת הפסיבי פועל מראש במצב 'חם' (hot standby), או שיש להפעילו ממצב 'קר' (cold standby). רק השרת הפעיל מקבל תעבורה. + +סוג זה נקרא גם Master-Slave. + +#### אקטיבי-אקטיבי (Active-Active) + +במבנה אקטיבי-אקטיבי, שני השרתים מקבלים תעבורה ומחלקים ביניהם את העומס. + +אם השרתים חשופים פומבית, שרת ה-DNS צריך לדעת על כתובות ה-IP הציבוריות של שניהם. אם השרתים פנימיים, על לוגיקת האפליקציה להכיר את שניהם. + +סוג זה נקרא גם Master-Master. + +### חסרונות של מעבר אוטומטי + + + +### שכפול (Replication) + +#### עבור Master-Slave/Master-Master + +נושא זה נדון בפירוט נוסף בחלק על [מסדי נתונים](#database): + +- [Master-slave replication](#master-slave-replication) +- [Master-master replication](#master-master-replication) + +### זמינות במספרים + +נהוג למדוד זמינות לפי זמן פעילות (uptime) או חוסר פעילות (downtime)כאחוז מהזמן שבו השירות פועל. המדד הנפוץ הוא לפי מספר התשיעיות — לדוגמה: שירות עם זמינות של 99.99% מתואר כבעל ארבע תשיעיות. + +#### זמינות של 99.9% — שלוש תשיעיות + +| Duration | Acceptable downtime| +|---------------------|--------------------| +| Downtime per year | 8h 45min 57s | +| Downtime per month | 43m 49.7s | +| Downtime per week | 10m 4.8s | +| Downtime per day | 1m 26.4s | + +#### זמינות של 99.99% — ארבע תשיעיות + +| Duration | Acceptable downtime| +|---------------------|--------------------| +| Downtime per year | 52min 35.7s | +| Downtime per month | 4m 23s | +| Downtime per week | 1m 5s | +| Downtime per day | 8.6s | + +#### זמינות במקביל לעומת בטור + +אם שירות מורכב ממספר רכיבים שעלולים להיכשל, הזמינות הכוללת של השירות תלויה באופן שבו הם מסודרים - בטור או במקביל. + +###### בטור + +כאשר שני רכיבים עם זמינות קטנה מ-100% מסודרים בטור, הזמינות הכוללת יורדת: + +``` +Availability (Total) = Availability (Foo) * Availability (Bar) +``` + +אם גם `Foo` וגם `Bar` זמינים ברמה של 99.9%, הזמינות הכוללת שלהם בטור תהיה 99.8%. + +###### במקביל + +הזמינות הכוללת עולה כאשר שני רכיבים בעלי זמינות קטנה מ־100% פועלים במקביל: + +``` +Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar)) +``` + +אם גם `Foo` וגם `Bar` זמינים ברמה של 99.9%, הזמינות הכוללת שלהם במקביל תהיה 99.9999%. + +
    + + + From 0d2c89e9cb2c28673a81657b9af2fd15b4f5e08a Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Mon, 9 Jun 2025 21:02:09 +0300 Subject: [PATCH 20/43] Updated links --- README-he.md | 45 ++++++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 21 deletions(-) diff --git a/README-he.md b/README-he.md index 5862cbbf..9474f3be 100644 --- a/README-he.md +++ b/README-he.md @@ -123,37 +123,37 @@
    אינדקס נושאים -
  • מערכת שמות דומיינים (DNS)
    • -
  • רשתות הפצת תוכן (CDN) +
  • מערכת שמות דומיינים (DNS)
    • +
  • רשתות הפצת תוכן (CDN)
    • -
  • מאזן עומסים (load balancer) +
  • מאזן עומסים (load balancer)
  • פרוקסי 'הפוך' (Reverse Proxy) @@ -899,7 +899,7 @@ Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))

    - +
    מקור: מצגת אבטחת DNS

    @@ -948,7 +948,7 @@ Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))

    - +
    מקור: Why use a CDN

    @@ -1000,7 +1000,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת

    - +
    Source: Scalable system design patterns

    From 40069a9bba14e675c98c0231ea053555ec36ca0e Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Wed, 11 Jun 2025 09:55:21 +0300 Subject: [PATCH 25/43] Translating - Reverse Proxy --- README-he.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/README-he.md b/README-he.md index e435b85d..e902c68c 100644 --- a/README-he.md +++ b/README-he.md @@ -172,7 +172,7 @@
  • גדילה אופקית (horizontal)
    • -
  • פרוקסי 'הפוך' (Reverse Proxy) +
  • פרוקסי הפוך (Reverse Proxy) @@ -1093,3 +1093,56 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת - [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html) + +## פרוקסי הפוך (Reverse Proxy) + +
    + +פרוקסי הפוך הוא שרת אינטרנט המרכז שירותים פנימיים ומספק ממשק אחיד החוצה. בקשות שמגיעות מלקוחות מועברות לשרת ה-backend המסוגל לטפל בהן, ולאחר מכן הפרוקסי מחזיר ללקוח את תגובת השרת. + +יתרונות הכלולים בצורה זו: + +
      +
    • אבטחה מוגברת – הסתרת מידע על שרתי ה-backend, חסימת כתובות IP, הגבלת מספר חיבורים לכל לקוח
      • +
    • גמישות וסקילביליות מוגברת – הלקוחות רואים רק את כתובת ה-IP של הפרוקסי, מה שמאפשר להגדיל/לשנות שרתים בלי להשפיע על הלקוחות
      • +
    • SSL Termination – טכניקת אבטחה שבה מפענחים בקשות נכנסות לפני שהן מגיעות לשרת הקצה, ומצפינים את התשובות של השרת כך ששרתי ה-backend לא צריכים לבצע את הפעולות היקרות הללו. +
        +
      • מוריד את הצורך להתקין תעודות X.509 על כל שרת. +
        • +
      +
      • +
    • דחיסה – דחיסת תגובות השרת
      • +
    • מטמון – החזרת תגובות עבור בקשות שמורות (cached)
      • +
    • תוכן סטטי – הנגשת קבצים סטטיים ישירות +
        +
      • HTML/CSS/JS
        • +
      • תמונות
        • +
      • סרטונים
        • +
      • וכד׳
        • +
      +
      • +
    + +### מאזן עומסים לעומת פרוקסי הפוך + +
      +
    • פריסת מאזן עומסים שימושית כשקיימים מספר שרתים. לרוב הוא מנתב תעבורה לקבוצת שרתים המבצעים אותה לוגיקה.
      • +
    • פרוקסי הפוך מועיל גם כאשר יש רק שרת אינטרנט/אפליקציה אחד – ומעניק את כל היתרונות שפורטו לעיל.
      • +
    • פתרונות כמו NGINX ו-HAProxy תומכים גם בפרוקסי הפוך בשכבה 7 וגם באיזון עומסים.
      • +
    + +### חסרונות: פרוקסי הפוך + +
      +
    • הכנסת פרוקסי הפוך מוסיפה מורכבות לארכיטקטורה.
      • +
    • פרוקסי הפוך יחיד הוא SPOF. הגדרת כמה כאלו להפחתת סיכון (Fail-over) מוסיפה מורכבות נוספת.
      • +
    + +### מקורות וקריאה נוספת + +- [Reverse proxy vs load balancer](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/) +- [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/) +- [HAProxy architecture guide](http://www.haproxy.org/download/1.2/doc/architecture.txt) +- [Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy) + +
    From a9e62485f00252c7e594c3ae1da378b4e9929ea4 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Wed, 11 Jun 2025 09:56:06 +0300 Subject: [PATCH 26/43] Fixed rtl --- README-he.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/README-he.md b/README-he.md index e902c68c..3716c641 100644 --- a/README-he.md +++ b/README-he.md @@ -1114,11 +1114,10 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת
  • דחיסה – דחיסת תגובות השרת
  • מטמון – החזרת תגובות עבור בקשות שמורות (cached)
  • תוכן סטטי – הנגשת קבצים סטטיים ישירות - From a8529b508b712aba6f75f9f2475295d54a70a923 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Wed, 11 Jun 2025 09:56:51 +0300 Subject: [PATCH 27/43] Smaller pics --- README-he.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README-he.md b/README-he.md index 3716c641..73a0249d 100644 --- a/README-he.md +++ b/README-he.md @@ -899,7 +899,7 @@ Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))

    - +
    מקור: מצגת אבטחת DNS

    @@ -948,7 +948,7 @@ Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))

    - +
    מקור: Why use a CDN

    @@ -1000,7 +1000,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת

    - +
    Source: Scalable system design patterns

    From 8f17bb0f17922e1d4c09ec2762f6e7ab3e0c272b Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sat, 14 Jun 2025 17:00:45 +0300 Subject: [PATCH 28/43] Translating - Application --- README-he.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/README-he.md b/README-he.md index 73a0249d..74db2ce1 100644 --- a/README-he.md +++ b/README-he.md @@ -1145,3 +1145,45 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת - [Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy)
    + + +## שכבת האפליקציה + +
    + +הפרדת שכבת הרשת משכבת האפליקציה (ידועה גם כשכבת ה-platform), מאפשרת לבצע scaling ולקנפג את שתי השכבות באופן בלתי תלוי. הוספת API חדש גוררת הוספתי שרתי אפליקציה, מבלי להוסיף בהכרח גם שרתי המטפלים בלוגיקת הרשת. + +עקרון האחריות היחידה (**single respoinsibility principle**) מעודד סרביסים עצמאיים וקטנים שעובדים יחד. צוותים קטנים המטפלים שירותים קטנים יכלוים להתכוונן בצורה מיטבית לגדילה מהירה. + + Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוניות](#asynchronism). + +### מיקרו-סרביסים (Microservices) + +במונח [Microservices](https://he.wikipedia.org/wiki/מיקרו-שירותים) הכוונה למערך של שירותים קטנים, מודולריים, הניתנים לפריסה עצמאית. כל שירות רץ כתהליך נפרד ומתקשר באמצעות מנגנון פשוט ומוגדר היטב כדי להשיג יעד עסקי.1 + +לדוגמה, ב-Pinterest יכולים להיות המיקרו-סרביסים הבאים: פרופיל משתמש, עוקבים, פיד, חיפוש, העלאת תמונה וכו'. + +### גילוי סרביסים (Service Discovery) + +מערכות כמו [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcddocs/latest), ו-[Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) מסייעות לשירותים “למצוא” זה את זה על ידי ניהול ומעקב אחר שמות הסרביסים, כתובות IP, ופורטים. +בדיקות דופק ([Health checks](https://www.consul.io/intro/getting-started/checks.html)) — מאמתות את תקינות השירות, לעיתים קרובות באמצעות endpoint HTTP. +גם Consul וגם Etcd כוללים +[אחסון key-value](#key-value-store) מובנה, השימושי לאחסון קונפיגורציה ונתונים משותפים. + +### חסרונות: שכבת האפליקציה + +
      +
    • הוספת שכבת אפליקציה עם סרביסים שהקשר ביניהם רופף (loosely coupled) דורשת גישה שונה בארכיטקטורה, תפעול ותהליכי פיתוח (לעומת מערכת מונוליטית).
      • +
    • מיקרו-סרביסים עלולים להוסיף מורכבות מבחינת פריסות ותפעול.
      • +
    + +### מקורות וקריאה נוספת +- [Intro to architecting systems for scale](http://lethain.com/introduction-to-architecting-systems-for-scale) +- [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) +- [Service oriented architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture) +- [Introduction to Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) +- [Here's what you need to know about building microservices](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/) + +
    + + From 9b073c6c4140bb184e34120382e1e0166fff8f0b Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sat, 14 Jun 2025 21:08:27 +0300 Subject: [PATCH 29/43] Translating - DB/RDBMS --- README-he.md | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) diff --git a/README-he.md b/README-he.md index 74db2ce1..eb80fc14 100644 --- a/README-he.md +++ b/README-he.md @@ -1186,4 +1186,231 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת
    +## מסדי נתונים (DB) +
    + +

    + +
    + Source: Scaling up to your first 10 million users +

    + +### מסדי נתונים רלציוניים (RDBMS) + +מסד נתונים רלציוני כמו SQL הוא אוסף פריטי מידע המאורגנים בטבלאות. **ACID** הוא סט מאפיינים של [טרנזקציות](https://he.wikipedia.org/wiki/טרנזקציה_(בסיס_נתונים)) במסדי נתונים רלציוניים: + +
      +
    • Atomicity – כל טרנזקציה מתבצעת בשלמותה או שלא מתבצעת כלל (all or nothing).
      • +
    • Consistency – טרנזקציה מעבירה את ה-DB ממצב תקין אחד למצב תקין אחר.
      • +
    • Isolation – הרצה במקביל של טרנזקציות שקולה להרצה סדרתית שלהן.
      • +
    • Durability – לאחר שטרנזקציה הסתיימה, היא תישאר קבועה גם בקריסת מערכת.
      • +
    + +ישנן טכניקות רבות להגדלת (scaling) מסד נתונים רלציוני: +שכפול Master-Slave, שכפול Master-Master, פדרציה (Federation), חלוקה (Sharding), דה-נורמליזציה (Denormalization), ו-SQL Tuning. + +--- + +#### שכפול Master-Slave + +ה-master משרת קריאות וכתיבות (RW), ומשכפל את הכתיבות ל-slave אחד או יותר שמשרת רק קריאות (R). ה-slaves יכול לשכפל את הדאטא ל-slaves נוספים במבנה של מעין עץ. +אם ה-master נופל, המערכת יכולה להמשיך לרוץ במצב read-only עד שאחד ה-slaves מקודם להיות master, או שמקצים master חדש. + +

    + +
    + Source: Scalability, availability, stability, patterns +

    + + +##### חסרונות: Master-Slave + +
      +
    • נדרשת לוגיקה לקידום slave ל-master.
      • +
    • ראה חסרונות: replication – רלוונטי גם ל-Master-Slave וגם ל-Master-Master.
      • +
    + +--- + +#### שכפול Master-Master + +שני ה-masters משרתים קריאה וכתיבה (RW) ומתאמים אחד עם השני את הכתיבות. אם אחד מהם נופל, המערכת יכולה להמשיך לתפקד במצב של קריאה וכתיבה. + +

    + +
    + Source: Scalability, availability, stability, patterns +

    + +##### חסרונות: Master-Master + +
      +
    • נדרש מאזן עומסים או שינוי לוגיקת האפליקציה כדי להחליט לאן לכתוב.
      • +
    • רוב מערכות ה-Master-Master מפרות עקרון של עקביות (לכן מפרות ACID) או סובלות מאיטיות כתיבה עקב הצורך לבצע סנכרון.
      • +
    • ככל שמתרבים שרתים שמאפשרים כתיבה וה-latency גדל, יש צורך להכריע יותר מקרים של conflict.
      • +
    • ראה חסרונות: replication.
      • +
    + +##### חסרונות: Replication (כללי) + +
      +
    • סכנת אובדן נתונים אם ה-master נופל לפני ששוכפל מידע חדש שנכתב.
      • +
    • כל שינוי ב-master משתכפל לרפליקות, מה שגורם להן להיות עסוקות בשחזור הכתיבות, וזה מאט את הקריאות מהן.
      • +
    • כל רפליקה נוספת מובילה ל-lag גדול יותר בקריאה עקב הצורך לשכפל את כל המידע לכל הרפליקות.
      • +
    • בחלק מהמערכות, כתיבה ל-master יכולה להיות multi-threaded בעוד שברפליקות לרוב הכתיבה היא סנכרונית עם thread בודד.
      • +
    • שכפול מוסיף עוד חומרה ומורכבות.
      • +
    + +##### מקורות וקריאה נוספת: Replication + +- [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) +- [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication) + +--- + +#### פדרציה (Federation) + +

    + +
    + Source: Scaling up to your first 10 million users +

    + +בפדרציה (או חלוקה פונקציונלית) מפצלת DB לפי הפונקציות שלו. לדוגמה, במקום DB מונוליטי בודד, ניתן לנהל 3 DBים נפרדים: **פורומים, משתמשים, ומוצרים**, מה שגורר פחות תעבורת קריאה וכתיבה לכל DB, ועקב כך פחות replication lag. +מסדי נתונים קטנים יותר מאפשרים יותר דאטא שנכנס בזיכרון, שיכול להוביל ליותר cache hits מוצלחים. בלי master אחד מרכזי שאחראי לדאוג לכל הכתיבות באופן סדרתי, אפשר לכתוב במקביל ל-DB שונים עבור כל סוג של נתונים, ובכך להגדיל את ה-throughput. + +##### חסרונות: פדרציה + +
      +
    • לא יעיל אם הסכימה דורשת טבלאות עצומות.
      • +
    • הלוגיקה באפליקציה צריכה להתעדכן כדי לדעת לאיזה DB לפנות.
      • +
    • ביצוע פעולת JOIN משני DBים קשה יותר ודורש server link.
      • +
    • דורשת הוספה של עוד חומרה ומורכבות.
      • +
    + +##### מקורות וקריאה נוספת: פדרציה + +- [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs) + +--- + +#### חלוקה (Sharding) + +

    + +
    + Source: Scalability, availability, stability, patterns +

    + +חלוקה מפזרת את הדאטא בין DBים שונים כך שכל DB מנהל חלק (subset) מסוים של הדאטא. נסתכל למשל על DB של משתמשים, ככל שכמות המשתמשים עולה, יותר חלקים (shards) מתווספים ל-cluster. + +בדומה ליתרונות של [פדרציה](), חלוקה גוררת פחות תעבורה של קריאות וכתיבות, פחות שכפול, ויותר cache hits. גודל ה-index גם קטן, מה שלרוב משפר את קצב ביצוע השאילתות. +אם shard אחד נופל, כל שאר ה-shards עדיין פעילים, למרות שנרצה לבצע שכפול מסוים כדי להימנע מאיבוד מידע. כמו פדרציה, אין master מרכזי אחיד שכל הכתיבות עוברות דרכו, מה שמאפשר לכתוב במקביל ל-DBים שונים ולהגביר את ה-throughput. + +דרכים נפוצות לבצע sharding לטבלה של משתמשים הן באמצעות האות הראשונה של שם המשפחה, או המיקום הגיאוגרפי של המשתמש. + +##### חסרונות: Sharding + +
      +
    • הקוד צריך לדעת באיזה shard הנתונים נמצאים, דבר הגורר שאילתות SQL מורכבות.
      • +
    • התפלגות נתונים עלולה להיות לא אחידה, קבוצה של power users על אותו ה-shard יכולה להביא לעומס מוגבר לאותו ה-shard ביחס לאחרים. + ביצוע rebalance גורר מורכבות נוספת. פונקציית sharding המבוססת על Consistent Hashing יכול להקטין את כמות הדאטא שמועבר בין shardים. +
    • ביצוע פעולת JOIN על מספר shardים מורכבת יותר.
      • +
    • sharding מוסיף חומרה ומורכבות.
      • +
    + +###### מקורות וקריאה נוספת + +- [The coming of the shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html) +- [Shard database architecture](https://en.wikipedia.org/wiki/Shard_(database_architecture)) +- [Consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) + +--- + +#### דנורמליזציה (Denormalization) + +דנורמליזציה שואפת לשפר ביצועים של קריאות על חשבון חלק מהביצועים של הכתיבות. עותקים מיותרים (משוכפלים באופן מכוון, Redundant) של הדאטא נכתבים במספר טבלאות שונות כדי להימנע מביצוע JOINים יקרים. חלק מה-RDBMSים כמו [PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) ו-Oracle תומכים ב-[materialized views](https://en.wikipedia.org/wiki/Materialized_view) אשר דואגים לשמירה של מידע מיותר ושמירת עותקים מיותרים עקביים. + +כאשר הדאטא מבוזר באמצעות טכניקות כמו [פדרציה]() או [חלוקה](), ניהול JOINים בין ריכוזי מידע שונים מגדיר את המורכבות. דנורמליזציה יכולה לייתר את הצורך לבצע JOINים מורכבים. + +ברוב המערכות, כמות הקריאות גדולה בהרבה מכמות הכתיבות, ביחס של 100:1 ואף 1000:1. קריה יכולה להוביל לביצוע JOIN מורכב ויקר, מה שעולה בביצוע פעולות דיסק זמן רב. + +##### חסרונות: דנורמליזציה + +
      +
    • הדאטא משוכפל.
      • +
    • אף שדנורמליזציה משפרת קריאות, היא דורשת שכבת אילוצים (constraints) וחוקים מסוימים כדי לשמור על עקביות העותקים — מה שמסבך את תכנון ה-DB.
      • +
    • במערכת עם עומס כתיבה כבד ייתכן שדנורמליזציה דווקא תפגע בביצועים.
      • +
    + +###### מקורות וקריאה נוספת + +- [Denormalization](https://en.wikipedia.org/wiki/Denormalization) + +--- + +#### SQL Tuning + +SQL Tuning הוא תחום רחב, ונכתבו עליו לא מעט [ספרים](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning). +חשוב לבצע **Benchmark** ו-**Profile** כדי לדמות עומסים ולגלות צווארי-בקבוק. + +
      +
    • Benchmark – סימולציית עומס כבד באמצעות כלים כמו ab.
      • +
    • Profile – הפעלת כלים כגון Slow Query Log למעקב אחר בעיות ביצועים.
      • +
    + +התוצאות של השימוש בכלים אלו עשויה להוביל לאופטימיזציות הבאות: +##### הידוק הסכימה (Tighten up the schema) + +
      +
    • MySQL כותב לדיסק בבלוקים עוקבים, לגישה מהירה.
      • +
    • השתמש ב-CHAR במקום VARCHAR לשדות קבועי-אורך +
        +
      • CHAR מאפשר גישה אקראית מהירה; ב-VARCHAR צריך לחפש את סוף-המחרוזת.
        • +
      +
      • +
    • השתמש ב-TEXT למקטעי טקסט גדולים (למשל פוסטים של בלוג); מאפשר גם חיפושים בוליאניים. השדה מאחסן מצביע על הדיסק שמטרתו לאתר את בלוק הטקסט.
      • +
    • השתמש ב-INT למספרים עד 232 (≈ 4 מיליארד).
      • +
    • השתמש ב-DECIMAL לערכים כספיים – כדי להימנע משגיאות Floating Point.
      • +
    • הימנע מאחסון BLOB-ים גדולים; שמור רק את המיקום שלהם.
      • +
    • VARCHAR(255) – המספר שמנצל בתים בצורה מיטבית בחלק מה-RDBMS-ים.
      • +
    • הגדר NOT NULL כשאפשר כדי לשפר ביצועי חיפוש.
      • +
    + +##### השתמש באינדקסים טובים (Use good indices) + +
      +
    • עמודות הנשלפות באמצעות פקודות כמו SELECT, GROUP BY, ORDER BY, JOIN יכולות להיות מהירות יותר עם אינדקסים.
      • +
    • אינדקסים מיוצגים בדרך-כלל כ-B-Tree מאוזן: שומר על הדאטא ממוין, ומאפשר חיפוש/הוספה/מחיקה בזמן לוגריתמי.
      • +
    • אינדקס שומר את הנתונים בזיכרון – אבל צורך יותר מקום.
      • +
    • כתיבות עלולות להיות איטיות יותר כי צריך לעדכן גם את האינדקס.
      • +
    • בעת טעינת נתונים גדולה ייתכן שיותר מהיר להשבית אינדקסים, לטעון את הנתונים ואז לבנות את האינדקסים מחדש.
      • +
    + +##### מניעת JOIN יקר + + + +##### חלוקה לטבלאות (Partitioning) + +
      +
    • חלוקה לטבלאות (Partitioning) מאפשרת לשמור את ה־hot spots (אזורים “חמים” בטבלה, כלומר רשומות שנקראות/נכתבות הכי הרבה) במחיצה קטנה שנשארת בזיכרון, ולכן שאילתות על הנתונים העדכניים רצות מהר יותר ומעמיסות פחות על הדיסק.
      • +
    + +##### כוונון Query Cache + + + +###### מקורות וקריאה נוספת + +- [Tips for optimizing MySQL queries](http://aiddroid.com/10-tips-optimizing-mysql-queries-dont-suck/) +- [Is there a good reason i see VARCHAR(255) used so often?](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l) +- [How do null values affect performance?](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search) +- [Slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) + +
    From 08f176413ddfc2e7bd0015a991668bc62c7a4eca Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 15 Jun 2025 09:57:27 +0300 Subject: [PATCH 30/43] Minor fixes --- README-he.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/README-he.md b/README-he.md index eb80fc14..c4cf1a0a 100644 --- a/README-he.md +++ b/README-he.md @@ -1154,8 +1154,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת הפרדת שכבת הרשת משכבת האפליקציה (ידועה גם כשכבת ה-platform), מאפשרת לבצע scaling ולקנפג את שתי השכבות באופן בלתי תלוי. הוספת API חדש גוררת הוספתי שרתי אפליקציה, מבלי להוסיף בהכרח גם שרתי המטפלים בלוגיקת הרשת. עקרון האחריות היחידה (**single respoinsibility principle**) מעודד סרביסים עצמאיים וקטנים שעובדים יחד. צוותים קטנים המטפלים שירותים קטנים יכלוים להתכוונן בצורה מיטבית לגדילה מהירה. - - Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוניות](#asynchronism). +Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוניות](#asynchronism). ### מיקרו-סרביסים (Microservices) @@ -1218,7 +1217,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת אם ה-master נופל, המערכת יכולה להמשיך לרוץ במצב read-only עד שאחד ה-slaves מקודם להיות master, או שמקצים master חדש.

    - +
    Source: Scalability, availability, stability, patterns

    @@ -1238,7 +1237,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת שני ה-masters משרתים קריאה וכתיבה (RW) ומתאמים אחד עם השני את הכתיבות. אם אחד מהם נופל, המערכת יכולה להמשיך לתפקד במצב של קריאה וכתיבה.

    - +
    Source: Scalability, availability, stability, patterns

    @@ -1272,7 +1271,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת #### פדרציה (Federation)

    - +
    Source: Scaling up to your first 10 million users

    @@ -1298,7 +1297,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת #### חלוקה (Sharding)

    - +
    Source: Scalability, availability, stability, patterns

    @@ -1365,10 +1364,8 @@ SQL Tuning הוא תחום רחב, ונכתבו עליו לא מעט [ספרים
    • MySQL כותב לדיסק בבלוקים עוקבים, לגישה מהירה.
      • -
    • השתמש ב-CHAR במקום VARCHAR לשדות קבועי-אורך -
        -
      • CHAR מאפשר גישה אקראית מהירה; ב-VARCHAR צריך לחפש את סוף-המחרוזת.
        • -
      +
    • השתמש ב-CHAR במקום VARCHAR לשדות קבועי-אורך. + code>CHAR מאפשר גישה אקראית מהירה; ב-VARCHAR צריך לחפש את סוף-המחרוזת.
    • השתמש ב-TEXT למקטעי טקסט גדולים (למשל פוסטים של בלוג); מאפשר גם חיפושים בוליאניים. השדה מאחסן מצביע על הדיסק שמטרתו לאתר את בלוק הטקסט.
    • השתמש ב-INT למספרים עד 232 (≈ 4 מיליארד).
      • From 8d6aadf15a74782069212711e63edd25272b1a83 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 15 Jun 2025 11:14:35 +0300 Subject: [PATCH 31/43] Translating - finished DB --- README-he.md | 169 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 167 insertions(+), 2 deletions(-) diff --git a/README-he.md b/README-he.md index c4cf1a0a..d2add0ed 100644 --- a/README-he.md +++ b/README-he.md @@ -1351,7 +1351,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני #### SQL Tuning -SQL Tuning הוא תחום רחב, ונכתבו עליו לא מעט [ספרים](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning). +התחום של SQL Tuning הוא רחב, ונכתבו עליו לא מעט [ספרים](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning). חשוב לבצע **Benchmark** ו-**Profile** כדי לדמות עומסים ולגלות צווארי-בקבוק.
        @@ -1403,11 +1403,176 @@ SQL Tuning הוא תחום רחב, ונכתבו עליו לא מעט [ספרים
      • במקרים מסוימים, query cache עלול לגרום לבעיות ביצועים.
      -###### מקורות וקריאה נוספת +##### מקורות וקריאה נוספת - [Tips for optimizing MySQL queries](http://aiddroid.com/10-tips-optimizing-mysql-queries-dont-suck/) - [Is there a good reason i see VARCHAR(255) used so often?](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l) - [How do null values affect performance?](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search) - [Slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) +### NoSQL + +לעומת SQL קלאסי, NoSQL הוא אוסף של מבני נתונים הנשמרים בתור **Key-Value Store**, **Document Store**, **Wide Column Store** או **Graph Database**. +הנתונים מנורמלים פחות, ופעולות JOIN מבוצעות לרוב בקוד האפליקציה עצמה. +רוב האחסונים מסוג NoSQL אינם תומכים בטרנזקציות ACID מלאות ומספקים [עקביות לא מיידית](#eventual-consistency). + +מקובל לסמן את מאפייני NoSQL בראשי התיבות **BASE** (תווך שימוש ב[משפט CAP](#cap-theorem), תכונות BASE מתעדפות זמינות (A) על פני עקביות (C)): + +
        +
      • Basically Available – המערכת מבטיחה זמינות.
        • +
      • Soft State – מצב המערכת עשוי להשתנות עם הזמן, גם ללא קלט.
        • +
      • Eventual Consistency – המערכת תהפוך עקבית בסופו של דבר, בהנחה שלא מתקבל קלט נוסף בתקופה זו.
        • +
      + +מעבר לבחירה בין [SQL ל-NoSQL](#sql-or-nosql), חשוב להבין איזה סוג NoSQL מתאים ביותר לשימוש שלך. נדון בסוגים **Key-Value Stores**, **Document Stores**, **Wide Column Stores** ו-**Graph Databases**. + +--- + +#### אחסון Key-Value +> הפשטה: Hash Table + +אחסון Key-Value לרוב מאפשר קריאות וכתיבות ב-O(1) ומגובה באמצעות זיכרון או SSD. ניתן לשמור מפתחות ב[סדר לקסיקוגרפי](), מה שמאפשר שליפה יעילה של טווחי המפתחות. +אחסון זה מאפשר תמיכה ב-metadadta עם ערכים. + +אחסון זה מספק ביצועים גבוהים ולרוב בשימוש עבור מודלי דאטא פשוטים או לדאטא שמשתנה במהירות, כמו שכבת cache in-memory. כיוון שסוגי אחסון זה מציעים סט מצומצם של פעולות, המורכבות נמצאת בשכבת האפלקציה אם נדרשות פעולות נוספות. + +אחסון זה הוא הבסיס למערכות מורכבות יותר כמו document store ובמקרים מסוימים גם graph db. + +##### מקורות וקריאה נוספת: אחסון Key-Value + +- [Key-value database](https://en.wikipedia.org/wiki/Key-value_database) +- [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or) +- [Redis architecture](http://qnimate.com/overview-of-redis-architecture/) +- [Memcached architecture](https://adayinthelifeof.nl/2011/02/06/memcache-internals/) + +--- + +#### אחסון Document +> הפשטה: אחסון Key-Value שבו הערך הוא מסמך + +אחסון Document מתרכז סביב מסמכים (XML, JSON, binary, etc.) כאשר מסמך שומר את כל המידע שקשור לאובייקט מסוים. אחסון זה מספק API או query language כדי לתשאל על בסיס המבנה הפנימי של המסמך עצמו. נשים לב, כי הרבה אחסונים מסוג Key-Value כוללים פיצ'רים כדי לעבוד עם ה-metadata של ה-value, מה שמטשטש את הגבול בין שני סוגי אחסון אלו. + +על בסיס המימוש הספציפי מאחורי הקלעים, מסמכים מאורגנים לפי אוספים, תגים, metadata או תיקיות. למרות שמסמכים יכולים להיות מאורגנים או מקובצים יחדיו, יכולים להיות להם שדות שונים לחלוטין אחד מהשני. + + +אחסונים כמו [MongoDB](https://www.mongodb.com/mongodb-architecture) ו-[CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) מציעים שפה דמוית SQL על מנת לבצע שאילתות מורכבות. +[DynamoDB](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) תומך גם ב-Key-Value וגם במסמכים. + +אחסונים אלו מספקים גמישות גבוהה ולרוב בשימוש עבור דאטא שמשתנה בתדירות גבוהה. + +##### מקורות וקריאה נוספת: אחסון Document + +- [Document-oriented database](https://en.wikipedia.org/wiki/Document-oriented_database) +- [MongoDB architecture](https://www.mongodb.com/mongodb-architecture) +- [CouchDB architecture](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) +- [Elasticsearch architecture](https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up) + +--- + +#### אחסון Wide Column + +

      + +
      + Source: SQL & NoSQL, a brief history +

      + +> הפשטה: Map מקונן מסוג + +> ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>> + +אחסון Wide Column עובד עם יחידת דאטא בסיסית שהיא עמודה (זוג שם/ערך). +עמודות מקובצות תחת column families (כמו טבלת SQL). Super column families הן אוסף של column families. אפשר לגשת לכל עמודה בנפרד עם row key, כאשר עמודות בעלות אותו row key יוצרות שורה. +כל ערך מכיל timestamp עבור גרסאות ופתרון קונפליקטים. + +דוגמאות: Google הציגה את [Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) כאחסון הראשון מסוג זה. זה השפיע על פרויקט הקוד הפתוח [HBase](https://www.edureka.co/blog/hbase-architecture/) (באקוסיסטם Hadoop) ו-[Cassandra](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html) של Facebook. +מערכות כמו Bigtable, HBase ו-Cassandra שומרות מפתחות בסדר **לקסיקוגרפי**, וכך מאפשרות שליפת טווחי מפתחות ביעילות. + +אחסונים אלו מציעים זמינות גבוהה, וסקילביליות גבוהה. לרוב משתמשים בהם לאחסון דאטאסטים מאוד גדולים. + +##### מקורות וקריאה נוספת: אחסון Wide Column + +- [SQL & NoSQL, a brief history](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html) +- [Bigtable architecture](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) +- [HBase architecture](https://www.edureka.co/blog/hbase-architecture/) +- [Cassandra architecture](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html) + +--- + +#### אחסון Graph + +

      + +
      + Source: Graph database +

      + +> הפשטה: גרף + +ב-DB גרפי כל **צומת** (Node) הוא רשומה, וכל **קשת** (Arc/Edge) היא קשר בין שני צמתים. +ה-DB מותאם לייצוג קשרים מורכבים – עם הרבה מפתחות זרים (Foreign Keys) או יחסי Many-to-Many. + +אחסון זה מאפשר ביצועים גבוהים למודלים עם יחסים מורכבים, למשל כמו רשת חברתית. הטכנולוגיה הזו יחסית חדשה ופות נפוצה; ייתכן קושי למצוא כלי פיתוח ומשאבים. הרבה אחסונים מסוג זה נגישים רק באמצעות +[REST APIs](#representational-state-transfer-rest). + +##### מקורות וקריאה נוספת: Graph + +- [Graph database](https://en.wikipedia.org/wiki/Graph_database) +- [Neo4j](https://neo4j.com/) +- [FlockDB](https://blog.twitter.com/2010/introducing-flockdb) + +#### מקורות וקריאה נוספת: NoSQL + +- [Explanation of base terminology](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology) +- [NoSQL databases a survey and decision guidance](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq) +- [Scalability](https://web.archive.org/web/20220602114024/https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database) +- [Introduction to NoSQL](https://www.youtube.com/watch?v=qI_g07C_Q5I) +- [NoSQL patterns](http://horicky.blogspot.com/2009/11/nosql-patterns.html) + +### SQL or NoSQL + +

      + +
      + Source: Transitioning from RDBMS to NoSQL +

      + +-סיבות לשימוש ב**SQL**: + +
        +
      • נתונים עם מבנה קבוע
        • +
      • סכמה ברורה עם אילוצים וטיפוסים
        • +
      • דאטא עם קשרי Foreign Key ו־Many-to-Many
        • +
      • צורך בביצוע JOIN-ים מורכבים
        • +
      • טרנזקציות (עקרונות ACID)
        • +
      • תבניות ברורות לביצוע Scaling
        • +
      • אקו־סיסטם ענק של כלים, קוד וקהילה
        • +
      • חיפושים לפי אינדקס מהירים מאוד
        • +
      + +סיבות לשימוש ב-**NoSQL**: + +
        +
      • דאטא שהוא מובנה באופן חלקי
        • +
      • סכמה דינמית או גמישה
        • +
      • דאטא ללא relations
        • +
      • אין צורך ב־JOIN־ים מורכבים
        • +
      • אחסון TB או PB של דאטא
        • +
      • פעולות רבות של כתיבה וקריאה בשנייה
        • +
      • כמות גדולה של פעולות דיסק בשנייה
        • +
      + +דאטא לדוגמה שמתאים מאוד עבור **NoSQL**: + +- Rapid ingest of clickstream and log data +- Leaderboard or scoring data +- Temporary data, such as a shopping cart +- Frequently accessed ('hot') tables +- Metadata/lookup tables + +##### מקורות וקריאה נוספת: SQL or NoSQL + +- [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs) +- [SQL vs NoSQL differences](https://www.sitepoint.com/sql-vs-nosql-differences/) +
    From 71ef65af5c1b41880b4423ded1240884d436b55b Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 15 Jun 2025 11:16:15 +0300 Subject: [PATCH 32/43] Minor fixes --- README-he.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README-he.md b/README-he.md index d2add0ed..96b8a9e1 100644 --- a/README-he.md +++ b/README-he.md @@ -1472,7 +1472,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני #### אחסון Wide Column

    - +
    Source: SQL & NoSQL, a brief history

    @@ -1502,7 +1502,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני #### אחסון Graph

    - +
    Source: Graph database

    @@ -1532,7 +1532,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני ### SQL or NoSQL

    - +
    Source: Transitioning from RDBMS to NoSQL

    From da82c9a4df80b40f7a29d5c8be1b1fca508faa99 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sun, 15 Jun 2025 11:46:08 +0300 Subject: [PATCH 33/43] Fixes --- README-he.md | 74 +++++++++++++++++++++++++++++----------------------- 1 file changed, 41 insertions(+), 33 deletions(-) diff --git a/README-he.md b/README-he.md index 96b8a9e1..9beac113 100644 --- a/README-he.md +++ b/README-he.md @@ -130,29 +130,29 @@
  • השלבים הבאים
    • -
  • ביצועים (performance) מול סקילביליות (scalability)
    • -
  • שיהוי (latency) מול תפוקה (throughput)
    • -
  • זמינות (availability) מול עקביות (consistency) +
  • ביצועים (Performance) מול סקילביליות (Scalability)
    • +
  • שיהוי (Latency) מול תפוקה (Throughput)
    • +
  • זמינות (Availability) מול עקביות (Consistency)
  • דפוסי עקביות
  • דפוסי זמינות
    • @@ -163,44 +163,44 @@
  • משיכה (Pull)
    • -
  • מאזן עומסים (load balancer) +
  • מאזן עומסים (Load Balancer)
    • -
  • פרוקסי הפוך (Reverse Proxy) +
  • פרוקסי הפוך (Reverse Proxy)
    • -
  • שכבת האפליקציה +
  • שכבת האפליקציה
    • -
  • מסדי נתונים +
  • מסדי נתונים
    • @@ -441,7 +442,7 @@ -## שאלות ריאיון תכנון מערכות עם פתרונות +## שאלות ריאיון ארכיטקטורה עם פתרונות
    @@ -491,7 +492,8 @@ הוסף שאלה לתכנון מערכת - תרום + תרום @@ -605,7 +607,6 @@ >**הערה: החלק הזה עדיין בפיתוח** - @@ -640,11 +641,13 @@ - + - +
    תכנן מערך מעגליתרוםתרום
    הוסף שאלה בעיצוב מונחה עצמיםתרוםתרום
    @@ -1838,7 +1841,7 @@ def set_user(user_id, values): - [Celery](https://docs.celeryproject.org/en/stable/) has support for scheduling and primarily has python support. -### Back Pressure +### לחץ נגדי (Back Pressure) אם התור מתחיל לגדול באופן משמעותי מעבר לקצב שבו ה-workers מסוגלים לעבד, גודל התור יכול להיות מעבר למה שפנוי לנו בזיכרון, מה שיגרום ל-cache misses, יותר קריאות מהדיסק, וביצועים נמוכים יותר. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) יכול לעזור באמצעות הגדלת גודל התור, מה ששומר על קצב הטיפול בבקשות לכאלו שכבר בתוך התור. אם התור מתמלא, השרת מפסיק לקבל עבודות חדשות ומחזיר ללקוח שגיאת HTTP 503 (עסוק). הלקוח יכול לנסות שוב לאחר זמן המתנה הולך וגדל כמו [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff). @@ -2062,7 +2065,7 @@ PUT /someresources/anId ## אבטחת מידע (Security) -הפרק הזה זקוק לעדכונים. מוזמנים [לעזור](#contributing)! +הפרק הזה זקוק לעדכונים. מוזמנים [לעזור](#תרומה-למדריך)! אבטחת מידע היא תחום רחב ומורכב, אבל לרוב הראיונות (כל עוד אינך מומחה אבטחה) מספיק להכיר את העקרונות הבסיסיים: @@ -2180,7 +2183,7 @@ Notes | Design a garbage collection system | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)
    [washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) | | Design an API rate limiter | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) | | Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)
    [Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)
    [Go Implementation](http://bhomnick.net/building-a-simple-limit-order-in-go/) | -| Add a system design question | [Contribute](#contributing) | +| Add a system design question | [Contribute](#תרומה-למדריך) | ### ארכיטקטורות מהעולם האמיתי @@ -2222,7 +2225,7 @@ Notes | Misc | **Dapper** - Distributed systems tracing infrastructure | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf) | Misc | **Kafka** - Pub/sub message queue from LinkedIn | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) | | Misc | **Zookeeper** - Centralized infrastructure and services enabling synchronization | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) | -| | Add an architecture | [Contribute](#contributing) | +| | Add an architecture | [Contribute](#תרומה-למדריך) | ### ארכיטקטורות של חברות @@ -2305,17 +2308,14 @@ Looking to add a blog? To avoid duplicating work, consider adding your company * [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs) - - - ## תחת פיתוח -מעוניין להוסיף חלק או לעזור לסיים אחד שנמצא בעבודה? [תרום](#contributing)! +מעוניין להוסיף חלק או לעזור לסיים אחד שנמצא בעבודה? [תרום](#תרומה-למדריך)! - Distributed computing with MapReduce - Consistent hashing - Scatter gather -- [Contribute](#contributing) +- [Contribute](#תרומה-למדריך) ## קרדיטים From a260e09497d4aac7c292329ab810bdb4f76cac21 Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Wed, 18 Jun 2025 20:59:18 +0300 Subject: [PATCH 43/43] Updated more links --- README-he.md | 87 ++++++++++++++++++++++++++-------------------------- 1 file changed, 43 insertions(+), 44 deletions(-) diff --git a/README-he.md b/README-he.md index 09628256..ab9c2527 100644 --- a/README-he.md +++ b/README-he.md @@ -116,7 +116,7 @@ > כל חלק מכיל קישורים להרחבה וללמידה מעמיקה יותר.

    - +

    @@ -268,7 +268,7 @@ > נושאים מוצעים ללימוד לפי לוח הזמנים לריאיון שלך (קצר, בינוני, ארוך)

    - +

    @@ -307,43 +307,43 @@ - קרא את הנושאים בתכנון מערכות כדי לקבל הבנה כללית של איך מערכות עובדות + קרא את אינדקס נושאים בארכיטקטורה כדי לקבל הבנה כללית של איך מערכות עובדות :+1: :+1: :+1: - קרא כמה מאמרים מתוך בלוגים של חברות שאתה מתראיין אליהן + קרא כמה מאמרים מתוך בלוגים טכניים של חברות שאתה מתראיין אליהן :+1: :+1: :+1: - קרא על כמה ארכיטקטורות מהעולם האמיתי + קרא על כמה ארכיטקטורות מהעולם האמיתי :+1: :+1: :+1: - חזור על איך לגשת לשאלת ריאיון בתכנון מערכות + חזור על איך לגשת לשאלת ריאיון ארכיטקטורה :+1: :+1: :+1: - תרגל שאלות ריאיון בתכנון מערכות עם פתרונות + תרגל שאלות ריאיון ארכיטקטורה עם פתרונות כמה הרבה רוב - תרגל שאלות ריאיון בתכנון מונחה עצמים עם פתרונות + תרגל שאלות ריאיון בתכנון מונחה עצמים עם פתרונות כמה הרבה רוב - חזור על שאלות ריאיון נוספות בתכנון מערכות + חזור על שאלות ריאיון נוספות כמה הרבה רוב @@ -361,7 +361,7 @@ ראיון ארכיטקטורה הוא **שיחה פתוחה**. מצופה ממך להוביל אותה. -אתה יכול להיעזר בצעדים הבאים כדי להנחות את הדיון. כדי לחזק את ההבנה של התהליך, תעבור על [שאלות ריאיון בתכנון מערכות עם פתרונות](#system-design-interview-questions-with-solutions) אל מול הצעדים הבאים: +אתה יכול להיעזר בצעדים הבאים כדי להנחות את הדיון. כדי לחזק את ההבנה של התהליך, תעבור על [שאלות ריאיון ארכיטקטורה עם פתרונות](#שאלות-ריאיון-ארכיטקטורה-עם-פתרונות) אל מול הצעדים הבאים: ### תאר מקרי שימוש, אילוצים והנחות עבודה @@ -420,24 +420,24 @@
  • פיצול בסיס נתונים (Database sharding)
    • -דון בפתרונות אפשריים וה-trade-offs. הכול הוא trade-off. התמודד עם צווארי בקבוק בעזרת [עקרונות תכנון מערכת סקילבילית](#index-of-system-design-topics). +דון בפתרונות אפשריים וה-trade-offs. הכול הוא trade-off. התמודד עם צווארי בקבוק בעזרת [עקרונות תכנון מערכת סקילבילית](#אינדקס-נושאים-בארכיטקטורה). -### חישובים "על גב המעטפה" (מהירים) +### חישובי מספרים (back-of-the-enveloppe) -ייתכן שיבקשו ממך לבצע הערכות באופן ידני. ראה את [הנספח](#appendix) עבור המשאבים הבאים: +ייתכן שיבקשו ממך לבצע הערכות באופן ידני. ראה את [הנספחים](#נספחים) עבור המשאבים הבאים: -* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html) -* [Powers of two table](#powers-of-two-table) -* [Latency numbers every programmer should know](#latency-numbers-every-programmer-should-know) +- [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html) +- [Powers of two table](#powers-of-two-table) +- [Latency numbers every programmer should know](#latency-numbers-every-programmer-should-know) ### מקורות לקריאה נוספת עיין בקישורים הבאים כדי להבין טוב יותר למה לצפות: -* [How to ace a systems design interview](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/) -* [The system design interview](http://www.hiredintech.com/system-design) -* [Intro to Architecture and Systems Design Interviews](https://www.youtube.com/watch?v=ZgdS0EUmn70) -* [System design template](https://leetcode.com/discuss/career/229177/My-System-Design-Template) +- [How to ace a systems design interview](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/) +- [The system design interview](http://www.hiredintech.com/system-design) +- [Intro to Architecture and Systems Design Interviews](https://www.youtube.com/watch?v=ZgdS0EUmn70) +- [System design template](https://leetcode.com/discuss/career/229177/My-System-Design-Template)
    @@ -765,7 +765,7 @@ תשובות לבקשות מהמערכת מחזירות את הגרסה הזמינה ביותר של הנתונים הזמינים בשרת הרלוונטי, שאינה בהכרח האחרונה. כתיבה עשויה לקחת זמן מסוים עד שתסתיים, עד אשר התקשורת הבעייתית תיפתר. -לכן, AP הוא בחירה טובה במידה ויש הצדקה עסקית לעבוד במצב של [eventual consistency](#eventual-consistency) או במידה והמערכת צריכה להמשיך לשרת למרות שגיאות בלתי-תלויות. +לכן, AP הוא בחירה טובה במידה ויש הצדקה עסקית לעבוד במצב של [eventual consistency](#עקביות-לא-מיידית-eventual-consistency) או במידה והמערכת צריכה להמשיך לשרת למרות שגיאות בלתי-תלויות. ### חומרים וקריאה נוספת @@ -782,7 +782,7 @@
    כאשר קיימים מספר עותקים של אותם נתונים, עלינו להחליט כיצד לסנכרן ביניהם כדי שלקוחות יקבלו תצוגה עקבית של המידע. -ניזכר בהגדרה של עקביות מתוך [משפט CAP](#cap-theorem): כל קריאה מקבלת את הכתיבה העדכנית ביותר או שגיאה. +ניזכר בהגדרה של עקביות מתוך [משפט CAP](#משפט-cap): כל קריאה מקבלת את הכתיבה העדכנית ביותר או שגיאה. ### עקביות חלשה (Weak Consistency) @@ -844,10 +844,10 @@ #### עבור Master-Slave/Master-Master -נושא זה נדון בפירוט נוסף בחלק על [מסדי נתונים](#database): +נושא זה נדון בפירוט נוסף בחלק על [מסדי נתונים](#מסדי-נתונים-db): -- [Master-slave replication](#master-slave-replication) -- [Master-master replication](#master-master-replication) +- [Master-slave replication](#שכפול-master-slave) +- [Master-master replication](#שכפול-master-master)
    @@ -1031,8 +1031,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת -כדי להגן מפני כישלונות נהוג להקים מספר מאזני עומסים, במצב -[Active-Passive](#אקטיבי-פסיבי-active-passive) או [Active-Active](#אקטיבי-אקטיבי-active-active). +כדי להגן מפני כישלונות נהוג להקים מספר מאזני עומסים, במצב [Active-Passive](#אקטיבי-פסיבי-active-passive) או [Active-Active](#אקטיבי-אקטיבי-active-active). מאזן עומסים יכול לנתב את התעבורה על פי מדדים שונים: @@ -1045,7 +1044,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת ### איזון עומסים בשכבה 4 -מאזני עומסים בשכבה 4 בוחנים מידע בשכבת התעבורה ([transport layer](#communication)) כדי להחליט כיצד להפיץ בקשות. +מאזני עומסים בשכבה 4 בוחנים מידע בשכבת התעבורה ([transport layer](#תקשורת-communication)) כדי להחליט כיצד להפיץ בקשות. בדרך כלל, מדובר בכתובות ה-IP של המקור והיעד ובפורטים שבכותרת (header), ולא בתוכן הפקטה (packet). מאזני עומסים בשכבה 4 מעבירים את חבילות הרשת אל ומן השרת הנבחר (upstream server) תוך ביצוע [תרגום כתובות רשת (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/). @@ -1053,7 +1052,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת ### איזון עומסים בשכבה 7 -מאזני עומסים בשכבה 7 בוחנים את [שכבת האפליקציה](#communication) כדי להחליט כיצד להפיץ בקשות. ההחלטה יכולה להתבסס על תוכן הכותרות (headers), גוף ההודעה, ועוגיות (cookies). +מאזני עומסים בשכבה 7 בוחנים את [שכבת האפליקציה](#תקשורת-communication) כדי להחליט כיצד להפיץ בקשות. ההחלטה יכולה להתבסס על תוכן הכותרות (headers), גוף ההודעה, ועוגיות (cookies). מאזן עומסים בשכבה 7 מסיים (terminates) את תעבורת הרשת אל מול הלקוח, קורא את ההודעה, מקבל החלטת איזון-עומסים, ואז פותח חיבור לשרת שנבחר. למשל, מאזן כזה יכול לשלוח תעבורת וידאו לשרתים שמאחסנים קטעי וידאו, ובמקביל לנתב תעבורת חיוב משתמשים (billing) לשרתים מוקשחים אבטחתית. @@ -1071,7 +1070,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת
  • גדילה אופקית מוסיפה מורכבות וכוללת שכפול שרתים
  • שרתים בהמשך השרשרת (downstream) למשל cache ו-DB צריכים להתמודד עם יותר חיבורים בו-זמנית ככל שמספר שרתי האפליקציה גדל
    • @@ -1157,7 +1156,7 @@ Pull CDN מתאים לאתרים עתירי תעבורה, שכן העומס מת הפרדת שכבת הרשת משכבת האפליקציה (ידועה גם כשכבת ה-platform), מאפשרת לבצע scaling ולקנפג את שתי השכבות באופן בלתי תלוי. הוספת API חדש גוררת הוספתי שרתי אפליקציה, מבלי להוסיף בהכרח גם שרתי המטפלים בלוגיקת הרשת. עקרון האחריות היחידה (**single respoinsibility principle**) מעודד סרביסים עצמאיים וקטנים שעובדים יחד. צוותים קטנים המטפלים שירותים קטנים יכלוים להתכוונן בצורה מיטבית לגדילה מהירה. -Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוניות](#asynchronism). +Workers בשכבת האפליקציה מסייעים גם [לאסינכרוניות](#אסינכרוניות-asynchronism). ### מיקרוסרביסים (Microservices) @@ -1170,7 +1169,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני מערכות כמו [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcddocs/latest), ו-[Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) מסייעות לשירותים “למצוא” זה את זה על ידי ניהול ומעקב אחר שמות הסרביסים, כתובות IP, ופורטים. בדיקות דופק ([Health checks](https://www.consul.io/intro/getting-started/checks.html)) — מאמתות את תקינות השירות, לעיתים קרובות באמצעות endpoint HTTP. גם Consul וגם Etcd כוללים -[אחסון key-value](#key-value-store) מובנה, השימושי לאחסון קונפיגורציה ונתונים משותפים. +[אחסון key-value](#אחסון-key-value) מובנה, השימושי לאחסון קונפיגורציה ונתונים משותפים. ### חסרונות: שכבת האפליקציה @@ -1230,7 +1229,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני --- @@ -1251,7 +1250,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני
  • נדרש מאזן עומסים או שינוי לוגיקת האפליקציה כדי להחליט לאן לכתוב.
  • רוב מערכות ה-Master-Master מפרות עקרון של עקביות (לכן מפרות ACID) או סובלות מאיטיות כתיבה עקב הצורך לבצע סנכרון.
  • ככל שמתרבים שרתים שמאפשרים כתיבה וה-latency גדל, יש צורך להכריע יותר מקרים של conflict.
    • -
  • ראה חסרונות: replication.
    • +
  • ראה חסרונות: replication.
    • ##### חסרונות: Replication (כללי) @@ -1307,7 +1306,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני חלוקה מפזרת את הדאטא בין DBים שונים כך שכל DB מנהל חלק (subset) מסוים של הדאטא. נסתכל למשל על DB של משתמשים, ככל שכמות המשתמשים עולה, יותר חלקים (shards) מתווספים ל-cluster. -בדומה ליתרונות של [פדרציה](), חלוקה גוררת פחות תעבורה של קריאות וכתיבות, פחות שכפול, ויותר cache hits. גודל ה-index גם קטן, מה שלרוב משפר את קצב ביצוע השאילתות. +בדומה ליתרונות של [פדרציה](#פדרציה-federation), חלוקה גוררת פחות תעבורה של קריאות וכתיבות, פחות שכפול, ויותר cache hits. גודל ה-index גם קטן, מה שלרוב משפר את קצב ביצוע השאילתות. אם shard אחד נופל, כל שאר ה-shards עדיין פעילים, למרות שנרצה לבצע שכפול מסוים כדי להימנע מאיבוד מידע. כמו פדרציה, אין master מרכזי אחיד שכל הכתיבות עוברות דרכו, מה שמאפשר לכתוב במקביל ל-DBים שונים ולהגביר את ה-throughput. דרכים נפוצות לבצע sharding לטבלה של משתמשים הן באמצעות האות הראשונה של שם המשפחה, או המיקום הגיאוגרפי של המשתמש. @@ -1392,7 +1391,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני ##### מניעת JOIN יקר ##### חלוקה לטבלאות (Partitioning) @@ -1418,9 +1417,9 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני לעומת SQL קלאסי, NoSQL הוא אוסף של מבני נתונים הנשמרים בתור **Key-Value Store**, **Document Store**, **Wide Column Store** או **Graph Database**. הנתונים מנורמלים פחות, ופעולות JOIN מבוצעות לרוב בקוד האפליקציה עצמה. -רוב האחסונים מסוג NoSQL אינם תומכים בטרנזקציות ACID מלאות ומספקים [עקביות לא מיידית](#eventual-consistency). +רוב האחסונים מסוג NoSQL אינם תומכים בטרנזקציות ACID מלאות ומספקים [עקביות לא מיידית](#עקביות-לא-מיידית-eventual-consistency). -מקובל לסמן את מאפייני NoSQL בראשי התיבות **BASE** (תווך שימוש ב[משפט CAP](#cap-theorem), תכונות BASE מתעדפות זמינות (A) על פני עקביות (C)): +מקובל לסמן את מאפייני NoSQL בראשי התיבות **BASE** (תווך שימוש ב[משפט CAP](#משפט-cap), תכונות BASE מתעדפות זמינות (A) על פני עקביות (C)): -מעבר לבחירה בין [SQL ל-NoSQL](#sql-or-nosql), חשוב להבין איזה סוג NoSQL מתאים ביותר לשימוש שלך. נדון בסוגים **Key-Value Stores**, **Document Stores**, **Wide Column Stores** ו-**Graph Databases**. +מעבר לבחירה בין [SQL ל-NoSQL](#השוואה-sql-or-nosql), חשוב להבין איזה סוג NoSQL מתאים ביותר לשימוש שלך. נדון בסוגים **Key-Value Stores**, **Document Stores**, **Wide Column Stores** ו-**Graph Databases**. --- #### אחסון Key-Value > הפשטה: Hash Table -אחסון Key-Value לרוב מאפשר קריאות וכתיבות ב-O(1) ומגובה באמצעות זיכרון או SSD. ניתן לשמור מפתחות ב[סדר לקסיקוגרפי](), מה שמאפשר שליפה יעילה של טווחי המפתחות. +אחסון Key-Value לרוב מאפשר קריאות וכתיבות ב-O(1) ומגובה באמצעות זיכרון או SSD. ניתן לשמור מפתחות ב[סדר לקסיקוגרפי](https://he.wikipedia.org/wiki/%D7%99%D7%97%D7%A1_%D7%A1%D7%93%D7%A8_%D7%9E%D7%99%D7%9C%D7%95%D7%A0%D7%99), מה שמאפשר שליפה יעילה של טווחי המפתחות. אחסון זה מאפשר תמיכה ב-metadadta עם ערכים. אחסון זה מספק ביצועים גבוהים ולרוב בשימוש עבור מודלי דאטא פשוטים או לדאטא שמשתנה במהירות, כמו שכבת cache in-memory. כיוון שסוגי אחסון זה מציעים סט מצומצם של פעולות, המורכבות נמצאת בשכבת האפלקציה אם נדרשות פעולות נוספות. @@ -1517,7 +1516,7 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני ה-DB מותאם לייצוג קשרים מורכבים – עם הרבה מפתחות זרים (Foreign Keys) או יחסי Many-to-Many. אחסון זה מאפשר ביצועים גבוהים למודלים עם יחסים מורכבים, למשל כמו רשת חברתית. הטכנולוגיה הזו יחסית חדשה ופות נפוצה; ייתכן קושי למצוא כלי פיתוח ומשאבים. הרבה אחסונים מסוג זה נגישים רק באמצעות -[REST APIs](#representational-state-transfer-rest). +[REST APIs](#ממשק-rest). ##### מקורות וקריאה נוספת: Graph @@ -1600,15 +1599,15 @@ Workers בשכבת האפליקציה מסייעים גם [לא-סינכרוני ### מטמון בצד לקוח -מטמון יכול להיות ממוקם בצד הלקוח (מערכת ההפעלה או הדפדפן), [צד השרת](#reverse-proxy-web-server), או בשכבה נפרדת. +מטמון יכול להיות ממוקם בצד הלקוח (מערכת ההפעלה או הדפדפן), [צד השרת](#פרוקסי-הפוך-reverse-proxy), או בשכבה נפרדת. ### מטמון CDN -ניתן להסתכל על [CDN](#content-delivery-network) גם בתור שכבה של מטמון. +ניתן להסתכל על [CDN](#רשתות-הפצת-תוכן-cdn) גם בתור שכבה של מטמון. ### מטמון בשרת -[פרוקסי הפוך](#reverse-proxy-web-server) ומנגנוני cache כמו [Varnish](https://www.varnish-cache.org/) יכולים להנגיש תוכן סטטי ודינמי ישירות. שרתי web יכולים גם לבצע cache לבקשות כדי להחזיר תשובות בלי צורך להגיע עד לשרתי האפליקציה. +[פרוקסי הפוך](#פרוקסי-הפוך-reverse-proxy) ומנגנוני cache כמו [Varnish](https://www.varnish-cache.org/) יכולים להנגיש תוכן סטטי ודינמי ישירות. שרתי web יכולים גם לבצע cache לבקשות כדי להחזיר תשובות בלי צורך להגיע עד לשרתי האפליקציה. ### מטמון במסד נתונים