ממשק Cassandra

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

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

מושגי ליבה

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

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

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

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

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

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

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

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

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

ארכיטקטורה

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

מופע Spanner מורכב מקבוצת שרתים בטופולוגיית שכפול. ‫Spanner מפצל באופן דינמי כל טבלה לטווחים של שורות על סמך השימוש ב-CPU ובדיסק. הנתונים מחולקים לחלקים קטנים (Shards) שמוקצים לצמתי מחשוב לצורך הצגה. הנתונים מאוחסנים פיזית ב-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.

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

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

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

סוגי נתונים נתמכים של Cassandra סוג הנתונים ב-Spanner GoogleSQL
סוגים מספריים tinyint (מספר שלם עם סימן, 8 ביט) INT64 (מספר שלם חתום ב-64 ביט)

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

smallint (16-bit signed integer)
int (32-bit signed integer)
bigint (מספר שלם חתום ב-64 ביט)
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 Request Count by Operation Type: מספר בקשות ה-API לכל op_type במסד הנתונים.

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

מסוף Google Cloud

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

    עוברים אל מרכזי בקרה.

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

  3. בדף סקירה כללית של מרכזי בקרה, לוחצים על יצירת מרכז בקרה בהתאמה אישית.
  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.

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