בדרך לבסיסי נתונים ללא שרת - איך ולמה

שלום לכולם! שמי גולוב ניקולאי. בעבר עבדתי ב-Avito וניהלתי את פלטפורמת ה-Data במשך שש שנים, כלומר עבדתי על כל מסדי הנתונים: אנליטיים (Vertica, ClickHouse), סטרימינג ו-OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). במהלך תקופה זו עסקתי במספר רב של מאגרי מידע - מאוד שונים ויוצאי דופן, ובמקרים לא סטנדרטיים של השימוש בהם.

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

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

מסדי נתונים ידועים 2020

זה 2020, הסתכלתי מסביב וראיתי שלושה סוגים של מסדי נתונים.

סוג ראשון - מסדי נתונים קלאסיים של OLTP: PostgreSQL, SQL Server, Oracle, MySQL. הם נכתבו מזמן, אבל עדיין רלוונטיים כי הם כל כך מוכרים לקהילת המפתחים.

הסוג השני הוא בסיסים מ"אפס". הם ניסו להתרחק מדפוסים קלאסיים על ידי נטישת SQL, מבנים מסורתיים ו-ACID, על ידי הוספת פיצול מובנה ותכונות אטרקטיביות אחרות. לדוגמה, זוהי Cassandra, MongoDB, Redis או Tarantool. כל הפתרונות הללו רצו להציע לשוק משהו חדש ביסודו וכבשו את הנישה שלהם, כי התברר שהם נוחים ביותר למשימות מסוימות. אציין את מסדי הנתונים הללו במונח המטריה NOSQL.

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

דוגמאות למאגרי מידע כאלה:

• AWS RDS הוא מעטפת מנוהלת עבור PostgreSQL/MySQL.
• DynamoDB הוא אנלוגי AWS למסד נתונים מבוסס מסמכים, בדומה ל-Redis ו-MongoDB.
• Amazon Redshift הוא מסד נתונים אנליטי מנוהל.

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

הערה. הדוגמאות נלקחות עבור סביבת AWS, אבל האנלוגים שלהן קיימים גם ב-Microsoft Azure, Google Cloud או Yandex.Cloud.

מה חדש בזה? ב-2020, שום דבר מזה.

קונספט ללא שרת

מה שבאמת חדש בשוק בשנת 2020 הוא פתרונות ללא שרת או ללא שרת.

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

האם יש דרך אחרת? עם שירותים ללא שרת אתה יכול.

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

אנסה להמחיש גישה זו בתמונות.


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

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

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

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

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

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

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

מסד נתונים ללא שרת - תיאוריה

שאלה של 2020: האם אפשר להפוך גם מסד נתונים ללא שרת? כולם שמעו על ה-backend ללא שרת... בואו ננסה להפוך את מסד הנתונים ללא שרת?

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

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

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

ללא שרת עבור פתרונות OLAP

בוא נראה איך חיתוך מסד נתונים לחלקים Stateful ו-Stateless עשוי להיראות באמצעות דוגמאות מעשיות.

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

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

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

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

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

זוהי גישת עבודה והיא מיושמת לא רק ב- Athena Serverless, אלא גם ב-Redshift Spectrum (ב-AWS).

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

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

ללא שרת עבור פתרונות OLTP

הדוגמה הקודמת הסתכלה על משימות OLAP (אנליטיות). כעת נסתכל על משימות OLTP.

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

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

בתוך Aurora יש את הרעיון של Aurora Capacity Unit, ACU. זהו (בתנאי) מופע (שרת). כל ACU ספציפי יכול להיות מאסטר או עבד. לכל יחידת קיבולת יש זיכרון RAM משלה, מעבד ודיסק מינימלי. בהתאם לכך, אחד הוא המאסטר, השאר הם העתקים לקריאה בלבד.

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

כאשר הבסיס מקבל בקשות, צי ה-proxy מעלה את Aurora CapacityUnits, ומגדיל את משאבי הביצועים של המערכת. היכולת להגדיל ולהקטין משאבים מאפשרת למערכת "להטוט" במשאבים: להציג אוטומטית ACUs בודדים (החלפתם בחדשים) ולהפיץ את כל העדכונים הנוכחיים למשאבים שנמשכו.

הבסיס של Aurora Serverless יכול להתאים את עומס הקריאה. אבל התיעוד לא אומר זאת ישירות. זה עשוי להרגיש כאילו הם יכולים להרים רב-מאסטר. אין קסם.

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

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

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

ללא שרת בעיצובו

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

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

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

הבלוק השני הוא קבוצה של אשכולות מחשוב וירטואליים לחישובים (באיור יש קבוצה של עיגולים כחולים).

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

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

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

בשלב הבא, השירות יוזם את השקת אשכול המחשוב. אשכול מחשוב הוא אשכול של שרתים שמבצעים חישובים. כלומר, מדובר באשכול שיכול להכיל שרת 1, 2 שרתים, 4, 8, 16, 32 - כמה שתרצו. אתה זורק בקשה וההשקה של האשכול הזה מתחילה מיד. זה באמת לוקח שניות.

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

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

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

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

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

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

בנוסף, נניח שיש לנו Data Scientists יצירתיים שמנסים לעשות דברים מפלצתיים עם נתונים, לפעול עם עשרות טרה-בייט, לנתח מיליארדים וטריליונים של שורות של נתונים.

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

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

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

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

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

בואו נסכם את Snowflake. הבסיס משלב רעיון יפה ויישום בר-ביצוע. ב-ManyChat, אנו משתמשים ב- Snowflake כדי לנתח את כל הנתונים שיש לנו. אין לנו שלושה אשכולות, כמו בדוגמה, אלא מ-5 עד 9, בגדלים שונים. יש לנו מכונות קונבנציונליות של 16 מכונות, 2 מכונות, וגם סופר-קטנות של 1 מכונות עבור משימות מסוימות. הם מחלקים בהצלחה את העומס ומאפשרים לנו לחסוך הרבה.

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

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

סך הכל

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

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

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

אני מקווה שמצאת את זה מעניין. ללא שרת הוא העתיד :)

מקור: www.habr.com