From 9b073c6c4140bb184e34120382e1e0166fff8f0b Mon Sep 17 00:00:00 2001 From: Roy Mayan <> Date: Sat, 14 Jun 2025 21:08:27 +0300 Subject: [PATCH] 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/טרנזקציה_(בסיס_נתונים)) במסדי נתונים רלציוניים: + + + +ישנן טכניקות רבות להגדלת (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 + + + +--- + +#### שכפול Master-Master + +שני ה-masters משרתים קריאה וכתיבה (RW) ומתאמים אחד עם השני את הכתיבות. אם אחד מהם נופל, המערכת יכולה להמשיך לתפקד במצב של קריאה וכתיבה. + +

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

+ +##### חסרונות: Master-Master + + + +##### חסרונות: Replication (כללי) + + + +##### מקורות וקריאה נוספת: 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. + +##### חסרונות: פדרציה + + + +##### מקורות וקריאה נוספת: פדרציה + +- [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 + + + +###### מקורות וקריאה נוספת + +- [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 מורכב ויקר, מה שעולה בביצוע פעולות דיסק זמן רב. + +##### חסרונות: דנורמליזציה + + + +###### מקורות וקריאה נוספת + +- [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** כדי לדמות עומסים ולגלות צווארי-בקבוק. + + + +התוצאות של השימוש בכלים אלו עשויה להוביל לאופטימיזציות הבאות: +##### הידוק הסכימה (Tighten up the schema) + + + +##### השתמש באינדקסים טובים (Use good indices) + + + +##### מניעת JOIN יקר + + + +##### חלוקה לטבלאות (Partitioning) + + + +##### כוונון 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) + +