Google Cloud Spanner: טוב, רע, מכוער

שלום, חברוביים. באופן מסורתי, אנו ממשיכים לחלוק חומר מעניין ערב תחילתם של קורסים חדשים. היום, במיוחד בשבילכם, תרגמנו מאמר על Google Cloud Spanner, שתוכנן במקביל להשקת הקורס "AWS למפתחים".

פורסם במקור ב בלוג Lightspeed HQ.

כחברה המציעה מגוון פתרונות POS מבוססי ענן לקמעונאים, מסעדנים וסוחרים מקוונים ברחבי העולם, Lightspeed משתמשת במספר סוגים שונים של פלטפורמות מסד נתונים עבור מגוון מקרי שימוש בעסקאות, ניתוחים וחיפוש. לכל אחת מפלטפורמות מסדי הנתונים הללו יש את החוזקות והחולשות שלה. לכן, כשגוגל הציגה את Cloud Spanner לשוק - תכונות מבטיחות שלא נראו בעולם של מסדי נתונים יחסיים, כמו מדרגיות אופקית כמעט בלתי מוגבלת והסכם רמת שירות של 99,999% (SLA) , לא יכולנו לוותר על ההזדמנות להחזיק אותה בידיים שלנו!

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

1. קריטריוני ההערכה שלנו
2. Cloud Spanner בקצרה
3. ההערכה שלנו
4. הממצאים שלנו

1. קריטריוני ההערכה שלנו

לפני שנצלול לפרטים הספציפיים של Cloud Spanner, הדמיון וההבדלים שלו עם פתרונות אחרים בשוק, בואו נדבר תחילה על מקרי השימוש העיקריים שחשבנו כאשר שקלנו היכן לפרוס את Cloud Spanner בתשתית שלנו:

• כתחליף לפתרון מסד הנתונים המסורתי (הרווח) של SQL
• כפתרון OLTP עם תמיכת OLAP

הערה: כדי להקל על ההשוואה, מאמר זה משווה את Cloud Spanner עם גרסאות MySQL של ​​משפחות הפתרונות GCP Cloud SQL ו-Amazon AWS RDS.

שימוש ב-Cloud Spanner כתחליף לפתרון מסד נתונים מסורתי של SQL

בסביבה מָסוֹרתִי מסדי נתונים, כאשר זמן התגובה לשאילתת מסד נתונים מתקרב או אפילו חורג מסף יישום מוגדר מראש (בעיקר עקב עלייה במספר המשתמשים ו/או הבקשות), ישנן מספר דרכים לצמצם את זמן התגובה לרמות מקובלות. עם זאת, רוב הפתרונות הללו כרוכים בהתערבות ידנית.

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

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

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

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

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

תכונות מלאות DBMS כשירות יש להעריך מנקודות מבט שונות. כבסיס, לקחנו את ה-DBMS הפופולרי ביותר בענן - עבור Google, GCP Cloud SQL ועבור Amazon, AWS RDS. בהערכה שלנו, התמקדנו בקטגוריות הבאות:

• מיפוי תכונות: היקף SQL, DDL, DML; ספריות חיבורים/מחברים, תמיכה בעסקאות וכן הלאה.
• תמיכה בפיתוח: קלות פיתוח ובדיקה.
• תמיכה בניהול: ניהול מופעים כגון הגדלה/הקטנה ושדרוג מופעים; SLA, גיבוי ושחזור; אבטחה/בקרת גישה.

שימוש ב-Cloud Spanner כפתרון OLTP מאופשר OLAP

בעוד שגוגל אינה מציינת במפורש ש-Cloud Spanner מיועד לניתוח, היא חולקת כמה תכונות עם מנועים אחרים כגון Apache Impala & Kudu ו-YugaByte המיועדים לעומסי עבודה של OLAP.

גם אם היה רק ​​סיכוי קטן ש-Cloud Spanner כללה מנוע HTAP (Hybrid Transactional/Analytic Processing) מורחבת עקבית עם מערך תכונות OLAP שמיש (פחות או יותר), אנחנו חושבים שזה יזכה לתשומת לבנו.

עם זאת בחשבון, בדקנו את הקטגוריות הבאות:

• טעינת נתונים, אינדקסים ומחיצות
• ביצועי שאילתות ו-DML

2. Cloud Spanner בקצרה

Google Spanner היא מערכת ניהול מסדי נתונים יחסיים מקובצים (RDBMS) ש-Google משתמשת בה עבור כמה מהשירותים שלה. Google הפכה אותו לזמין לציבור למשתמשי Google Cloud Platform בתחילת 2017.

הנה כמה מהתכונות של Cloud Spanner:

• אשכול RDBMS עקבי מאוד, ניתן להרחבה: משתמש בסנכרון זמן חומרה כדי להבטיח עקביות נתונים.
• תמיכה בעסקאות חוצות טבלאות: עסקאות יכולות להשתרע על טבלאות מרובות - לא בהכרח מוגבלות לטבלה בודדת (בניגוד ל- Apache HBase או Apache Kudu).
• טבלאות מבוססות מפתח ראשי: לכל הטבלאות חייב להיות מפתח ראשי מוצהר (PC), שיכול להיות מורכב ממספר עמודות טבלה. נתונים טבלאיים מאוחסנים בסדר מחשב, מה שהופך אותם ליעילים ומהירים מאוד עבור חיפושים במחשב. בדומה למערכות אחרות המבוססות על מחשבים אישיים, היישום חייב להיות מבוסס על מקרי שימוש מוקדמים על מנת להשיג ההופעה הכי טובה.
• טבלאות פסים: לטבלאות יכולות להיות תלות פיזית זו בזו. ניתן להתאים את השורות של טבלת הצאצא לשורות של טבלת האב. גישה זו מזרזת את החיפוש אחר קשרים שניתן לקבוע בשלב מודל הנתונים, למשל, בעת הצבת הלקוחות והחשבוניות שלהם יחד.
• אינדקסים: Cloud Spanner תומך באינדקסים משניים. אינדקס מורכב מעמודות באינדקס וכל עמודות ה-PC. אופציונלי, האינדקס יכול להכיל גם עמודות אחרות שאינן צמודות לאינדקס. ניתן לשלב את האינדקס עם טבלת האב כדי להאיץ שאילתות. מספר הגבלות חלות על אינדקסים, כגון המספר המרבי של עמודות נוספות שניתן לאחסן באינדקס. כמו כן, ייתכן ששאילתות דרך אינדקסים לא יהיו פשוטות כמו ב-RDBMS אחרות.

"Cloud Spanner בוחר אינדקס באופן אוטומטי רק במקרים נדירים. במיוחד, Cloud Spanner אינו בוחר אוטומטית אינדקס משני אם השאילתה מבקשת עמודות שאינן מאוחסנות ב אינדקס ".

• הסכם רמת שירות (SLA): פריסה של אזור יחיד עם 99,99% SLA; פריסות מרובות אזורים עם 99,999% SLA. בעוד שה-SLA עצמו הוא רק הסכם ולא ערובה מכל סוג שהוא, אני מאמין שלאנשי גוגל יש כמה נתונים קשים לטעון טענה כה חזקה. (לעיון, 99,999% פירושם 26,3 שניות של השבתת שירות לחודש.)
• עוד: https://cloud.google.com/spanner/

הערה: פרויקט Apache Tephra מוסיף תמיכה מתקדמת בעסקאות ל- Apache HBase (מיושם כעת גם ב- Apache Phoenix כגרסת בטא).

3. ההערכה שלנו

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

דירגנו את Cloud Spanner כתחליף ל-Sharded MySQL

ל-Google Cloud SQL ו-Amazon AWS RDS, שניים ממסדי הנתונים הפופולריים ביותר של OLTP בשוק הענן, יש מערך תכונות גדול מאוד. עם זאת, על מנת להרחיב את מסדי הנתונים הללו מעבר לגודל של צומת בודד, עליך לבצע פיצול יישומים. גישה זו יוצרת מורכבות נוספת הן ליישומים והן לניהול. בדקנו איך Spanner משתלב בתרחיש של שילוב של רסיסים מרובים למופע אחד ואילו תכונות (אם בכלל) יש להקריב.

תמיכה ב-SQL, DML ו-DDL, כמו גם במחבר ובספריות?

ראשית, כאשר מתחילים עם כל מסד נתונים, עליך ליצור מודל נתונים. אם אתה חושב שאתה יכול לחבר את JDBC Spanner לכלי ה-SQL המועדף עליך, תגלה שאתה יכול לבצע שאילתה על הנתונים שלך באמצעותו, אך אינך יכול להשתמש בו כדי ליצור טבלה או עדכון (DDL) או כל הוספה/עדכון/מחיקה. פעולות (DML). גם ה-JDBC הרשמי של גוגל אינו תומך.

"מנהלי התקנים אינם תומכים כרגע בהצהרות DML או DDL."
תיעוד מפתח

המצב לא טוב יותר עם קונסולת GCP - אתה יכול לשלוח רק שאילתות SELECT. למרבה המזל, יש מנהל התקן JDBC עם תמיכה ב-DML ו-DDL מהקהילה, כולל עסקאות github.com/olavloite/spanner-jdbc. אמנם מנהל ההתקן הזה שימושי ביותר, אבל היעדר מנהל התקן JDBC של גוגל עצמו מפתיע. למרבה המזל, גוגל מציעה תמיכה רחבה למדי בספריית לקוחות (מבוססת על gRPC): C#, Go, Java, node.js, PHP, Python ו-Ruby.

השימוש הכמעט חובה בממשקי ה-API המותאמים אישית של Cloud Spanner (בשל היעדר DDL ו-DML ב-JDBC) גורם להגבלות מסוימות עבור תחומי קוד קשורים, כגון חיבור חיבורים או מסגרות מחייבות מסד נתונים (כמו Spring MVC). בדרך כלל, בעת שימוש ב-JDBC, אתה חופשי לבחור את מאגר החיבורים המועדף עליך (למשל HikariCP, DBCP, C3PO וכו') שנבדק ועובד היטב. במקרה של ממשקי API מותאמים אישית של Spanner, עלינו להסתמך על מסגרות/מאגרי כריכה/מפגשים שיצרנו בעצמנו.

העיצוב המכוון למפתח הראשי (PC) מאפשר ל-Cloud Spanner להיות מהיר מאוד בעת גישה לנתונים דרך המחשב האישי, אך גם מציג כמה בעיות שאילתות.

• לא ניתן לעדכן את הערך של מפתח ראשי; תחילה עליך למחוק את ערך המחשב המקורי ולהכניס אותו מחדש עם הערך החדש. (זה דומה למנועי מסד נתונים/אחסון אחרים מוכווני PC.)
• כל הצהרות UPDATE ו-DELETE חייבות לציין את ה-PC ב-WHERE, לכן, לא יכול להיות DELETE ריק בכל ההצהרות - תמיד חייבת להיות שאילתת משנה, למשל: UPDATE xxx WHERE id IN (SELECT id FROM table1)
• חוסר אפשרות להגדלה אוטומטית או משהו דומה שקובע את הרצף עבור שדה ה-PC. כדי שזה יעבוד, יש ליצור את הערך המתאים בצד האפליקציה.

מדדים משניים?

ל-Google Cloud Spanner תמיכה מובנית באינדקסים משניים. זוהי תכונה נחמדה מאוד שלא תמיד קיימת בטכנולוגיות אחרות. Apache Kudu לא תומך כרגע באינדקסים משניים בכלל, ו- Apache HBase לא תומך באינדקסים ישירות, אבל יכול להוסיף אותם דרך Apache Phoenix.

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

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

יִצוּג?

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

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

תמיכה בפיתוח?

Cloud Spanner מציע תמיכה די הגונה בשפת תכנות לעבודה עם ה-API שלו. הספריות הנתמכות רשמית הן באזור C#, Go, Java, node.js, PHP, Python ו-Ruby. התיעוד מפורט למדי, אך כמו בטכנולוגיות מתקדמות אחרות, הקהילה קטנה למדי בהשוואה לרוב טכנולוגיות מסד הנתונים הפופולריות, מה שעלול לגרום ליותר זמן לבזבז על מקרי שימוש או בעיות פחות נפוצות.

אז מה לגבי תמיכה בפיתוח מקומי?

לא מצאנו דרך ליצור מופע של Cloud Spanner מקומי. הכי קרוב שהגענו הוא תמונת Docker ג'וק DBשהוא דומה בעקרון, אבל שונה מאוד בפועל. לדוגמה, CockroachDB יכול להשתמש ב-PostgreSQL JDBC. מכיוון שסביבת הפיתוח צריכה להיות קרובה ככל האפשר לסביבת הייצור, Cloud Spanner אינו אידיאלי מכיוון שאתה צריך להסתמך על מופע מלא של Spanner. כדי לחסוך בעלויות, אתה יכול לבחור מופע אזור בודד.

תמיכה במינהל?

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

מספר מדדים בסיסיים זמינים ישירות בדף Spanner ב-Google Console. תצוגות מפורטות יותר זמינות דרך Stackdriver, שם תוכל גם להגדיר ערכי סף מדדים ומדיניות התראות.

גישה למשאבים?

MySQL מציע הגדרות הרשאות/תפקידים נרחבות ומפורטות מאוד. אתה יכול בקלות להתאים אישית גישה לטבלה ספציפית, או אפילו רק תת-קבוצה של העמודות שלה. Cloud Spanner משתמש בכלי Google Identity & Access Management (IAM), המאפשר רק להגדיר מדיניות והרשאות ברמה גבוהה מאוד. האפשרות המפורטת ביותר היא הרשאה ברמת מסד הנתונים, שאינה מתאימה ברוב מקרי הייצור. הגבלה זו מאלצת אותך להוסיף אמצעי אבטחה נוספים לקוד, לתשתית או לשניהם כדי למנוע שימוש לא מורשה במשאבי Spanner.

גיבויים?

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

שאילתה ביצועים?

השתמשנו ב-Yahoo! כדי לטעון נתונים ולבדוק בקשות. Benchmark לשרת ענן. הטבלה שלהלן מציגה את עומס העבודה של B YCSB עם יחס כתיבה של 95% קריאה ל-5%.

* מבחן העומס הופעל על n1-standard-32 Compute Engine (CE) (32 vCPUs, 120 GB זיכרון) ומופע הבדיקה מעולם לא היה צוואר הבקבוק בבדיקות.
** המספר המרבי של שרשורים במופע YCSB אחד הוא 400. בסך הכל, היה צורך להריץ שישה מופעים מקבילים של בדיקות YCSB כדי לקבל סך של 2400 שרשורים.

בהסתכלות על תוצאות ההשוואה, בפרט השילוב של עומס מעבד ו-TPS, אנו יכולים לראות בבירור ש-Cloud Spanner מתקדם די טוב. העומס הגדול שנוצר על ידי מספר רב של חוטים מקוזז על ידי מספר רב של צמתים באשכול Cloud Spanner. למרות שהשהייה נראית די גבוהה, במיוחד כאשר פועל על 2400 שרשורים, ייתכן שיהיה צורך לבצע בדיקה חוזרת עם 6 מופעים קטנים יותר של מנוע המחשוב כדי לקבל מספרים מדויקים יותר. כל מופע יפעיל בדיקת YCSB אחת במקום מופע CE אחד גדול עם 6 בדיקות מקבילות. זה יקל על ההבחנה בין עיכובים בבקשת Cloud Spanner לבין עיכובים שנוספו על ידי חיבור הרשת בין Cloud Spanner לבין מופע CE המריץ את הבדיקה.

כיצד מתפקד Cloud Spanner כ-OLAP?

חלוקה למחיצות?

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

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

טוען נתונים?

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

• מיין את הנתונים שלך לפי מפתח ראשי.
• מחלקים אותם ב-10*מספר צמתים סעיפים בודדים.
• צור קבוצה של משימות עובד הטוענות נתונים במקביל.

טעינת נתונים זו משתמשת בכל צמתי Cloud Spanner.

השתמשנו בעומס העבודה A YCSB כדי ליצור מערך נתונים של 10 מיליון שורות.

* מבחן העומס הופעל על מנוע המחשוב n1-standard-32 (32 vCPUs, 120 GB זיכרון) ומופע הבדיקה מעולם לא היה צוואר הבקבוק בבדיקות.
** הגדרת צומת 1 אינה מומלצת עבור כל עומס ייצור.

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

דֵרוּג?

הגדלה והקטנה של מספר צמתים של Cloud Spanner היא משימה בלחיצה אחת. אם אתה רוצה לטעון נתונים במהירות, אולי כדאי לשקול להגביר את המופע למקסימום (במקרה שלנו זה היה 25 צמתים באזור ארה"ב-מזרח) ואז להפחית את מספר הצמתים המתאימים לעומס הרגיל שלך לאחר כל הנתונים במסד הנתונים, תוך התחשבות במגבלה של 2 TB/צומת.

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

הצלחנו להקטין מ-25 ל-2 מקרים, אבל אנחנו תקועים בשני צמתים.

העלאה והפחתה של מספר הצמתים באשכול Cloud Spanner יכולה להיות אוטומטית באמצעות REST API. זה יכול להיות שימושי במיוחד להפחתת העומס המוגבר על המערכת בשעות עמוסות.

ביצועי שאילתת OLAP?

במקור תכננו להקדיש זמן לא מבוטל להערכת Spanner בנושא זה. לאחר כמה ספירות SELECT, הבנו מיד שהבדיקה תהיה קצרה ושSpnner לא יהיה מנוע מתאים ל-OLAP. ללא קשר למספר הצמתים באשכול, פשוט בחירת מספר השורות בטבלת שורות של 10 מיליון ארכה 55 עד 60 שניות. כמו כן, כל שאילתה שדרשה יותר זיכרון לאחסון תוצאות ביניים נכשלה עם שגיאת OOM.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

מספרים מסוימים עבור שאילתות TPC-H ניתן למצוא במאמר של טוד ליפקון nosql-kudu-spanner-slides.html, שקופיות 42 ו-43. המספרים הללו תואמים את התוצאות שלנו (למרבה הצער).

4. הממצאים שלנו

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

כשהתחלנו להעריך את Cloud Spanner, ציפינו שתכונות הניהול שלו יהיו דומות, או לפחות לא רחוקות מפתרונות אחרים של Google SQL. אבל הופתענו מהחוסר המוחלט של גיבויים ובקרת גישה מוגבלת מאוד למשאבים. שלא לדבר על ללא תצוגות, ללא סביבת פיתוח מקומית, רצפים לא נתמכים, JDBC ללא תמיכה ב-DML ו-DDL, וכן הלאה.

אז, לאן לפנות למישהו שצריך להגדיל מסד נתונים עסקה? נראה שעדיין אין פתרון אחד בשוק שמתאים לכל מקרי השימוש. ישנם פתרונות קוד סגור ופתוח רבים (חלקם מוזכרים במאמר זה), כל אחד עם נקודות החוזק והחולשה שלו, אך אף אחד מהם לא מציע SaaS עם 99,999% SLA ודרגה גבוהה של עקביות. אם SLA גבוה הוא המטרה העיקרית שלך ואתה לא נוטה לבנות פתרון משלך עבור עננים מרובים, Cloud Spanner עשוי להיות הפתרון שאתה מחפש. אבל אתה צריך להיות מודע לכל המגבלות שלו.

למען ההגינות, Cloud Spanner שוחרר לציבור רק באביב 2017, כך שסביר לצפות שחלק מהפגמים הנוכחיים שלו עלולים בסופו של דבר להיעלם (אני מקווה), וכשזה יקרה, זה יכול להיות מחליף משחק. אחרי הכל, Cloud Spanner הוא לא רק פרויקט צדדי של גוגל. Google משתמשת בו כבסיס למוצרים אחרים של Google. וכאשר גוגל החליפה לאחרונה את Megastore ב-Google Cloud Storage ב-Cloud Spanner, היא אפשרה ל-Google Cloud Storage להיות עקבי ביותר עבור רשימות אובייקטים בקנה מידה עולמי (מה שעדיין לא קיים עבור אמזון S3).

אז, עדיין יש תקווה... אנחנו מקווים.

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

אנו מזמינים את כולם לבקר אצלנו סמינר מקוון חינם בו נספר לכם בפירוט על הקורס "AWS למפתחים" מ-OTUS.

מקור: www.habr.com