[השמעת מוסיקה] ריק הוליהאן: בסדר. היי כולם. שמי ריק הוליהאן. אני מנהל בכיר אדריכל פתרונות בAWS. אני מתמקד בNoSQL ו טכנולוגיות DynamoDB. אני כאן היום כדי לדבר איתי אתה קצת על אלה. 

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

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

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

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

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

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

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

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

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

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

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

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

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

וזה אכן קרה ב -1880. יָמִינָה? בשנת 1880 מפקד אוכלוסין של ארה"ב. זה באמת שבו מפנה להצביע עיבוד נתונים מודרני. זוהי הנקודה ב אשר את כמות הנתונים שנאסף על ידי ממשלת ארה"ב הגיעה לנקודה ש שבו לקח שמונה שנים כדי לעבד. 

עכשיו, שמונה years-- כ אתה יודע, המפקד ריצות כל 10 years-- אז זה די ברור שעל ידי זמננו קיבלתי את המפקד 1890, כמות הנתונים ש הולך להיות מעובד על ידי הממשלה הייתה הולך תעלה 10 השנים ש אקח להשיק את המפקד החדש. זו הייתה בעיה. 

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

אז יבמ במקור היה ב עסק מסד הנתונים. וזה באמת מה שהם עשו. הם עשו עיבוד נתונים. 

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

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

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

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

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

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

ושנמשך כ -20 או 30 שנים עד האבולוציה של מסדי נתונים היחסיים, ש כאשר העולם החליט שאנחנו עכשיו צריך מאגר שמביס ההתפשטות של נתונים בקובץ מערכות שבנינו. יָמִינָה? יותר מדי נתונים מבוזרים במדי מקומות, ביטול הכפילות של נתונים, ואת העלות של אחסון הייתה עצומה. 

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

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

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

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

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

וככלל אצבע days-- אלה אם אתה הולך Google-- 90% מהנתונים ש אנו מאחסנים היום, וזה היה נוצר בשנתיים האחרונות. אוקיי. עכשיו, זה לא מגמה שחדשה. זוהי מגמה שהייתה יוצא במשך 100 שנים. מאז הרמן הולרית ' פיתח את כרטיסי הניקוב, אנחנו כבר בונים מאגרי נתונים ואיסוף נתונים בקצבים מדהימים. 

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

אם עסק בשנת 2010 היה אחד טרה-בייט של נתונים תחת ניהול, היום שאומר שהם ניהול 6.5 פטה-בייט של נתונים. זה 6,500 פעמים יותר נתונים. ואני יודע את זה. אני עובד עם עסקים אלה בכל יום. לפני חמש שנים, אני אדבר עם חברות שהיה מדבר איתי על מה כאב זה הוא לנהל טרה של נתונים. והם היו מדברים איתי על איך שאנחנו רואים שזה כנראה הולך להיות petabyte או שתיים בתוך כמה שנים. 

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

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

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

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

אז אחד הדברים אנחנו מסתכלים כמדוע NoSQL? איך NoSQL אין לפתור את הבעיה הזו? ובכן, מסדי נתונים יחסיים, שפת שאילתות מובנית, SQL-- זה באמת מבנה של יחסי database-- הדברים האלה הם מותאם לאחסון. 

חזרה בשנתי ה -70, שוב, הדיסק הוא יקר. תרגיל ההקצאה של אחסון בעסק שלא נגמר. אני יודע. אני חייתי את זה. כתבתי אחסון מנהלי התקנים עבור חברת superserver enterprised חזרה בשנתי ה -90. והשורה התחתונה היא צוברות עוד מערך אחסון היה פשוט משהו ש קרה כל יום במפעל. וזה לא הפסיק. אחסון צפיפות גבוה יותר, ביקוש לאחסון בצפיפות גבוה, ולאחסון יעיל יותר מכשירים שזה אף פעם לא הפסיק. 

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

וזה מה שאנחנו מקבלים ב מסדי נתונים היחסיים. זה מותאם לאחסון. זה מנורמל. זה יחסי. הוא תומך בשאילתות אד-הוק. וזה וזה מאזניים אנכי. 

אם אני צריך לקבל מסד נתונים SQL גדול או מסד נתונים SQL חזק יותר, אני הולך לקנות חתיכת הברזל גדולה יותר. אוקיי? אני כבר עובד עם הרבה לקוחות שעבר שדרוגים משמעותיים בתשתית של SQL שלהם רק כדי לגלות שישה חודשים מאוחר יותר, הם פגעו בקיר שוב. והתשובה של אורקל או MSSQL או כל אחד אחר הוא לקבל תיבה גדולה יותר. ובכן מוקדם או במאוחר, אתה לא יכול לקנות תיבה גדולה, וזה בעיה אמיתית. אנחנו צריכים לשנות דברים באמת. אז איפה זה עובד? זה עובד גם למחובר ניתוח, עומסי עבודה OLAP-סוג. וזה באמת שבו SQL שייך. עכשיו, הוא משמש היום בהרבה באינטרנט עיבוד מסוג עסקות יישומים. וזה עובד בסדר גמור ב רמה מסוימת של ניצול, אבל זה פשוט לא בקנה מידה הדרך שNoSQL עושה. ונדבר קצת קצת על למה זה. 

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

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

אז זה באמת בנוי לאינטרנט עיבוד עסקה והיקף. יש הבדל גדול כאן בין הדיווח, נכון? הדיווח, אני לא יודע שאלות שאני הולך לשאול. יָמִינָה? Reporting-- אם מישהו מ מחלקת השיווק שלי רוצה פשוט- כמה מהלקוחות שלי יש מאפיין המסוים הזה ש קנה בday-- זה אני לא יודע מה שאילתה שהם הולכים לשאול. אז אני צריך להיות אגנוסטי. 

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

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

אז אתה שומע על זה הרבה. זה אילוץ משולש, משולש של אילוץ משולש, או משולש הברזל הוא oftentimes-- כאשר אתה מדבר עם מנהלי פרויקטים, הם ידברו על זה. עכשיו, יש לי מאגרי מידע משולש הברזל שלהם. והמשולש הברזל של נתונים הוא מה שאנחנו מכנים משפט CAP. אוקיי? 

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

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

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

מסדי נתונים יחסיים אז choose-- אתה יכול להרים שני אלה. אוקיי. מסדי נתונים יחסיים אז לבחור להיות עקבי וזמין. אם המחיצה קורה בין DataNodes במאגר הנתונים, מסד נתוני קריסות. יָמִינָה? זה פשוט יורד. אוקיי. 

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

וזה מה שמסדי נתוני NoSQL לעשות. בסדר. אז מסד נתונים NoSQL, זה מגיע בשני טעמים. יש לנו-- טוב, זה מגיע בטעמים רבים, אבל זה מגיע עם שני בסיסי characteristics-- מה היינו קוראים למסד נתוני CP, או סובלנות עולה בקנה אחד ומחיצה מַעֲרֶכֶת. החבר'ה האלה לעשות את הבחירה שכאשר בלוטות לאבד קשר אחד עם השני, אנחנו לא מתכוונים לאפשר ל אנשים לכתוב יותר. אוקיי? 

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

הטעם הבא יהיה מערכת AP, או למחיצות זמינות ו מערכת סובלנות. לא אכפת לי החבר'ה האלה. יָמִינָה? כל צומת שמקבלת לכתוב, אנחנו ניקח אותו. אז אני משכפלים את הנתונים שלי על פני צמתים מרובים. בלוטות אלה מקבלים הלקוח, הלקוח מגיע ב, אומר, אני הולך לכתוב כמה נתונים. צומת אומרת, אין בעיה. הצומת לידו מקבל כתיבה על אותו השיא, הוא הולך להגיד לא בעיה. אי שם בקצה האחורי, נתונים שהולכים לשכפל. ואז מישהו הולך לממש, אוי, מערכת שהם יבינו, אה-אה, יש כבר עדכון לשני צדדים. מה אנחנו עושים? ומה הם עושים אז הוא הם עושים משהו ש מאפשר להם להחליט כי מדינת נתונים. ונדבר על כי בתרשים הבא. 

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

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

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

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

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

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

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

מצד השני, יש לנו מה שנקרא טכנולוגית BASE. ואלה הם מאגרי NoSQL שלך. בסדר. אז יש לנו CP שלנו, מסדי נתונים AP. ואלה הם מה שאתה קורא בעצם זמינה, מדינה רכה, סופו של דבר עִקבִי. אוקיי? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אז אנחנו הולכים להיכנס לDynamoDB. DynamoDB הוא AWS של באופן מלא בניהול פלטפורמת NoSQL. מה באופן מלא בניהול מתכוון? זה אומר שאתה לא צריך באמת לדאוג לשום דבר. 

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

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

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

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

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

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

עכשיו אני אלך דרך כמה מאלה להשתמש במקרים אחדות כאן דקות. control-- גישה משולבת יש לנו מה שאנו מכנים ניהול זהויות גישה, או IAM. זה מחלחל לכל מערכת, כל שירות שמציע AWS. DynamoDB הוא לא יוצא מן הכלל. אתה יכול לשלוט בגישה לשולחנות DynamoDB. בכל AWS שלך חשבונות על ידי הגדרת תפקידים והרשאות גישה בתשתית IAM. 

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

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

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

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

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

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

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

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

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

API האחר שיש לנו הוא מה שאנו מכנים API הזרמים שלנו. אנחנו לא הולכים לדבר יותר מדי הרבה על זה עכשיו. יש לי כמה תוכן מאוחר יותר על הסיפון על זה. אבל זרמים הוא באמת running-- חושב על זה כעל הזמן הזמין ושינוי מחיצת יומן. כל מה שקורה ב השולחן מופיע על הזרם. 

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

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

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

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

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

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

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

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

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

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

מפתחות מגוון לאפשר חשיש me-- מפתחות צריכים להיות שוויון. כששאילתא חשיש, אני חייב לומר תן לי חשיש ששווה את זה. כששאילתא טווח, אני יכול להגיד לי טווח כי הוא משתמש בכל סוג של מפעיל עשיר שאנו תומכים. תן לי את כל הפריטים לחשיש. האם זה שווה, גדול יותר מ, פחות מ, הוא מתחיל עם, זה קיים בין שני הערכים האלה? אז אלו סוגים של שאילתות טווח שאנחנו תמיד מתעניינים ב. עכשיו דבר אחד על נתונים, כאשר אתה מסתכל על הגישה לנתונים, כאשר אתה ניגש לנתונים, זה תמיד על צבירה. זה תמיד על רשומות הקשורים לזה. תן לי כל מה שכאן that's-- כל העסקות בכרטיס אשראי זה בחודש האחרון. זה צבירה. 

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

אז הדבר האחר מפתח החשיש עושים זה נותן לנו מנגנון כדי להיות מסוגל להפיץ את הנתונים בסביבה. מסדי נתונים NoSQL עבודה הטובים ביותר כאשר הנתונים הוא באופן שווה מופץ ברחבי האשכול. כמה אנשים מכירים עם hashing אלגוריתמים? כשאני אומר חשיש וhashing-- כי אלגוריתם hashing היא דרך של להיות מסוגל ליצור ערך אקראי מכל ערך נתון. אז במקרה הספציפי הזה, אלגוריתם hash אנחנו רצים הוא ND 5 מבוססים. 

ואם יש לי תעודת זהות, וזה הוא מפתח החשיש שלי, יש לי 1, 2, 3. כאשר אני מפעיל את אלגוריתם החשיש, זה הולך לחזור ולומר, גם 1 שווה 7 ב, 2 שווה 48, 3 שווים CD. הם התפשטו בכל רחבי החלל המרכזי. ולמה אתה עושה את זה? מכיוון שמוודא שאני יכול לשים את הרשומות פני צמתים מרובים. 

אם אני עושה את זה בהדרגה, 1, 2, 3. ויש לי מגוון חשיש ש ריצות במקרה המסוים הזה, חלל חשיש קטן, זה יוצא ממ 00 ל FF, אז את הרשומות הולכים לבוא ב והם הולכים ללכת 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. מה קורה? כל הוספה הולכת לאותו צומת. אתה מבין למה אני מתכוון? 

כי כשאני לפצל את השטח, ופרשתי רשומות אלה על פני, ואני מחיצה, אני הולך להגיד יש מחיצה 1 מרחב מפתח 0-54. מחיצה 2 היא 55-89. מחיצה 3 היא AA לFF. אז אם אני משתמש באופן ליניארי הגדלה מזהים, אתה יכול לראות מה קורה. 1, 2, 3, 4, 5, 6, כל הדרך עד 54. אז כמו שאני פטיש רשומות במערכת, כל מה שסופו של דבר הולך לצומת אחד. 

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

קהל: האם שA9 169 בעשרוני? 

ריק הוליהאן: כן, זה בערך שם. A9, אני לא יודע. היית צריך לקבל בינארי שלי למחשבון עשרוני. המוח שלי לא עובד כמו ש. קהל: רק אחד מהיר הערות Mongo. אז הוא מזהה האובייקט שמגיע באופן מקורי עם Mongo לעשות את זה? ריק הוליהאן: האם זה עושה את זה? אם תציין את זה. עם MongoDB, יש לך האפשרות. אתה יכול specify-- כל מסמך ב MongoDB יש לי מזהה תחתון. זה הערך הייחודי. 

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

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

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

החשיש מגדיר את ההורה, מגוון מגדיר את הילדים. אז אתה יכול לראות שיש כאן אנלוגי בין המבנה היחסי ואת אותם סוגים בונה בNoSQL. אנשים מדברים על NoSQL כnonrelational. זה לא nonrelational. תמיד יש נתונים מערכות יחסים. יחסים אלה רק הם מודל שונה. בואו נדבר קצת קצת על עמידות. כשאתה כותב לDynamoDB, כותב תמיד משולש משוכפל. כלומר, יש שלושה AZ שלנו. AZ שלהם אזורים זמינות. אתה יכול לחשוב על זמינות אזור כמרכז נתונים או אוסף של מרכזי נתונים. הדברים האלה הם מבחינה גיאוגרפית מבודד זה מזה על פני אזורים שונים באשמה, על פני שונה רשתות חשמל וfloodplains. כישלון באחד מאלף עד תו לא הולך לקחת את זה. הם גם מקושרים יחד עם סיבים כהים. הוא תומך במשנה אחת 1 חביון אלפית השנייה בין AZS. אז משוכפלי נתונים בזמן אמת מסוגלים. בAZS רבת 

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

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

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

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

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

מה הכוונה? יש לי תכונה אחת שאני יכול להריץ שאילתות עשירות נגד. זה מפתח מגוון. תכונות אחרות על item-- ש אני יכול לסנן בתכונות אלה. אבל אני לא יכול לעשות דברים כמו, זה מתחיל עם, או גדול מ. 

איך אני עושה את זה? אני יוצר מדד. יש שני סוגים של מדדים בDynamoDB. מדד הוא באמת מבט אחר של השולחן. והמדד המשני המקומי. 

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

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

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

יש לי אלה השפעה הגבלת מרחב מפתח החשיש שלך. כי הם ישתפו קיימים- באותו צומת האחסון, הם מגבילים את מפתח החשיש חלל עד 10 ג'יגה. DynamoDB, תחת שולחנות, יהיו חלוקה השולחן שלך כל 10 ג'יגה בייט. כאשר אתה שם את 10 הופעות של נתונים ב, אנחנו ללכת [PHH], ואנו מוסיפים צומת נוספת. 

אנחנו לא לפצל את LSI על פני מספר מחיצות. אנחנו לפצל את השולחן. אבל אנחנו לא לפצל את LSI. אז זה משהו חשוב להבין הוא אם אתה עושה מאוד, מאוד, מצבורים גדולים מאוד, אז אתה הולך להיות מוגבל עד 10 ג'יגה בייט ביחטיף להן?. 

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

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

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

קהל: [לא ברור] מפתח --table התכוון היה חשיש? החשיש המקורי? רב-שלבים? 

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

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

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

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

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

אז אני עובד עם כמה מ החבר'ה האלה שסובלים בגלל שהם יוצרים מצבורים ginormous אלה במדדים המשניים שלהם. אולי יש להם חלקי גלם שולחן שמגיע כחשיש בלבד. כל חלק יש מספר סידורי ייחודי. אני משתמש במספר הסידורי כחשיש. זה יפה. טבלת נתוני הגלם שלי היא להפיץ בכל רחבי החלל המרכזי. שֶׁלִי [? לִכתוֹב ?] [? בליעה?] היא מדהימה. אני לוקח הרבה נתונים. אז מה שהם עושים הוא שהם יוצרים GSI. ואני אומר, אתה יודע מה, אני צריך לראות כל החלקים ליצרן זה. ובכן, פתאום אני לוקח מיליארדים שורות, ודבריהם על צומת אחד, כי כש אני מצרפים כ זיהוי יצרן כחשיש, ומספר חלק כטווח, אז פתאום אני לשים מיליארדים חלקים למה יצרן זה סיפק אותי. 

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

בסדר, אז GSI של LSI של,, אשר אחד כדאי לי להשתמש? LSI של עולים בקנה אחד. GSI שלהם סופו של דבר עולה בקנה אחד. אם זה בסדר, אני ממליץ להשתמש GSI, שהם הרבה יותר גמישים. LSI של יכול להיות מודל כGSI. ואם גודל הנתונים למפתחות חשיש ב האוסף שלך עולה על 10 ג'יגה בייט, אז אתה הולך רוצה להשתמש בזה GSI כי זה פשוט מגבלה קשה. 

בסדר, אז קנה המידה. תפוקה בדינמו DB, הפרשה יכול [לא ברורה] תפוקה לשולחן. יש לנו לקוחות שיש לי הקצאת 60 billion-- עושים 60 מיליארדים בקשות, באופן קבוע פועל בלמעלה ממיליון בקשות לשנייה על השולחנות שלנו. באמת אין גבול תיאורטי לכמה וכמה מהר השולחן יכול לרוץ בדינמו DB. יש כמה רך מגבלות על החשבון שלך שאנחנו מכניסים לשם כך כי אתה לא להשתגע. אם אתה רוצה יותר מ כי, לא בעיה. אתה בא לספר לנו. אנחנו נהפוך את החיוג. 

כל חשבון מוגבל לרמה מסוימת בכל שירות, רק את הבת כך האנשים לא להשתגע לקבל את עצמם בצרות. אין גבול בגודל. אתה יכול לשים את כל מספר של פריטים על שולחן. הגודל של פריט הוא מוגבל ל -400 קילו-כל, זה יהיה פריט לא התכונות. אז הסכום של כל התכונות מוגבל ל- 400 קילו-בתים. ואז שוב, יש לנו נושא LSI שקטן עם המגבלה של 10 ג'יגה בייט לחשיש. קהל: מספר קטן, חסר לי מה שאתה אומר לי, שהוא-- קהל: הו, קילובייט 400 הוא בגודל המקסימאלי לכל פריט. אז יש פריט כל התכונות. אז 400 k הוא הגודל הכולל של פריט ש, 400 קילובייט. אז כל התכונות שילוב, את כל הנתונים זה בכל התכונות האלה, מגולגל לגודל כולל, כיום היום מגבלת הפריט היא 400 k. אז דרוג שוב, השיג באמצעות מחיצות. התפוקה מוקצה ברמת השולחן. ויש באמת שתי ידיות. יש לנו יכולת לקרוא ולכתוב קיבולת. 

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

שוב, מותאם באופן בלתי תלוי זה בזה. ויש להם את throughput-- אם אתם צורכים של RCU שלך 100%, אתה לא הולך להשפיע על זמינות של הזכויות שלך. אז הם לגמרי תלוי זו בזו. בסדר, אז אחד הדברים ש הזכרתי בקצרה היה ויסות. ויסות היא רעה. ויסות מציינת רעה לא SQL. יש דברים שאנחנו יכולים לעשות כדי לעזור לך להקל על הוויסות ש חווים. אבל הפתרון הטוב ביותר לזה הוא בואו ניקח להסתכל על מה שאתה עושה, כי יש אנטי-דפוס במשחק כאן. 

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

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

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

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

אז הכחול הוא נחמד. אנחנו אוהבים כחולים. אנחנו לא אוהבים אדומים. שבו הלחץ של רד מקבל עד 100%. 100%, עכשיו אתה הולך להיות חנוק. אז בכל פעם שאתה רואה כל קווים אדומים כמו זה-- וזה לא רק דינמו DB-- לכל מסד נתונים NoSQL בעיה זו. יש אנטי-דפוסים שיכולים לנהוג סוגים אלה של תנאים. מה שאני עושה הוא שאני עובד עם לקוחות כדי להקל על תנאים אלה. 

ומה זה נראה? וזה הוא מקבל ביותר מתוך תפוקת דינמו DB, אבל זה באמת מקבל את המרב של NoSQL. זו אינה מוגבלת לדינמו. זה אני ספק-- בעבר עבד בMongo. אני מכיר את פלטפורמות NoSQL רבות. לכל אחד מסוגים אלה בעיות מקש חמות. כדי להשיג את המרב מכל NoSQL מסד הנתונים, במיוחד דינמו DB, אתה רוצה ליצור טבלאות שבו יש המרכיב המרכזי חשיש מספר גדול של ערכים שונים, רמה גבוהה של cardinality. כי זה אומר שאני כותב להרבה דליים שונים. 

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

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

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

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

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

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

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

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

החבר'ה האלה מעשה-- הם אלה הבחורים. אני לא בטוח אם זה החבר'ה האלה. יכול להיות הבחורים האלה. בעיקרון אמרתי לי us-- לא, אני לא חושב שזה היה להם. אני חושב שזה היה מישהו אחר. אני עובד עם לקוחות שאמרו לי כי עכשיו שיש להם הלכנו לדינמו DB, הם לבזבז יותר כסף על חטיפים ל צוות הפיתוח שלהם בכל חודש ממה שהם מוציאים על מסד הנתונים שלהם. אז זה ייתן לך רעיון של החיסכון בעלויות כי אתה יכול לקבל בדינמו DB הוא עצום. בסדר, dropcam של חברה אחרת. בחור אלה של עצם-- אם אתה חושב של אינטרנט של דברים, dropcam הוא בעצם וידאו אבטחה באינטרנט. אתה שם את המצלמה שלך בחוץ. יש מצלמה גלאי תנועה. מישהו מגיע, מפעיל נקודת קיו. מצלמה מתחילה להקליט במשך זמן עד ש זה לא לזהות כל תנועה יותר. מעביר וידאו שלמעלה באינטרנט. 

Dropcam הייתה חברה ש בעצם עבר לדינמו DB כי הם חווים כאבי גדילה עצום. ומה שהם אמרו לנו, פתאום פטה-בייט של נתונים. היה להם מושג השירות שלהם יהיה כל כך מוצלח. עוד וידאו הנכנס מאשר YouTube זה מה שהחבר'ה האלה מקבלים. הם משתמשים בDynamoDB לעקוב אחר כל מטה בכל נקודות מפתח הווידאו שלהם. 

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

דינמו DB מפחית זמן אספקה ​​לאירועי וידאו מחמש עד 10 שניות. בחנות היחסי הישנה שלהם, הם משמשים לצריכים ללכת ולבצע שאילתות מורכבות מרובות לדמות אילו קטעי וידאו לניתץ, פחות מ 50 אלפיות שנייה. אז זה מדהים, מדהים כמה ביצועים אתה יכול לקבל בעת לייעל ו לך לכוון את מסד הנתונים שבבסיס כדי לתמוך בדפוס הגישה. אבן ניגף, החבר'ה האלה, מה זה, פירות הנינג אני מניח שזה הדבר שלהם. שכל הריצות על דינמו DB. והבחורים האלה, הם נהדרים צוות פיתוח, פיתוח גדול לִקְנוֹת. 

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

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

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

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

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

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

אז שבנה סוג של לשולחן בדינמו DB. כאשר אני מגדיר את חשיש ושולחן לא מגוון, אני הגדרה אחת ליחסים רבים. זה יחסי הורה-ילד. 

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

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

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

כנראה אני לא הולך לבזבז יותר הרבה זמן מדבר על מסמכים. זה מקבל קצת, כנראה, עמוק יותר ממה שאנחנו צריכים ללכת ל. בואו נדבר קצת ביטוי שאילתא על עשיר. אז בדינמו DB יש לנו היכולת ליצור מה שאנו מכנים ביטויי הקרנה. ביטויי הקרנה הם פשוט לקטוף את השדות או הערכים שברצונך להציג. אוקיי, אז אני עושה את בחירה. אני עושה שאילתא נגד דינמו DB. ואני אומר, אתה יודע מה, מופע שלי רק חמש ביקורות הכוכב למוצר המסוים הזה. כך שכל מה שאני רוצה לראות. אני לא רוצה לראות את כל תכונות אחרות של השורה, אני רק רוצה לראות את זה. זה בדיוק כמו ב- SQL כאשר אתה אומר כוכב נבחרים או משולחן, אתה מקבל הכל. כשאני אומר שם בחר מ שולחן, אני מקבל רק תכונה אחת. זה אותו הסוג של דבר ב דינמו DB או מסדי נתונים NoSQL אחר. ביטויי מסנן יאפשר לי בעצם לחתוך את התוצאה שנקבעה. אז אני עושה את שאילתא. שאילתא עשויה לחזור עם 500 פריטים. אבל אני רוצה רק את הפריטים ש יש תכונה שאומרת את זה. אוקיי, אז בואו לסנן פריטים אלה שאינו תואם את השאילתה מסוימת. אז יש לנו ביטויי מסנן. 

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

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

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

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

קהל: ומסנן ביטוי בעצם אומר לא במספר או not-- 

[חציצת קולות] ריק הוליהאן: אני לא מקבל יותר מדי לזה. זוהי מילת המפתח שמורה. צפה בלירה שמורה מילת המפתח בדינמו DB. לכל מסד הנתונים שלה שמורות שמות לאוספים שאתה לא יכול להשתמש. דינמו DB, אם תציין ליש"ט מול זה, אתה יכול להגדיר את השמות האלה למעלה. זהו ערך הפניה. זה כנראה לא התחביר הטוב ביותר יש שם למעלה לדיון הזה, כי זה נכנס לכמה real-- אני היה מדבר יותר על זה ברמה עמוקה יותר. 

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

והראשון שאנחנו הולכים דיבורים על זה באינטרנט של דברים. אז אנחנו מקבלים הרבה ל-- אני מניח, מה הוא יותר מ -50% it-- תנועה באינטרנט בימים אלה למעשה נוצר על ידי מכונות, תהליכים אוטומטיים, לא על ידי בני אדם. אני מתכוון דבר זה הדבר הזה ש אתה נושא בכיס שלך, כמה נתונים שהדבר שהוא שליחה סביב למעשה בלעדיך בידיעה שזה היא בהחלט מדהימה. המיקום, המידע שלך על כמה מהר אתה הולך. איך אתה חושב שעבודות ב- Google Maps כשהם אומרים לך מה היא התנועה. זה בגלל שיש מיליון ו מיליוני אנשים בנהיגה עם טלפונים ששולחים הנתונים בכל רחבי מקום כל הזמן. אז אחד הדברים על סוג זה של נתונים שמגיע ב, נתוני צג, להיכנס נתונים, נתונים סדרת זמן, הוא שזה בדרך כלל מעניין רק לקצת זמן. לאחר הזמן, זה לא כל כך מעניין. אז דיברנו על, לא נותנים לי שולחנות אלה לגדול ללא גבולות. הרעיון כאן הוא שאולי יש לי 24 שעות בשווי של אירועים בשולחן החם שלי. ושהשולחן חם הולך להיות הקצאה בשיעור גבוה מאוד, כי זה לוקח הרבה נתונים. זה לוקח הרבה נתונים ובאני קוראת את זה הרבה. יש לי הרבה פעולה שאילתות פועלות נגד הנתונים ש. 

לאחר 24 שעות, היי, אתה יודע מה, לא אכפת לי. אז אולי כל אני רול חצות השולחן שלי מעל לשולחן חדש ואני deprovision טבלה זו. ואני אקח ושל RCU מטה של ​​WCU כי 24 שעות מאוחר יותר אני לא רצתי רב שאילתות מול הנתונים. אז אני הולך לחסוך כסף. ואולי 30 ימים לאחר מכן אני לא אפילו צריך לדאוג לגבי כל זה. אני יכול לקחת את WCU של כל הדרך למטה לאחד, כי אתה יודע מה, זה אף פעם לא הולך לקבל בכתב ל. הנתונים הוא בן 30 ימים. זה לא משנה. 

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

בואו הרבה יותר טוב לעצב את הבקשה שלך כך שאתה יכול לפעול בדרך זו נכונה. אז זה רק אוטומטי בקוד היישום. בחצות בכל לילה הוא מתגלגל לשולחן. אולי מה שאני צריך זה זזים חלון של 24 שעות של נתונים. אז על בסיס קבוע אני קוראים נתונים מהשולחן. אני זמירה אותו עם cron עבודה ואני שם את זה על שולחנות אחרים אלה, כל מה שאתה צריך. אז אם גלגול עובד, זה נהדר. אם לא, לקצץ אותו. אבל בואו נשמור שהנתונים חמים מהנתונים הקרים שלך. זה יחסוך לכם הרבה כסף ו להפוך את השולחנות שלך יותר ביצועים. אז הדבר הבא שאנחנו נדבר עליו הוא קטלוג מוצרים. קטלוג מוצרים מקרה שימוש די נפוץ. זהו למעשה דפוס נפוץ מאוד שנראה במגוון רחב של דברים. אתה יודע, טוויטר ל למשל, ציוץ חם. מגיע לכולם ו תופס ציוץ ש. קטלוג מוצרים, יש לי מכירה. יש לי מכירה חמה. יש לי 70,000 בקשות ל שני מגיע למוצר תיאור מתוך קטלוג המוצרים שלי. אנחנו רואים את זה בהקמעונאי פעולה לא מעט. אז איך אנחנו מתמודדים עם זה? אין דרך להתמודד עם זה. כל המשתמשים שלי רוצים לראות אותה פיסת המידע. הם באים במקביל. וכולם עושים את בקשות לאותה פיסת המידע. זה נותן לי שמקש חם, שאדום גדול פס על התרשים שלי שאנחנו לא אוהבים. וזה מה שזה נראה כמו. אז על פני שטח המפתח שלי אני מקבל מרוקע בפריטים למכירה. אני מקבל שום דבר בשום מקום אחר. 

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

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

זוהי דוגמא טובה למדי. יש לנו איזה שולחן הודעות. ויש לנו תיבת הדואר הנכנס ודואר יוצא. זה מה שהיית עושה SQL נראה כמו לבנות תיבת הדואר הנכנס ש. אנחנו סוג של להשתמש באותו סוג אסטרטגיה להשתמש GSI של, GSI של לתיבת הדואר הנכנס שלי והדואר היוצא שלי. אז יש לי הודעות גלם הקרובות לשולחן ההודעות שלי. והגישה הראשונה לזה יכול להיות, אומר, בסדר, אין בעיה. יש לי הודעות גלם. הודעות מגיעות [לא ברור], ההודעה ID, זה נהדר. זה החשיש הייחודי שלי. אני הולך ליצור שני GSI של, אחד לתיבת הדואר הנכנס שלי, אחד לתיבת הדואר היוצא שלי. והדבר הראשון שאני אעשה הוא אני אגיד מפתח החשיש שלי הוא הולך להיות הנמען ו אני הולך לארגן במועד. זה פנטסטי. יש לי הנוף היפה שלי כאן. אבל יש בעיה קטנה כאן. ואתה נתקלת בזה ב מסדי נתונים יחסיים, כמו גם. הם קראו מחיצות אנכית. אתה רוצה לשמור נתונים הגדולים שלך מהנתונים הקטנים שלך. 

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

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

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

בסדר. קהל: זה אומר לו שבו הוא מאוחסן? ריק הוליהאן: כן, זה אומר לי exactly-- זה בדיוק מה שהיא עושה. זה אומר הנה השיא מחדש שלי. וזה יהיה להצביע בחזרה לשיא מחדש שלי. בְּדִיוּק. אוקיי, אז עכשיו תיבת הדואר הנכנס שלי היא למעשה הרבה יותר קטן. וזה תומך למעשה זרימת העבודה של יישום דואר אלקטרוני. אז תיבת הדואר הנכנס שלי, אני לוחץ. אני הולך יחד ואני לוחץ על ההודעה, זה כשאני צריך ללכת לקבל את הגוף, כי אני הולך ל ללכת לתצוגה אחרת. אז אם אתה חושב על הסוג של MVC מסגרת, בקר להציג מודל. 

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

אני קורא הרבה פחות נתונים. אני רק קורא את הגופים ש דוד צריך כאשר הוא זקוק להם. ואני לא לשרוף בשנת 1600 RCU של רק כדי להראות תיבת הדואר הנכנס שלו. אז עכשיו לראות-- זו הדרך שLSI או GSI-- אני מצטער, GSI, יסתדר. יש לנו החשיש על הנמען. יש לנו את מפתח מגוון במועד. ויש לנו את התכונות החזויות כי אנחנו רק צריכים לתמוך בהשקפה. 

אנו לסובב שלדואר היוצא. חשיש על שולח. ובמהות, שיש לנו הנוף יפה מאוד, נקי. וזה שאנחנו basically-- יש הודעות זה נחמד שולחן זה להיות יפה להפיץ כי זה חשיש רק, זיהוי הודעה מרוסקים. ויש לנו שני מדדים ש הם מסתובבים מעל השולחן ש. בסדר, אז רעיון כאן הוא לא לשמור נתונים הגדולים ונתונים קטנים זה יַחַד. החלוקה אנכית, לחלקם שולחנות. אל תקראו נתונים אין לך. בסדר, המשחקים. כולנו אוהבים משחקים. לפחות אני אוהב משחקים אז. אז כמה מהדברים שאנו מתמודדים עם כש אנחנו חושבים על משחקים, נכון? משחקים בימים אלה, במיוחד ניידים משחקים, הוא על כל חשיבה. ואני הולך לסובב כאן קצת מDynamoDB. אני הולך להביא ב חלק מהדיון סביב חלק מ טכנולוגיות AWS אחרות. 

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

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

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

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

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

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

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

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

אז לך לקבל מושג. אתה סוג של מינוף כל היבטים של AWS כאן כדי לקבל את זה נעשה. וסופו של דבר, אנחנו זורקים בקבוצה דרוג אוטומטי. אז מקרי AC2 שלנו שרתי המשחק שלנו, כפי שהם מתחילים לקבל עסוקים ועסוק יותר ויותר, הם פשוט ספין אחר למשל, לסובב מקרה אחר, ספין מקרה אחר. אז הטכנולוגיה יש AWS, זה מאפשר לך לציין את הפרמטרים שסביבו השרתים שלך יגדלו. אז אתה יכול לקבל מספר n של שרתים בחוץ בכל זמן נתון. ואם העומס שלך הולך משם, הם יהיו לכווץ, המספר יתכווץ. ואם העומס חוזר, זה יגדל בחזרה החוצה, elastically. 

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

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

אז לאן אנחנו הולכים כאן? יש לך צוואר בקבוק גדול שם למטה באתר. והמקום ללכת אליו ברור הוא החלוקה. מחיצות היא לא קל לעשות כשאתה התמודדות עם מסדי נתונים יחסיים. עם מסדי נתונים יחסיים, אתה אחראי על ניהול, ביעילות, החלל המרכזי. אתה אומר משתמשים בין וM ללכת כאן, בין N ו- Z ללכת לשם. ואתה עובר מעבר ליישום. עם כל כך יש לך עסק מקור נתוני מחיצה זו. יש לך אילוצי עסקות שלא להקיף מחיצות. יש לך כל מיני לכלוכים שאתה התמודדות עם שם למטה מנסה כדי להתמודד עם שינוי קנה מידה החוצה ובניית תשתית גדולה יותר. זה פשוט לא כיף. 

קהל: אז אתה אומר ש הגדלת נקודות מקור מאיצה התהליך? ריק הוליהאן: הגדלת? נקודות מקור: קהל. ריק הוליהאן: נקודות מקור? קהל: מהמידע, שבו המידע מגיע? ריק הוליהאן: מס ' מה שאני אומר הוא הגדלת מספר המחיצות במאגר הנתונים משפר את התפוקה. אז מה שקורה כאן הוא משתמשים הקרוב לדוגמא EC2 עד כאן, טוב, אם אני צריך משתמש זה לM, אני אלך כאן. מN לעמ, אני אלך כאן. מP 'עד ת', אני אלך כאן. 

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

ריק הוליהאן: כן. תחשוב על אלה כ ממגורות שונות של נתונים. אז יש לך לעשות את זה. אם אתה מנסה לעשות זה, אם אתה מנסה בקנה מידה על פלטפורמה יחסי, זה מה שאתה עושה. אתה לוקח נתונים ו אתה חותך אותו. ואתה החלוקה אותו על פני מספר מופעים של מסד הנתונים. ואתה ניהול כל ש ברובד היישום. זה לא כיף. אז מה אנחנו רוצים ללכת? אנחנו רוצים ללכת DynamoDB, מנוהלים באופן מלא, חנות NoSQL נתונים, תפוקת הפרשה. אנו משתמשים במדדים משניים. זה בעצם HTTP API ו כולל תמיכת מסמך. אז אתה לא צריך לדאוג על כל מחיצות ש. אנחנו עושים את זה כל בשבילך. אז עכשיו, במקום, רק לכתוב לשולחן. אם השולחן צריך להיות מחולק, שקורה מאחורי הקלעים. אתה מבודד לחלוטין מזה כמפתח. אז בואו נדבר על חלק מהמקרים השימוש שאנו נתקלים במשחקים, נפוץ תרחישי משחקים, leaderboard. אז יש לך משתמשים הקרובים ב, BoardNames שהם ב, הציונים עבור משתמש זה. אנו עשויים להיות ליבון בזיהוי המשתמש, ואז יש לנו מגוון במשחק. אז כל משתמש רוצה לראות כל משחק שהוא שיחק וכל הציון העליון שלו בכל משחק. אז זה leaderboard האישי שלו. 

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

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

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

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

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

קהל: האם אני יכול לשאול שאלה מהירה? אחת הוא לכתוב כבד? ריק הוליהאן: מה הוא? קהל: הוסף כבד. ריק הוליהאן: הוסף כבד. תן לי לראות. 

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

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

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

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

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

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

אז איך אנחנו מתקנים את זה? ובאמת, הדרך לתקן את זה היא על ידי לקיחת דליי מועמד אלה ולכל מועמד שיש לנו, אנחנו הולכים להוסיף ערך אקראי, משהו שאנחנו יודעים, אקראי ערך בין אחד ל -100, בין 100 ל -1,000, או בין אחד ו1,000, עם זאת רבים ערכים אקראיים אתה רוצה לצרף אל סוף המועמד ש. 

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

אז יש לי מיליון, ומיליון, ומיליוני רשומות הקרובות ב למועמדים אלה, אני עכשיו מתפשט אלה קולות על פני A_1 מועמד דרך A_100 מועמד, כי בכל פעם שמגיעה בהצבעה, אני יצירה אקראית ערך בין אחד ל -100. אני tacking אותו על סוף מועמד שהאדם של הצבעה ל. אני זורק אותו לדלי ש. 

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

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

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

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

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

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

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

אז זרמים הם idempotent. האם כולנו יודעים מה idempotent אומר? Idempotent אומר שאתה יכול לעשות את זה מעל, ושוב, ושוב. התוצאה תהיה זהה. 

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

אותו דבר עם MongoDB. יש MongoDB מבנה הם קוראים oplog. זה בדיוק את אותו המבנה. מסדי נתונים NoSQL רבים יש מבנה זה. הם משתמשים בו כדי לעשות דברים כמו שכפול, ש זה בדיוק מה שאנחנו עושים עם זרמים. קהל: אולי שאלת כפירה, אבל אתה מדבר על היישומים עושים את כן הלאה. האם זרמים מובטחים מעולם אולי לרדת? ריק הוליהאן: כן, הנחלים מובטחים מעולם לא לרדת. אנחנו מנהלים את התשתית מֵאָחוֹר. הנחלים באופן אוטומטי לפרוס בקנה המידה אוטומטי הקבוצה שלהם. נלך דרך קצת קצת על מה שקורה. 

אני לא צריך לומר שהם לא מובטח לא לרדת. האלמנטים מובטחים להופיע בזרם. והזרם יהיה נגיש. אז מה הולך למטה או חוזר עד, שקורה מתחת. זה covers-- זה בסדר. בסדר, כך שאתה מקבל שונה סוגי תצוגה מהמסך. סוגי הנוף שחשובים לי מתכנת בדרך כלל הם, מה זה היה? אני מקבל את הנוף הישן. כאשר עדכון פוגע בשולחן, זה ימצא לדחוף את התצוגה הישנה לזרם כך שנתונים יכולים ארכיון, או שינוי שליטה, שינוי זיהוי, שינוי הַנהָלָה. 

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

יש לי סוג ציות של תהליך שרץ. זה צריך לוודא ש כאשר הדברים האלה ישתנו, שהם בגבולות מסוימים או בתוך פרמטרים מסוימים. 

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

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

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

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

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

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

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

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

זרמי DynamoDB יכולים להיות מעובד על ידי מה שאנחנו קוראים למבדה. הזכרנו קצת על אירוע ארכיטקטורות יישום מונעים. למבדה היא מרכיב מרכזי לכך. למבדה היא קוד שמורה על פי דרישה בתגובה לאירוע מסוים. אחד מהאירועים אלה יכול להיות שיא מופיע בזרם. אם שיא מופיע בזרם, אנחנו קוראים לפונקציה זו Java. ובכן, זה JavaScript, ולמבדה תומך Node.js, Java, Python, ובקרוב לתמוך שפות אחרות גם כן. ודי לומר, זה קוד טהור. לכתוב ב- Java, אתה מגדיר את מעמד. אתה דוחף את הצנצנת עד למבדה. ואז אתה מציין שכיתה לקרוא בתגובה לאירוע ש. ולאחר מכן את התשתית למבדה מאחורי שיפעל קוד ש. 

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

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

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

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

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

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

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

אנחנו בסופו של הדבר. תודה לך על נושא עימי. אז בואו נדבר על ארכיטקטורת התייחסות. DynamoDB יושב באמצע כל כך הרבה של תשתית AWS. בעיקרון אתה יכול לחבר אותו עד מה שאתה רוצה. יישומים שנבנו באמצעות דינמו כולל למבדה, ElastiCache, CloudSearch, לדחוף את הנתונים אל אלסטיים MapReduce, יבוא ויצוא מDynamoDB לS3, כל מיני סוגים של תהליכי עבודה. אבל כנראה הטוב ביותר דבר לדבר עליו, וזה מה שבאמת מעניין הוא כאשר אנו מדבר על יישומי אירוע מונע. 

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

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

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

אז פעולת POST שלי היא קורה ללא שרת. בעיקרון API שGateway יושב שם. זה עולה לי שום דבר עד שאנשים להתחיל פרסום לזה, נכון? הפונקציה למבדה פשוט יושבת שם. וזה עולה לי שום דבר עד אנשים מתחילים להכות אותו. אז אתה יכול לראות, כמו הנפח עליות, זה כאשר החיובים לבוא. אני לא רצתי שרת 7/24. 

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

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

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

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

קהל: אז זה יותר חלוף יותר מזה יהיה אם זה היה מאוחסן בשרת בפועל? 

ריק הוליהאן: בהחלט. מכיוון שמופע השרת היה צריך להיות 7/24. זה חייב להיות זמין ל מישהו להגיב ל. ובכן נחש מה? S3 הוא זמין 7/24. S3 תמיד מגיב. וS3 הוא מאוד, מאוד טוב במשרת את חפצים. אובייקטים אלה יכולים להיות קבצי HTML, או קבצי JavaScript, או מה שאתה רוצה. אתה יכול להריץ יישומי אינטרנט עשירים מאוד מתוך דליי S3, ואנשים עושים. 

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

קהל: אז תיבת הזהב שלך באמצע של API Gateway הוא לא כמו שרת, אבל במקום זאת היא פשוט-- 

ריק הוליהאן: אתה יכול לחשוב על זה כחזית שרת. כל זה הוא שזה ייקח HTTP לבקש ולמפות אותו לתהליך אחר. זה כל מה שהיא עושה. ובמקרה הזה, אנחנו ממפים זה לפונקציה למבדה. בסדר, אז זה כל מה שיש לי. תודה רבה. אני מעריך את זה. אני יודע שאנחנו רוצים קצת יותר זמן. ואני מקווה שאתם קיבלת קצת מידע כי אתה יכול לקחת משם היום. ואני מתנצל אם הלכתי על חלק מהראש שלך, אבל יש הרבה טוב של ידע בסיסי בסיסי כי אני חושב שזה מאוד חשוב לך. אז תודה לך שיש לי. [תְשׁוּאוֹת] קהל: [לא ברור] כאשר אתה אומר אתה צריך לעבור את הדבר מההתחלה ועד הסוף כדי לקבל את הערכים הנכונים או את אותם ערכים, איך היית הערכים לשנות אם [לא ברור]. 

ריק הוליהאן: אה, idempotent? איך הייתם הערכים לשנות? ובכן, כי אם אני לא מנוהל זה כל הדרך עד הסוף, אז אני לא יודע מה שינויים נעשו בק"מ האחרון. זה לא הולך להיות אותם נתונים כמו מה שראיתי. קהל: הו, אז אתה רק לא קיבל כל הקלט. ריק הוליהאן: ימין. אתה צריך ללכת מהתחלה לסיום, ואז זה הולך להיות מדינה עולה בקנה אחד. מגניב. 

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

ריק הוליהאן: לא הייתי אומר ומשאיר אותו מאחור. 

קהל: הם הופרדו מכל-- 

ריק הוליהאן: עם המסמך גישה, סוג המסמך בDynamoDB הוא חושב רק עליו כתכונה אחרת. זה תכונה שמכילה מבנה נתונים היררכי. ולאחר מכן בשאילתות, אתה יכול להשתמש בתכונות של אובייקטים אלה באמצעות סימון אובייקט. אז אני יכול לסנן על מקונן רכושו של מסמך JSON. קהל: אז כולי זמן לעשות גישת מסמך, אני יכול סוג של להגיע לtabular-- קהל: בהחלט. קהל: --indexes ו דברים שאתה פשוט דיברת על. ריק הוליהאן: כן, מדדים וכל זה, כאשר אתה רוצה מדד מאפיינים של JSON, האופן שבו היינו צריך לעשות את זה הוא אם אתה מכניס אובייקט JSON או מסמך לדינמו, שהיית משתמש בזרמים. זרמים היו קוראים את הקלט. היית מקבל שJSON מתנגד ואתה הייתי אומר על אישור, מה הרכוש אני רוצה מדד? 

אתה יוצר טבלה נגזרת. עכשיו ככה זה עובד עכשיו. אנחנו לא נאפשר לך מדד ישירות אלה תכונות. 

קהל: Tabularizing המסמכים שלך. 

ריק הוליהאן: בדיוק, משטח זה, tabularizing זה, בדיוק. זה מה שאתה עושה עם זה. 

קהל: תודה לך. 

ריק הוליהאן: כן, בהחלט, תודה. קהל: אז זה סוג של Mongo פוגש classifers Redis. 

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