בסיסי הנתונים
אחד החלקים הכי מרכזיים בשירות, הוא בסיס הנתונים, המקום בו הדאטה שלנו ישמר. אך ישנם הרבה סוגים של בסיסי נתונים, כמו שיש הרבה סוגים של דאטה. וחשוב לבחור את בסיס הנתונים המתאים לדאטה שנשמור.
דיבי אס קיו אל
אינקסים
הדיבי אסקיואל הישן והטוב, אותו כל ילד בכיתה א' מכיר. אני מניח שאתם מכירים את דרך השימוש בו כבר, אבל האם אתם מבינים מה קורה מתחת למכה המנוע? נצלול רגע לארכיטקטורה של בסיס הנתונים ונלמד על עמודים עצים ועוד...אז כן, זה בהחלט מראה יפה להסתכל על איך זה עובד מתחת למנוע.לצפייה
אם הייתם חדים, שמתם לב שאינדקס, המקנה לדיבי יכולת לשלוף את השורה הנכונה מהר מבלי לעבור על כל הטבלה, לאו דווקא חייב להיות המפתח העיקרי של השולחן, אלא הוא יכול להיות כל עמודה בדיבי, ויכולים להיות כמה מהם.
ולכן חשוב מאוד להבין מראש על אילו עמודות נרצה לשלוף בדיבי, ולהגדיר עליהן אינדקס. נצלול לזה קצת יותר עמוק.אז עכשיו אנחנו גם מבינים איך אינדקס עובד. בסרטונים בטח ראיתם ותראו שימוש בלצפייה
EXPLAIN ANALYZE, זהו כלי המפרט באיזה אינדקסים יהיה שימוש בשאילתה. מאוד שימושי.
אוקיי, מה יש עוד לדעת על אינדקסים? נלמד על עוד כמה קונספטים חשובים באינדקסים. וגם, הכי חשוב, למה לא להשתמש באינדקס על כל שורה בדיבי.לצפייה
סטורד פרסיג'ר
תחשבו שיש שאילתה שאתם שולחים בצורה תכופה לדיבי, לא חבל כל פעם לשלוח את כל השאילתה דרך המרשתת? תחשבו על כל הטקסט הזה שעובר... לא חבל על הראוטר? אז מה אם, לא נדרש לשלוח את כל השאילתה כל פעם? כאן נכנס ידידנו, הסטורד פרסיג'ר.לצפייה
אמנם בסרטון השאילתות קצרות יחסית, אבל אני יכול להעיד שאני השתמשתי בפונקציונאליות הזו על שאילתות של עשרות שורות וזה קלף מאוד חשוב בשרוול. הוא נותן לעשות חישובים בלי פינג פונג מיותר עם שרת המאט את התהליך. אך זה גם החיסרון שלו, מכיוון שכחלק מהסטורד פרסיג'ר נוכל לעשות חישובים בתוך הדיבי במקום על השרת עצמו, במידה ומשאבי הדיבי שלנו מצומצמים, זה יכול לגרום ל"האצלת סמכויות חישוב" לבסיס הנתונים מה שיגרום לעומס ואיטיות. ולכן נשתמש בו בתבונה.הסוגים השונים
Postgres,MySql,Mssql, יש הרבה מאוד אימפלמנטציות לדבר היפה הזה שנקראSql. אבל באיזה אחד כדאי לבחור? נעמיק בכתבה המכסה את עשרת הסוגים הכי פופולאריים - לינק.
ועכשיו, ננסה להתאים פרויקטים שונים, לאימפלמנטציה המתאימה ביותר:- חנות אינטרנטית - תעבורה גבוהה, טרנזאקציות (להרחבה), סקייל.
לתשובה
PostgreSQL, אוMssql, במיוחד אם מתכנתים על דוטנט. - אפליקציית פתקים - אחסון מקומי, גודל נתונים נמוך, ללא מקביליות גבוהה.
לתשובה
SQLite - בלוג אינטרנטי - ביצועי קריאה טובים, גודל נתונים נמוך עד בינוני.
לתשובה
MySQL,MariaDB
- חנות אינטרנטית - תעבורה גבוהה, טרנזאקציות (להרחבה), סקייל.
מונגו
בונגו
יוסי - "אס קיו אל זה כזה מסורבל, כל הטבלאות השונות והג'ויינים, אתם יודעים מה אני אוהב הרבה יותר מטבלאות? ג'ייסונים. אני הרי מקבל את המידע ככה בבקשות של הHTTPלמה שאפצל אותו לטבלאות כל פעם מחדש?"
במיוחד בשביל יוסי, אליוט הורוביץ ודוויט מרימן (שהוא גם נהג מירוצים מסתבר) יצרו את מונגו דיבי (או בשמו המקצועי, מונגו בונגו). להלן סרטון שסוקר את כל הבסיס בצורה יסודית.לצפייה
ולחנונים מביננו שרוצים להעמיק בארכיטקטורה,לצפייה
הקרנות
נושא מאוד חשוב שהוזכר בסרטון אבל אדגיש אותו שוב הוא השימוש בProjection. האפשרות לקבל רק שדות ספציפיים היא מאוד חשובה למהירות של המערכת. אשתף במורק,המורק
אני הייתי חלק מפיתוח אתר בו ישנה טבלת ניהול משתמשים, המציגה את שם המשתמש ואת התפקיד שלו. המידע שהגיע לטבלה עבר מהמונגו, לשרת של האתר, לאתר. במסמך המשתמשים שלנו היה מלאאאא מידע, שלא היה רלוונטי לטבלה. בכל פעם שניגשו לטבלה, הקליינט ביקש מהשרת את הנתונים של הטבלה, והשרת העביר לו את הנתונים הרלוונטיים בלבד - שמות המשתמשים, והתפקידים של היוזרים.
וזה היה נורא. לקח לטבלה עשרות שניות לטעון ולא הבנו למה.
התשובה הייתה, כמובן,Projection. אמנם השרת העביר לקליינט רק את הנתונים הרלוונטים, אבל בכל שליפה השרת ביקש מהמונגו את כל מסמך היוזר, ולא רק את שם המשתמש והתפקיד, מה שמאוד הכביד על השליפות, ברגע שהוספנו פרוג'קשן רק על השדות הרלוונטיים, השליפה לקחה כמה מילי-שניות. מאז נשבעתי - תמיד להשתמש בפרוג'קשן!מתי?
אז מתי בעצם עדיף לנו להשתמש בMongoומתי בSql?
Sql- סכמת המידע אינה דינמית.
- ישנם קשרים בין אובייקטים (
Join).
Mongo- סכמת המידע דינמית.
- אין קשרים בין אובייקטים, או כמה שמעט, ונדע מראש איך נשלוף את המידע.
למה זה בעצם חשוב לדעת איך נשלוף את המידע? שוב, אשתף מניסיוני.מנסיוני
כחלק מאותו הפיתוח של האתר היה לנו קולקשן של יוזרים, ושל חיות מחמד. והיה לנו קשר שבו כל יוזר יכול להחזיק חיות מחמד.
למרות שאמנם בסוג הנתונים היו קשרים, קבענו שהקשר קל לתחזור, ותמיד נבדוק איזה חיות מחמד יש ליוזר, ולא איזה בעלים יש לחיית המחמד. ולכן נדרש רק במסמך של היוזר להחזיק רשימה של חיות המחמד ופרטים בסיסיים עליהם, שתשומש לרשימת החיות בדף התצוגה של פרטי היוזר.
אם נרצה לראות את הפרטים המלאים של חיית המחמד, נשלוף על מסמך חיית המחמד. הכל היה טוב ויפה אפילו בנינו מנגנון שאם השם של החיה/פרטים בסיסיים עודכנו זה יעודכן גם במסמך של היוזר - העולם היה נראה מושלם באותו היום. לא צריכים לעשות אףJoinמעצבן, שגם מאט ביצועים.
ואז הגיע הפרודקט.
כמובן שאחרי שהוא הבטיח שלא יצטרכו לראות את כל הבעלים של החיה ממסך החיה, לקוחות העלו את הדרישה הזו, ועכשיו צריך. ואז היינו צריכים לבנות את כל המנגנון הזה מהצד השני, מה שיכול היה להיחסך לגמרי אם היינו משתמשים בSqlעםJoin.
לכן, אם יש איזושהי אי וודאות בנוגע לדרך שליפת המידע, וקיימים קשרים כלשהם, אמליץ בחום להשתמש בSql.DB Sql
רגע מה לא כבר כיסינו דיבי אסקיואל? ומה הקשר למונגו לעזזל? כאן בעצם ארצה לערער אתכם עוד, הידעתם שאפשר לשים עמודתJsonבבסיסי נתונים מסויימים של אסקיואל? אז עכשיו כן. ומנסיוני, זה מאוד שימושי, ובשימוש נכון, זו יכולה להיות הפשרה שתתן כמה שיותר מהטוב מבין שני העולמות.לצפייה
ולחנונים מבנינו, הנה כתבה הבודקת את הביצועים שלJsonבמונגו, אל מול בפוסטגרס - לינק.אלסטיק
המנוע
מה זה אלסטיק? אלסטיק זה כיף. עכשיו נלמד למה זה כיף,לצפייה
בעצם אלסטיק זהו בסיס נתונים, המתמחה בשליפה על כמויות נתונים עצומות, ומתמחה בחיפוש טקסטואלי ואגריגטיבי. שימוש קלאסי בו הוא ללוגים, או לחיפוש טקסטואלי. כל זה נשמע מעולה, אך כמו כל רכיב, חשוב שנבין את החולשות שלו, והנה סרטון הסוקר אותן.לצפייה
השלדה
קיבאנה! קיבאנה היא חלק מהאקוסיסטם של אלסטיק, והיא בעצםUIדרכו נוכל לשלוף על אלסטיק, להכין ויזואליזציות וכו', כך,לצפייה
אם זה עושה בעיות, לחצו על צפייה ביוטיוב.
שימוש נכון בקיבאנה והכנת ויזואליזציות ודאשבורדים מתאימים, יכולים לתת לנו יכולת מדהימה לנתח את הלוגים שלנו ולהבין באמת מה קורה לנו במערכת. כלי מדהים לתחזוקה וניטור.הדלק
אמנם אנחנו יכולים להזין נתונים ישירות לאלסטיק, אבל כלי עזר שיכול לסייע לנו הואLogstashשהינו בעצם כלי לPre Processingמרוכז על המידע שנכניס לאלסטיק.לצפייה
רדיס
רמי
שלום לכולם, היום נכיר את רמי הראם. מי זה? על מנת להכיר אותו, נצלול קצת לאיך זיכרון עובד במחשב.אז כמו שראיתם רמי הראם בעצם מבוסס על "נורות חשמל" שדולקות או כבויות, מה שמאפשר לקריאה ממנו להיות הרבה יותר מהירה. אך בגלל שהוא מבוסס חשמל, אם מכבים אותו, הכל נמחק. ובגלל זה בסיס נתונים לא יאגור נתונים בראם, למרות המהירות שלו.לצפייה
או שכן??ניד פור ספיד
רדיס הוא בסיס נתונים הרץ על הראם, מה שכמו שכבר אמרנו, מקנה לו מהירות גדולה. כמה בדיוק? זה תלוי בנתונים, בסוג האופרציה, ובמחשוב. אבל כמו שתוכלו לקרוא בטרד הזה (לינק) נוכל לאמר שבפניות בסיסיות אל מול מונגו זה בסביבות ה,- פי 2 לכתיבה.
- פי 3 לקריאה.
Cache. עכשיו אחרי כל הדיבורים, איך נשתמש ברדיס?אוקיי עכשיו שהבנו איך להשתמש ברדיס, נבחן יותר לעומק את השימושים האפשריים שלו,לצפייה
הדוגמא מדקה 13 היא רשות לצפייה מבחינתי, אבל היא כן יכולה להראות איך רדיס באמת משתלב כקאש באפליקציה.מקווה ששמתם לב ללצפייה
Distributed Lockזה כלי מאוד חשב כשרוצים להשיגThread Safetyבאפליקציה שרצה על כמה נודים.שיקרתי
אמנם המידע ברדיס נשמר על הראם, ולכן במקרה שהשרת נופל הכל ימחק, אבל ישנם מנגנונים המאפשרים לכך שהמידע ישאר.בעצם, יכולת זו מאפשרת לנו לשמור פרטי מידע קבועים ברדיס בלי לחשוש שהם יימחקו. כמו למשל הודעות כניסה למערכת וכו'. ואם אנחנו מאוד אמיצים, אפילו להשתמש ברדיס כדיבי ראשי.לצפייה
לואה
זוכרים את הסטורד פרסיג'ר בSql? אז יש משהו כזה גם ברדיס. קוראים לו לואה סקריפט, וכמו שמה, זה יכול מאוד לייעל את המערכת. ללמידה - לינק.
שארדינג
הבסיס
לי יש שרת, על השרת יש לי 100 גיגה של אחסון. על אותו השרת התקנתי תוכנת דיבי, והוא מתפקד כבסיס הנתונים שלי. אוקיי, הכל טוב ויפה, אבל מה קורה כשנגמר לי המקום באחסון? אני יכול לשדרג את השרת ל200 ג'יגה אבל בסופו של דבר יש גבול לכמה אחסון שרת אחד יכול להכיל... אז מה עושים? נפצל לשארדים.
אפשר לקחת שרת נוסף, עם 100 ג'יגה, ולגרום להם לעבוד ב"עבודת צוות" , שיש לה עוד הרבה מאוד יתרונות, כך,
לצפייה
אמנם הסרטון מתמקד בSql אבל המנגנון דומה בכל בסיסי הנתונים. תפעול השארדינג יכול להיעשות בשלוש תצורות:
- האפליקציה - האפליקציה תדע לאיזה שארד לגשת לפי חוקי החילוק לשארדים, למשל
shard_id = user_id % 4. - פרוקסי - פרוקסי או מידלוור שינווט את הפקודות, לדוגמא עבור
PostgresהשירותCitus. - הדיבי - בבסיסי נתונים מסויימים אפשרויות לשארדינג בנויות מראש, כמו
ElasticSearchאוCockroachDB.
לרוב נעדיף מוצרים עם שארדינג מובנה בתוך הדיבי, מהסיבה הפשוטה שזה הכי חלק, ודורש הכי פחות עבודה.
כעת, נעשה צלילה קלה לכמה אימפלמנטציות של שארדינג. אדגיש כי בSql האימפלמנטציה לא זהה בכל סוג מיישם, ולכל אחד התכונות שלו בנוגע לשארדינג.
דוגמאות
נתחיל ממונגו,
לצפייה
וכמובן איך נוותר על CockroachDB.
לצפייה
ונסיים עם ביס טוב מRedis.
לצפייה
וזהו
יש עוד אינסוף דברים להבין בבסיסי נתונים, ואני מעודד אתכם לחקור עוד הרבה יותר לעומק, אבל זה די והותר להבנת אפשרויות בסיסי הנתונים הקיימות.
אין תגובות:
הוסף רשומת תגובה