ממשק Cassandra

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

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

מושגי ליבה

בקטע הזה מוצגות השוואות בין מושגים מרכזיים ב-Cassandra וב-Spanner.

הסברים על המונחים

Cassandra Spanner
אשכול מכונה

אשכול Cassandra שווה למכונה של Spanner – אוסף של שרתים ומשאבי אחסון. מכיוון ש-Spanner הוא שירות מנוהל, לא צריך להגדיר את החומרה או התוכנה הבסיסיות. צריך רק לציין את מספר הצמתים שרוצים לשריין למופע, או להשתמש בהתאמה אוטומטית לעומס (automatic scaling) כדי לשנות את גודל המופע באופן אוטומטי. מופע פועל כמו מאגר של מסדי הנתונים שלכם. אתם גם בוחרים את טופולוגיית השכפול של הנתונים (אזורית, בשני אזורים או במספר אזורים) ברמת המופע.
Keyspace מסד נתונים

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

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

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

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

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

ארכיטקטורה

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

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

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

עקביות

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

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

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

ממשק Cassandra

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

היתרונות של ממשק Cassandra

  • ניידות: הממשק של Cassandra מספק גישה למגוון רחב של תכונות Spanner, באמצעות סכימות, שאילתות ולקוחות שתואמים ל-Cassandra. כך קל יותר להעביר אפליקציה שנבנתה ב-Spanner לסביבת Cassandra אחרת או להפך. הניוד הזה מאפשר גמישות בפריסה ותומך בתרחישי תוכנית התאוששות מאסון (DR), כמו יציאה ממתח.
  • היכרות: אם אתם כבר משתמשים ב-Cassandra, תוכלו להתחיל להשתמש ב-Spanner במהירות באמצעות הרבה מההצהרות והסוגים של CQL.
  • Spanner ללא פשרות: הממשק של Cassandra מבוסס על התשתית הקיימת של Spanner, ולכן הוא מספק את כל היתרונות הקיימים של Spanner מבחינת זמינות, עקביות ויחס עלות-ביצועים, בלי להתפשר על אף אחת מהיכולות שזמינות במערכת האקולוגית המשלימה של GoogleSQL.

תאימות ל-CQL

  • תמיכה בדיאלקט CQL: Spanner מספק קבוצת משנה של דיאלקט CQL, כולל שפת שאילתות נתונים (DQL), שפת טיפול בנתונים (DML), טרנזקציות קלות (LWT), פונקציות מצטברות ופונקציות של תאריך ושעה.

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

  • תמיכה בפרוטוקול לקוח ופרוטוקול קווי: ‏ Spanner תומך ביכולות הליבה של שאילתות של Cassandra wire protocol v4 באמצעות Cassandra Adapter, לקוח קל משקל שפועל לצד האפליקציה. כך לקוחות רבים של Cassandra יכולים לעבוד עם מסד נתונים של ממשק Spanner Cassandra כמו שהוא, וליהנות מנקודת הקצה הגלובלית, מניהול החיבורים ומאימות IAM של Spanner.

סוגי נתונים נתמכים ב-Cassandra

בטבלה הבאה מוצגים סוגי הנתונים הנתמכים ב-Cassandra, וכל סוג נתונים ממופה לסוג הנתונים המקביל ב-GoogleSQL של Spanner.

סוגי נתונים נתמכים ב-Cassandra סוג הנתונים של Spanner GoogleSQL
סוגים מספריים tinyint (8-bit signed integer) INT64 (64-bit signed integer)

‫Spanner תומך בסוג נתונים יחיד ברוחב 64 ביט למספרים שלמים עם סימן.

smallint (16-bit signed integer)
int (32-bit signed integer)
bigint (64-bit signed integer)
float (32-bit IEEE-754 floating point) FLOAT32 (32-bit IEEE-754 floating point)
double (64-bit IEEE-754 floating point) FLOAT64 (64-bit IEEE-754 floating point)
decimal למספרים עשרוניים עם דיוק קבוע, משתמשים בסוג הנתונים NUMERIC (דיוק 38, קנה מידה 9).
varint (מספר שלם עם דיוק משתנה)
סוגי מחרוזות text STRING(MAX)

גם text וגם varchar מאחסנים ומאמתים מחרוזות UTF-8. ב-Spanner, צריך לציין את האורך המקסימלי של עמודות מסוג STRING. אין השפעה על האחסון. השינוי הזה נועד למטרות אימות.

varchar
ascii STRING(MAX)
uuid STRING(MAX)
timeuuid STRING(MAX)
inet STRING(MAX)
blob BYTES(MAX)

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

סוגי תאריך ושעה date DATE
time INT64

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

timestamp TIMESTAMP
duration STRING(MAX)

‫Spanner לא תומך בסוג משך מאוחסן. משתמשים ב-STRING כדי לאחסן את משך הזמן.

סוגי מאגרי תגים set ARRAY

‫Spanner לא תומך בסוג נתונים ייעודי set. משתמשים בעמודות ARRAY כדי לייצג set.

list ARRAY

משתמשים ב-ARRAY כדי לאחסן רשימה של אובייקטים מוקלדים.

map JSON

‫Spanner לא תומך בסוג מפה ייעודי. אפשר להשתמש בעמודות JSON כדי לייצג מפות.

סוגים אחרים boolean BOOL
counter INT64

הערות על סוגי נתונים

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

לדוגמה, אם יש טבלה ב-Cassandra עם הסכימה הבאה:

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  score frozen<set<int>>
  ....
  PRIMARY KEY(albumId)
)

ב-Spanner, משתמשים בהערות לגבי סוגים כדי למפות לסוגי הנתונים של Cassandra, כמו שמוצג בדוגמה הבאה:

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

בדוגמה הקודמת, פסוקית ה-OPTIONS ממפה את סוג הנתונים של העמודה ב-Spanner לסוג הנתונים התואם ב-Cassandra.

  • albumId (Spanner STRING(MAX)) ממופה ל-uuid ב-Cassandra.
  • title (Spanner STRING(MAX)) ממופה ל-varchar ב-Cassandra.
  • artists (Spanner ARRAY<STRING(MAX)>) ממופה ל-set<varchar> ב-Cassandra.
  • tags (Spanner JSON) ממופה ל-map<varchar,varchar> ב-Cassandra.
  • numberOfSongs (Spanner INT64) ממופה ל-tinyint ב-Cassandra.
  • releaseDate (Spanner DATE) ממופה ל-date ב-Cassandra.
  • copiesSold (Spanner INT64) ממופה ל-bigint ב-Cassandra.
  • score (Spanner ARRAY<INT64>) ממופה ל-frozen<set<int>> ב-Cassandra.
שינוי האפשרות cassandra_type

אפשר להשתמש בהצהרת ALTER TABLE כדי להוסיף או לשנות את האפשרות cassandra_type בעמודות קיימות.

כדי להוסיף אפשרות cassandra_type לעמודה שעדיין אין בה אפשרות כזו, משתמשים בהצהרה הבאה:

ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');

בדוגמה הזו, העמודה uuid בטבלה Albums (אלבומים) מתעדכנת עם האפשרות cassandra_type שמוגדרת ל-uuid.

כדי לשנות אפשרות קיימת של cassandra_type, משתמשים בהצהרת ALTER TABLE עם הערך החדש של cassandra_type. לדוגמה, כדי לשנות את cassandra_type של העמודה numberOfSongs בטבלה Albums מ-tinyint ל-bigint, משתמשים בהצהרה הבאה:

ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');

מותר לכם לשנות רק את הסוגים הבאים:

מאת אל
tinyint smallint, ‏ int, ‏ bigint
smallint int, bigint
int bigint
מספר ממשי (float) double
טקסט varchar
ascii varchar, text
מיפויים ישירים ומורכבים

במקרים רבים, המיפוי בין סוגי הנתונים ב-Spanner וב-Cassandra הוא פשוט. לדוגמה, Spanner STRING(MAX) ממופה ל-Cassandra varchar, ו-Spanner INT64 ממופה ל-Cassandra bigint.

עם זאת, יש מצבים שבהם המיפוי דורש יותר מחשבה והתאמה. לדוגמה, יכול להיות שתצטרכו למפות Cassandra smallint ל-Spanner INT64.

פונקציות נתמכות של Cassandra

בקטע הזה מפורטות הפונקציות של Cassandra שנתמכות ב-Spanner.

ברשימה הבאה מפורטת התמיכה של Spanner בפונקציות של Cassandra.

אורך חיים (TTL)

כשמבצעים מיגרציה מ-Cassandra, צריך להוסיף המדיניות בנושא מחיקת נתונים לטבלת Spanner כדי להשתמש באפשרות USING TTL בהצהרות INSERT או UPDATE או ב-TTL של Spanner.

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

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

מידע נוסף זמין במאמר בנושא הפעלת TTL בנתוני Cassandra.

תכונות של Cassandra שלא נתמכות ב-Spanner

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

הרשימה הבאה מספקת מידע נוסף על תכונות Cassandra שלא נתמכות:

  • חלק מהתכונות של שפת CQL לא נתמכות: פונקציות וסוגים שהוגדרו על ידי המשתמש, הפונקציה token.
  • Spanner ו Google Cloud מישור הבקרה: מסדי נתונים עם ממשקי Cassandra משתמשים ב-Spanner וב Google Cloudכלים כדי להקצות, לאבטח, לנטר ולבצע אופטימיזציה של מופעים. ‫Spanner לא תומך בכלים כמו nodetool לפעילויות ניהוליות.

תמיכה ב-DDL

אין תמיכה ישירה בהצהרות CQL DDL באמצעות ממשק Cassandra. כדי לבצע שינויים ב-DDL, צריך להשתמש במסוף Spanner Google Cloud , בפקודת gcloud או בספריות הלקוח.

קישוריות

  • תמיכה בלקוחות Cassandra

    ‫Spanner מאפשר להתחבר למסדי נתונים ממגוון לקוחות:

בקרת גישה באמצעות ניהול זהויות והרשאות גישה (IAM)

כדי לבצע פעולות קריאה וכתיבה בנקודת הקצה של Cassandra, צריך הרשאות spanner.databases.adapt, spanner.databases.select ו-spanner.databases.write. מידע נוסף מופיע במאמר סקירה כללית על IAM.

במאמר הקצאת תפקידי IAM מוסבר איך להעניק הרשאות IAM ל-Spanner.

מעקב

‫Spanner מספק את המדדים הבאים כדי לעזור לכם לעקוב אחרי Cassandra Adapter:

  • spanner.googleapis.com/api/adapter_request_count: מתעד ומציג את מספר הבקשות של המתאם ש-Spanner מבצעת בשנייה, או את מספר השגיאות שמתרחשות בשרת Spanner בשנייה.
  • spanner.googleapis.com/api/adapter_request_latencies: מתעדת ומציגה את משך הזמן שנדרש ל-Spanner לטיפול בבקשות של המתאם.

אתם יכולים ליצור לוח בקרה מותאם אישית של Cloud Monitoring כדי להציג ולעקוב אחרי מדדים של Cassandra Adapter. לוח הבקרה המותאם אישית מכיל את התרשימים הבאים:

  • זמני האחזור של בקשות P99: ההתפלגות של האחוזון ה-99 של זמני האחזור של בקשות השרת לכל message_type במסד הנתונים.

  • זמני האחזור של בקשות P50: חלוקת האחוזון ה-50 של זמני האחזור של בקשות השרת לכל message_type במסד הנתונים.

  • מספר בקשות ה-API לפי סוג ההודעה: מספר בקשות ה-API לכל message_type במסד הנתונים.

  • מספר בקשות ה-API לפי סוג הפעולה: מספר בקשות ה-API לכל op_type במסד הנתונים.

  • שיעורי שגיאה: שיעורי השגיאה ב-API של מסד הנתונים.

מסוף Google Cloud

  1. מורידים את הקובץ cassandra-adapter-dashboard.json. בקובץ הזה יש את המידע שנדרש כדי לאכלס לוח בקרה בהתאמה אישית ב-Monitoring.
  2. במסוף Google Cloud , עוברים לדף  Dashboards:

    מעבר אל מרכזי בקרה

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

  3. בדף Dashboards Overview, לוחצים על Create Custom Dashboard.
  4. בסרגל הכלים של לוח הבקרה, לוחצים על סמל ההגדרות של לוח הבקרה. לאחר מכן בוחרים באפשרות JSON ואז באפשרות JSON Editor (עורך JSON).
  5. בחלונית JSON Editor, מעתיקים את התוכן של קובץ cassandra-adapter-dashboard.json שהורדתם ומדביקים אותו בעורך.
  6. כדי להחיל את השינויים על לוח הבקרה, לוחצים על החלת השינויים. אם אינכם רוצים להשתמש במרכז הבקרה הזה, נווטו חזרה לדף 'סקירה כללית של מרכזי הבקרה'.
  7. אחרי שיוצרים את לוח הבקרה, לוחצים על הוספת מסנן. לאחר מכן בוחרים באפשרות project_id או instance_id כדי לעקוב אחרי Cassandra Adapter.

‫CLI של gcloud

  1. מורידים את הקובץ cassandra-adapter-dashboard.json. בקובץ הזה יש את המידע שנדרש כדי לאכלס לוח בקרה בהתאמה אישית ב-Monitoring.
  2. כדי ליצור מרכז בקרה בפרויקט, משתמשים בפקודה gcloud monitoring dashboards create:

    gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json
    

    מידע נוסף זמין במאמר בנושא gcloud monitoring dashboards create.

בנוסף, המדדים הבאים של Spanner יכולים לעזור במעקב אחרי Cassandra Adapter:

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

תמחור

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

מידע נוסף זמין במאמר תמחור של Spanner.

המאמרים הבאים