mirrors
/
system-design-primer
mirror of https://github.com/donnemartin/system-design-primer.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
system-design-primer/README-he.md

34 KiB
Raw Blame History

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

עזרו לתרגם את המדריך!

המדריך לתכנון מערכות (The System Design Primer)


מוטיבציה

ללמוד איך לתכנן מערכות ב-scale גדול.

להתכונן לראיונות ארכיטקטורה.

ללמוד איך לתכנן מערכות ב-scale גדול

ללמוד כיצד לתכנן מערכות סְקֵילָבִּילִיוּת יסייע לך להפוך למהנדס תוכנה טוב יותר.

תכנון מערכות הוא נושא רחב. יש כמות אדירה של משאבים ברחבי הרשת על עקרונות של תכנון מערכות.

ה-repo הזה הוא אוסף מסודר של משאבים שנועדו לעזור לך ללמוד איך לבנות מערכות ב-scale.

ללמוד מקהילת הקוד הפתוח

מדובר בפרויקט קוד פתוח (open source) שמתעדכן באופן מתמשך.

מוזמנים לתרום!

להתכונן לראיונות ארכיטקטורה

בנוסף לראיונות קידוד, ארכיטקטורה היא רכיב נדרש כחלק מתהליך ראיונות טכניים בהרבה חברות טכנולוגיות.

תוכל לתרגל שאלות ארכיטקטורה נפוצות ואף להשוות את התוצאות שלך עם פתרונות לדוגמה: דיונים, קוד, ודיאגרמות.

נושאים נוספים להכנה לראיונות:

כרטיסיות Anki


החבילות המוכנות של כרטיסיות Anki משתמשות בשיטת חזרתיות מבוססת מרווחים (Spaced Repetition) כדי לעזור לך לזכור מושגים חשובים בתכנון מערכות.

מומלצות לשימוש בדרכים.

משאב לראיונות קידוד: אתגרי קידוד אינטראקטיביים

מחפש משאבים שיעזרו לך להתכונן לראיונות קידוד?


תעיף מבט על ה-repo המקביל Interactive Coding Challenges, שמכיל חבילת Anki נוספת:

תרומה למדריך

ללמוד מהקהילה.

אל תהסס להגיש pull requests כדי לעזור:

תכנים שעדיין דורשים ליטוש מסומנים בתור תחת פיתוח.

מומלץ לעיין בהנחיות לתרומה לפני התחלה.

אינדקס נושאים בארכיטקטורה

סיכומים של נושאים שונים בתכנון מערכות, כולל יתרונות וחסרונות. כל החלטה כוללת פשרות (trade-offs).

כל חלק מכיל קישורים להרחבה וללמידה מעמיקה יותר.


אינדקס נושאים

מדריך למידה

נושאים מוצעים ללימוד לפי לוח הזמנים לריאיון שלך (קצר, בינוני, ארוך)


ש: עבור הראיונות, האם אני אמור לדעת כל מה שכתוב כאן?

ת: לא, אתה לא צריך לדעת הכול כדי להתכונן לריאיון.

מה שאתה תישאל עליו בריאיון תלוי בדברים כגון:

  • כמה ניסיון יש לך
  • מה הרקע הטכני שלך
  • לאילו משרות אתה מתראיין
  • באילו חברות אתה מתראיין
  • מזל

לרוב מצופה ממועמדים מנוסים יותר לדעת יותר על ארכיטקטורה ותכנון מערכות. ארכיטקטים או ראשי צוותים מצופים לדעת יותר מאשר עובדים בודדים. חברות טכנולוגיות מובילות לרוב יערכו ריאיון אחד או יותר של ארכיטקטורה.

רצוי להתחיל רחב ולהעמיק במספר תחומים. זה עוזר לדעת קצת בנוגע למספר נושאי מפתח בתכנון מערכות. תתאים את המדריך לפי לוח הזמן שלך, הניסיון, המשרות שאתה מתראיין אליהן, והחברות שבהן אתה מתראיין.

  • לוח זמנים קצר – התמקד ברוחב של נושאים בתכנון מערכות. תרגל פתרון של כמה שאלות ריאיון.
  • לוח זמנים בינוני – התמקד ברוחב וקצת עומק של נושאים בתכנון מערכות. תרגל פתרון של הרבה שאלות ריאיון.
  • לוח זמנים ארוך – התמקד ברוחב ויותר עומק של נושאים בתכנון מערכות. תרגל פתרון של רוב שאלות הריאיון.
קצר בינוני ארוך
קרא את הנושאים בתכנון מערכות כדי לקבל הבנה כללית של איך מערכות עובדות 👍 👍 👍
קרא כמה מאמרים מתוך בלוגים של חברות שאתה מתראיין אליהן 👍 👍 👍
קרא על כמה ארכיטקטורות מהעולם האמיתי 👍 👍 👍
חזור על איך לגשת לשאלת ריאיון בתכנון מערכות 👍 👍 👍
תרגל שאלות ריאיון בתכנון מערכות עם פתרונות כמה הרבה רוב
תרגל שאלות ריאיון בתכנון מונחה עצמים עם פתרונות כמה הרבה רוב
חזור על שאלות ריאיון נוספות בתכנון מערכות כמה הרבה רוב

איך לגשת לשאלת ריאיון ארכיטקטורה

איך לפתור שאלת ראיון ארכיטקטורה.

ראיון ארכיטקטורה הוא שיחה פתוחה. מצופה ממך להוביל אותה.

אתה יכול להיעזר בצעדים הבאים כדי להנחות את הדיון. כדי לחזק את ההבנה של התהליך, תעבור על שאלות ריאיון בתכנון מערכות עם פתרונות אל מול הצעדים הבאים:

תאר מקרי שימוש, אילוצים והנחות עבודה

אסוף דרישות והגדר את ה-scope של הבעיה. שאל שאלות כדי להבהיר את מקרי השימוש והאילוצים. דון בהנחות העבודה שאתה עושה.

  • מי הולך להשתמש במערכת?
  • איך הם הולכים להשתמש בה?
  • כמה משתמשים יהיו?
  • מה המערכת עושה?
  • מה הקלטים והפלטים של המערכת?
  • בכמה דאטא נצטרך לטפל?
  • כמה בקשות לשניה מחכות לנו?
  • מה היחס הצפוי בין קריאה לכתיבה?

שלב 2: כתוב תכנון במבט על (high level design)

כתוב תכנון high level עם כל הרכיבים החשובים.

  • שרטט את הרכיבים החשובים והקשרים ביניהם
  • תצדיק את הרעיונות שלך

שלב 3: תכנן את הרכיבים המרכזיים

צלול לפרטים של כל רכיב מרכזי. לדוגמה, אם התבקשת לתכנן שירות קיצור כתובות url, דון בנושאים הבאים:

  • יצירה ואחסון hash של ה-url המלא
    • דרכים כמו MD5 ו-Base62
    • התנגשויות hash
    • מסד נתונים SQL או NoSQL
    • סכמת הנתונים
  • המרה של כתובת מקוצרת לכתובת המלאה
    • חיפוש ב-DB
  • תכנון API ותכנון מונחה עצמים

שלב 4: תבצע scale לתכנון

זהה וטפל בצווארי בקבוק, בהתאם לאילוצים. למשל, האם תזדקק לאחד מהפתרונות הבאים כדי להתמודד עם בעיות של סקילביליות?

  • מאזן עומסים (Load balancer)
  • סקיילינג אופקי (Horizontal scaling)
  • שמירה במטמון (Caching)
  • פיצול בסיס נתונים (Database sharding)

דון בפתרונות אפשריים וה-trade-offs. הכול הוא trade-off. התמודד עם צווארי בקבוק בעזרת עקרונות תכנון מערכת סקילבילית.

חישובים "על גב המעטפה" (מהירים)

ייתכן שיבקשו ממך לבצע הערכות באופן ידני. ראה את הנספח עבור המשאבים הבאים:

מקורות לקריאה נוספת

עיין בקישורים הבאים כדי להבין טוב יותר למה לצפות:

שאלות ריאיון תכנון מערכות עם פתרונות

שאלות נפוצות בריאיון ארכיטקטורה עם הסברים לדוגמה, קוד, ודיאגרמות.

הפתרונות מפנים לתוכן שנמצא בתיקיית solutions/.

שאלה פתרון
תכנן את pastebin.com (או bit.ly) פתרון
תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק) פתרון
תכנן web crawler פתרון
תכנן את Mint.com פתרון
תכנן את מבני הנתונים של רשת חברתית פתרון
תכנן אחסון key-value למנוע חיפוש פתרון
תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון פתרון
תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS פתרון
הוסף שאלה לתכנון מערכת תרום

תכנן את pastebin.com (או bit.ly)

צפה בתרגיל ובפתרון

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


תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק)

צפה בתרגיל ובפתרון

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


תכנן web crawler

צפה בתרגיל ובפתרון

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


תכנן את Mint.com

צפה בתרגיל ובפתרון

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


תכנן את מבני הנתונים של רשת חברתית

צפה בתרגיל ובפתרון

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


תכנן אחסון key-value למנוע חיפוש

צפה בתרגיל ובפתרון

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


תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון

צפה בתרגיל ובפתרון

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


תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS

צפה בתרגיל ובפתרון

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


שאלות ריאיון בתכנון מונחה עצמים עם פתרונות

שאלות נפוצות בתכנון מונחה עצמים עם הסברים לדוגמה, קוד, ודיאגרמות.

הפתרונות מפנים לתוכן שנמצא בתיקיית solutions/.

הערה: החלק הזה עדיין בפיתוח

שאלה פתרון
תכנן Hash Map פתרון
תכנן מנגנון Cache בשיטת Least Recently Used פתרון
תכנן מרכז שירות טלפוני (Call Center) פתרון
תכנן חפיסת קלפים פתרון
תכנן חניון פתרון
תכנן שרת צ'אט פתרון
תכנן מערך מעגלי תרום
הוסף שאלה בעיצוב מונחה עצמים תרום

נושאים בתכנון מערכות: התחל כאן

חדש בתחום תכנון מערכות?

ראשית, תצטרך לקבל הבנה בסיסית של העקרונות הנפוצים, ללמוד מה הם, איך משתמשים בהם, מה היתרונות והחסרונות של כל אחד מהם.

שלב 1: צפה בהרצאה על סקילביליות

Scalability Lecture at Harvard

  • Topics covered:
    • Vertical scaling
    • Horizontal scaling
    • Caching
    • Load balancing
    • Database replication
    • Database partitioning

שלב 2: קרא מאמר על סקילביליות

Scalability

השלבים הבאים

בהמשך, נסתכל על trade-offs ב-high level:

  • Performance vs scalability
  • Latency vs throughput
  • Availability vs consistency

נזכור כי הכול זה trade-off. לאחר מכן נצלול לנושאים ספציפיים יותר כמו DNS, CDN ו-load balancers.

ביצועים (performance) מול סקילביליות (scalability)

שירות הוא סקילבילי (scalable) אם הוא משתפר בביצועים (performance) שלו באופן פרופורציונלי למשאבים שנוספו. באופן כללי, שיפור בביצועים פירושו היכולת לתת שירות ליותר יחידות עבודה, אך הוא יכול גם לבוא לידי ביטוי ביכולת להתמודד עם יחידות עבודה גדולות יותר, ככל שהדאטא גדל.1

דרך נוספת להסתכל על ביצועים מול סקילביליות

  • אם יש לך בעיית ביצועים, המערכת איטית עבור משתמש בודד.
  • אם יש לך בעיית סקילביליות, המערכת מהירה עבור משתמש בודד אך איטית בעומס כבד.

מקורות וקריאה נוספת

שיהוי (latency) מול תפוקה (throughput)

שיהוי הוא הזמן שנדרש כדי לבצע פעולה כלשהי או להפיק תוצאה כלשהי

תפוקה היא מספר הפעולות או התוצאות ליחידת זמן.

באופן כללי, כדאי לשאוף לתפוקה מקסימלית עם שיהוי סביר.

חומרים וקריאה נוספת

זמינות (availability) מול עקביות (consistency)

משפט CAP


Source: CAP theorem revisited

במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים:

  • עקביות (Consistency) – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.
  • זמינות (Availability) - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.
  • יכולת חלוקה (Partition Tolerance) - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.

ניתן לצאת מנקודת הנחה שרשתות לא אמינות - כך שנהיה חייבים לתמוך ב-״Partition tolerance״. לכן, נצטרך לבחור אחד משני האחרים - זמינות או עקביות.

בחירה ב-CP - עקביות ויכולת חלוקה

המתנה לתשובה מהמערכת (אשר סובלת מ-network partition) עלולה להסתיים בשגיאת timeout. לכן, CP הוא בחירה טובה במידה ויש הצדקה עסקית לקריאות וכתיבות אטומיות.

בחירה ב-AP - זמינות ויכולת חלוקה

תשובות לבקשות מהמערכת מחזירות את הגרסה הזמינה ביותר של הנתונים הזמינים בשרת הרלוונטי, שאינה בהכרח האחרונה. כתיבה עשויה לקחת זמן מסוים עד שתסתיים, עד אשר התקשורת הבעייתית תיפתר.

לכן, AP הוא בחירה טובה במידה ויש הצדקה עסקית לעבוד במצב של eventual consistency או במידה והמערכת צריכה להמשיך לשרת למרות שגיאות בלתי-תלויות.

חומרים וקריאה נוספת