העברה מ-Cassandra ל-Spanner

בדף הזה מוסבר איך להעביר את מסד הנתונים NoSQL מ-Cassandra ל-Spanner.

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

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

מגבלות על העברה

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

תהליך ההעברה

תהליך ההעברה מחולק לשלבים הבאים:

1. המרת הסכימה ומודל הנתונים.
2. הגדרת כתיבה כפולה לנתונים נכנסים
3. ייצוא בכמות גדולה של נתונים היסטוריים מ-Cassandra ל-Spanner.
4. מאמתים את הנתונים כדי לוודא תקינות נתונים לאורך תהליך ההעברה.
5. מפנים את האפליקציה ל-Spanner במקום ל-Cassandra.
6. זה שינוי אופציונלי. ביצוע שכפול הפוך מ-Spanner ל-Cassandra.

המרת הסכימה ומודל הנתונים

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

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

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

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

הגדרת מיגרציה פעילה של נתונים נכנסים

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

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

הארכיטקטורה של מיגרציה פעילה כוללת את הרכיבים העיקריים הבאים:

1. מקור: מסד הנתונים של Cassandra שממנו מתבצעת ההעברה.
2. יעד: מסד הנתונים ב-Spanner שאליו אתם מעבירים את הנתונים. אנחנו מניחים שכבר הקציתם מופע של Spanner ומסד נתונים עם סכימה שתואמת לסכימת Cassandra (עם ההתאמות הנדרשות למודל הנתונים ולתכונות של Spanner).

3. ‫Datastax ZDM Proxy: ‫ZDM Proxy הוא פרוקסי כתיבה כפולה שנוצר על ידי DataStax להעברות מ-Cassandra ל-Cassandra. ה-proxy מחקה אשכול Cassandra, וכך מאפשר לאפליקציה להשתמש ב-proxy בלי לבצע שינויים באפליקציה. הכלי הזה הוא מה שהאפליקציה שלכם מתקשרת איתו, והוא משמש אותה באופן פנימי כדי לבצע כתיבות כפולות למסדי הנתונים של המקור והיעד. למרות שבדרך כלל משתמשים בו עם אשכולות של Cassandra כמקור וכמטרה, ההגדרה שלנו קובעת שהוא ישתמש ב-Cassandra-Spanner Proxy (שפועל כקובץ עזר) כמטרה. כך, כל קריאה נכנסת מועברת רק למקור, והתגובה של המקור מוחזרת לאפליקציה. בנוסף, כל פעולת כתיבה נכנסת מופנית גם למקור וגם ליעד.

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

4. ‫Cassandra-Spanner Proxy: אפליקציית sidecar שמיירטת תנועה של Cassandra Query Language ‏(CQL) שמיועדת ל-Cassandra ומתרגמת אותה לקריאות ל-Spanner API. היא מאפשרת לאפליקציות ולכלים ליצור אינטראקציה עם Spanner באמצעות לקוח Cassandra.

5. אפליקציית לקוח: האפליקציה שקוראת נתונים מאשכול Cassandra של המקור וכותבת נתונים אליו.

הגדרת שרת proxy

השלב הראשון בביצוע מיגרציה פעילה הוא פריסה והגדרה של שרתי proxy. שרת ה-Proxy של Cassandra-Spanner פועל כקובץ עזר לשרת ה-Proxy של ZDM. שרת ה-proxy של קובץ העזר החיצוני פועל כיעד לפעולות הכתיבה של ZDM Proxy אל Spanner.

בדיקה של מופע יחיד באמצעות Docker

אפשר להריץ מופע יחיד של ה-proxy באופן מקומי או במכונה וירטואלית לבדיקה ראשונית באמצעות Docker.

דרישות מוקדמות

• מוודאים שלמכונה הווירטואלית שבה פועל ה-proxy יש קישוריות לרשת לאפליקציה, למסד הנתונים המקורי של Cassandra ולמסד הנתונים של Spanner.
• מתקינים את Docker.
• מוודאים שיש קובץ מפתח של חשבון שירות עם ההרשאות הנדרשות לכתיבה למופע ולמסד הנתונים של Spanner.
• מגדירים את המופע, מסד הנתונים והסכימה של Spanner.
• מוודאים ששם מסד הנתונים של Spanner זהה לשם של מרחב המפתחות של Cassandra במקור.
• משכפלים את מאגר spanner-migration-tool.

הורדה והגדרה של ZDM Proxy

1. עוברים לספרייה sources/cassandra.
2. מוודאים שהקבצים entrypoint.sh ו-Dockerfile נמצאים באותה ספרייה כמו קובץ ה-Docker.

3. מריצים את הפקודה הבאה כדי ליצור תמונה מקומית:

   docker build -t zdm-proxy:latest .
   

הפעלת שרת ה-Proxy של ZDM

1. מוודאים שהקבצים zdm-config.yaml ו-keyfiles נמצאים באופן מקומי במקום שבו מריצים את הפקודה הבאה.
2. פותחים את קובץ ה-YAML לדוגמה zdm-config.
3. אפשר לעיין ברשימת הדגלים המפורטת שמתקבלים ב-ZDM.

4. משתמשים בפקודה הבאה כדי להריץ את הקונטיינר:

   sudo docker run --restart always  -d -p 14002:14002 \
   -v zdm-config-file-path:/zdm-config.yaml  \
   -v local_keyfile:/var/run/secret/keys.json \
   -e SPANNER_PROJECT=SPANNER_PROJECT_ID \
   -e SPANNER_INSTANCE=SPANNER_INSTANCE_ID \
   -e SPANNER_DATABASE=SPANNER_DATABASE_ID   \
   -e GOOGLE_APPLICATION_CREDENTIALS="/var/run/secret/keys.json" \
   -e ZDM_CONFIG=/zdm-config.yaml \
   zdm-proxy:latest
   

אימות ההגדרה של שרת ה-Proxy

1. משתמשים בפקודה docker logs כדי לבדוק אם יש שגיאות ביומני ה-proxy במהלך ההפעלה:

   docker logs container-id
   

2. מריצים את הפקודה cqlsh כדי לוודא שהפרוקסי מוגדר בצורה נכונה:

   cqlsh VM-IP 14002
   

   מחליפים את VM-IP בכתובת ה-IP של המכונה הווירטואלית.

הגדרת סביבת ייצור באמצעות Terraform:

בסביבת ייצור, מומלץ להשתמש בתבניות Terraform שסופקו כדי לתזמן את הפריסה של Cassandra-Spanner proxy.

דרישות מוקדמות

• מתקינים את Terraform.
• מוודאים שלאפליקציה יש פרטי כניסה שמוגדרים כברירת מחדל עם הרשאות מתאימות ליצירת משאבים.
• מוודאים שלקובץ מפתח לנותני שירות יש את ההרשאות הרלוונטיות לכתיבה ב-Spanner. הקובץ הזה נמצא בשימוש על ידי ה-proxy.
• מגדירים את המופע, מסד הנתונים והסכימה של Spanner.
• מוודאים שקובץ ה-Dockerfile‏, entrypoint.sh וקובץ מפתח השירות נמצאים באותה ספרייה כמו הקובץ main.tf.

הגדרת משתני Terraform

1. מוודאים שיש לכם את תבנית Terraform לפריסת ה-proxy.
2. מעדכנים את הקובץ terraform.tfvars עם המשתנים של ההגדרה.

פריסת תבנית באמצעות Terraform

הסקריפט של Terraform מבצע את הפעולות הבאות:

• יוצרת מכונות וירטואליות שעברו אופטימיזציה למאגרי תגים על סמך מספר שצוין.
• יוצר קובצי zdm-config.yaml לכל מכונה וירטואלית, ומקצה להם אינדקס טופולוגיה. כדי להגדיר את הטופולוגיה באמצעות השדות PROXY_TOPOLOGY_ADDRESSES ו-PROXY_TOPOLOGY_INDEX בקובץ ההגדרות yaml, צריך להגדיר כמה מכונות וירטואליות ב-ZDM Proxy.
• הכלי מעביר את הקבצים הרלוונטיים לכל מכונה וירטואלית, מריץ מרחוק את Docker Build ומפעיל את הקונטיינרים.

כדי לפרוס את התבנית:

1. משתמשים בפקודה terraform init כדי להפעיל את Terraform:

   terraform init
   

2. מריצים את הפקודה terraform plan כדי לראות אילו שינויים Terraform מתכננת לבצע בתשתית:

   terraform plan -var-file="terraform.tfvars"
   

3. אם המשאבים נראים תקינים, מריצים את הפקודה terraform apply:

   terraform apply -var-file="terraform.tfvars"
   

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

   cqlsh VM-IP 14002
   

   מחליפים את VM-IP בכתובת ה-IP של המכונה הווירטואלית.

הפניית אפליקציות הלקוח אל ZDM Proxy

משנים את ההגדרה של אפליקציית הלקוח, ומגדירים את נקודות הקשר כ-VM שמריץ את ה-proxies במקום את אשכול Cassandra המקורי.

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

ייצוא נתונים בכמות גדולה ל-Spanner

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

מומלץ להשתמש בתבנית SourceDB To Spanner של Dataflow כדי להעביר את הנתונים מ-Cassandra ל-Spanner בכמות גדולה. ‫Dataflow הוא שירות מבוזר לחילוץ, טרנספורמציה וטעינה (ETL) שמספק פלטפורמה להפעלת צינורות נתונים לקריאה ולעיבוד של כמויות גדולות של נתונים במקביל במספר מכונות. Google Cloud תבנית ה-Dataflow‏ SourceDB To Spanner נועדה לבצע קריאות מקבילות מאוד מ-Cassandra, לשנות את נתוני המקור לפי הצורך ולכתוב ל-Spanner כמסד נתונים יעד.

פועלים לפי השלבים במאמר העברה בכמות גדולה מ-Cassandra ל-Spanner באמצעות קובץ ההגדרות של Cassandra.

אימות הנתונים כדי לוודא שהם תקינים

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

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

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

• משימה בכמות גדולה וכתיבה כפולה שפועלות במקביל: העברה בכמות גדולה שפועלת במקביל לכתיבה כפולה עלולה לגרום להבדלים בנתונים בגלל תנאי מירוץ שונים, כמו אלה:

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

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

השוואת נתונים בין Cassandra לבין Spanner

מומלץ לבצע אימותים גם של מספר השורות וגם של התוכן בפועל של השורות.

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

יש שתי דרכים לאמת את הנתונים:

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

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

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

השוואה בין מספר השורות ב-Cassandra וב-Spanner

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

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

• כשמעבירים מערכי נתונים גדולים (יותר מ-10 מיליון שורות לכל טבלה), חשוב לזכור ששאילתות ספירה ב-Spanner ניתנות להרחבה, אבל שאילתות ב-Cassandra נוטות להגיע לזמן קצוב לתפוגה. במקרים כאלה, מומלץ להשתמש בכלי DataStax Bulk Loader כדי לקבל שורות ספירה מטבלאות Cassandra. ברוב המקרים של טעינות בקנה מידה גדול, אפשר להשתמש בפונקציה count(*) של SQL כדי לספור ב-Spanner. מומלץ להריץ את הכלי להעלאה בכמות גדולה לכל טבלה ב-Cassandra, לאחזר את הספירות מהטבלה ב-Spanner ולהשוות בין השתיים. אפשר לעשות את זה באופן ידני או באמצעות סקריפט.

אימות של אי התאמה בשורה

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

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

אימות של מדגם אקראי של שורות

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

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

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

1. יצירת מספרים אקראיים בטווח הטוקנים [-2^63, 2^63 - 1].
2. אחזור שורות WHERE token(PARTITION_KEY) > GENERATED_NUMBER.

סקריפט לדוגמה של validation.go שולף שורות באופן אקראי ומאמת אותן באמצעות שורות במסד הנתונים של Spanner.

אימות של מערך הנתונים כולו

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

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

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

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

השוואה בין נתונים או בין מספר השורות

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

הפניית האפליקציה אל Spanner במקום אל Cassandra

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

כדי לבצע את המעבר, פועלים לפי השלבים הבאים:

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

   • חיבור Cassandra אל Cassandra Adapter שפועל כ-sidecar.
   • מחליפים את קובץ ה-JAR של הדרייבר בלקוח של נקודת הקצה.

2. מחילים את השינוי שהכנתם בשלב הקודם כדי להפנות את האפליקציה אל Spanner.

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

4. אחרי מעבר חד למערכת אחרת מוצלח והפעלה יציבה, צריך להוציא משימוש את מופעי ZDM Proxy ו-Cassandra-Spanner Proxy.

ביצוע שכפול הפוך מ-Spanner ל-Cassandra

אפשר לבצע שכפול הפוך באמצעות תבנית Dataflow‏ Spanner to SourceDB. שכפול הפוך שימושי כשנתקלים בבעיות בלתי צפויות ב-Spanner וצריך לחזור למסד הנתונים המקורי של Cassandra עם הפרעה מינימלית לשירות.

טיפים לאימות של Cassandra באמצעות התאמת שורות

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

1. פיצול מערך הנתונים לטווחים של טוקנים
2. הרצת שאילתות על מחיצות במקביל
3. קריאת נתונים בכל מחיצה
4. אחזור השורות התואמות מ-Spanner
5. כלי אימות עיצוב להרחבה
6. דיווח על אי התאמות ביומן ובדוחות

פיצול מערך הנתונים לטווחים של טוקנים

‫Cassandra מחלקת את הנתונים בין הצמתים על סמך טוקנים של מפתח המחיצה. טווח הטוקנים של אשכול Cassandra הוא מ--2^63 עד 2^63 - 1. אפשר להגדיר מספר קבוע של טווחי טוקנים בגודל שווה כדי לחלק את מרחב המפתחות כולו למחיצות קטנות יותר. מומלץ לפצל את טווח האסימונים באמצעות פרמטר partition_size שאפשר להגדיר כדי לעבד במהירות את כל הטווח.

חלוקת שאילתות למחיצות במקביל

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

דוגמה לשאילתה לטווח אסימונים נתון:

SELECT *
FROM your_keyspace.your_table
WHERE token(pk) >= partition_min_token AND token(pk) <= partition_max_token;

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

קריאת נתונים בכל מחיצה

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

שליפת שורות תואמות מ-Spanner

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

השוואה בין שורות כדי לזהות אי התאמות

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

כלים לאימות עיצוב לצורך הרחבה

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

דיווח על אי התאמות ורישום שלהן ביומן

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

הפעלה והשבתה של TTL בנתוני Cassandra

בקטע הזה מוסבר איך להפעיל ולהשבית את אורך החיים (TTL) של נתוני Cassandra בטבלאות Spanner. סקירה כללית זמינה במאמר בנושא אורך חיים (TTL).

הפעלת TTL בנתוני Cassandra

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

CREATE TABLE Singers (
  SingerId INT64 OPTIONS (cassandra_type = 'bigint'),
  AlbumId INT64 OPTIONS (cassandra_type = 'int'),
) PRIMARY KEY (SingerId);

כדי להפעיל TTL ברמת השורה בטבלה קיימת:

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

   ALTER TABLE Singers ADD COLUMN ExpiredAt TIMESTAMP;
   

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

   ALTER TABLE Singers ADD ROW DELETION POLICY (OLDER_THAN(ExpiredAt, INTERVAL 0 DAY));
   

3. מגדירים את cassandra_ttl_mode ל-row כדי להפעיל את ה-TTL ברמת השורה.

   ALTER TABLE Singers SET OPTIONS (cassandra_ttl_mode = 'row');
   

4. אפשר להגדיר את cassandra_default_ttl כדי לקבוע את ערך ברירת המחדל של TTL. הערך מופיע בשניות.

   ALTER TABLE Singers SET OPTIONS (cassandra_default_ttl = 10000);
   

השבתה של TTL בנתוני Cassandra

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

CREATE TABLE Singers (
SingerId INT64 OPTIONS ( cassandra_type = 'bigint' ),
AlbumId INT64 OPTIONS ( cassandra_type = 'int' ),
ExpiredAt TIMESTAMP,
) PRIMARY KEY (SingerId),
ROW DELETION POLICY (OLDER_THAN(ExpiredAt, INTERVAL 0 DAY)), OPTIONS (cassandra_ttl_mode = 'row');

כדי להשבית את ה-TTL ברמת השורה בטבלה קיימת:

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

   ALTER TABLE Singers SET OPTIONS (cassandra_default_ttl = 0);
   

2. מגדירים את cassandra_ttl_mode ל-none כדי להשבית את ה-TTL ברמת השורה.

   ALTER TABLE Singers SET OPTIONS (cassandra_ttl_mode = 'none');
   

3. מסירים את המדיניות בנושא מחיקת נתונים של השורה.

   ALTER TABLE Singers DROP ROW DELETION POLICY;
   

4. מסירים את העמודה של חותמת הזמן של התפוגה.

   ALTER TABLE Singers DROP COLUMN ExpiredAt;
   

שיקולים להטמעה

• מסגרות וספריות: כדי לבצע אימות מותאם אישית שניתן להרחבה, אפשר להשתמש במסגרות מבוססות MapReduce כמו Apache Spark או Dataflow ‏(Beam). בוחרים שפה נתמכת (Python,‏ Scala,‏ Java) ומשתמשים במחברים ל-Cassandra ול-Spanner, למשל באמצעות שרת proxy. המסגרות האלה מאפשרות עיבוד מקביל יעיל של מערכי נתונים גדולים לצורך אימות מקיף.
• טיפול בשגיאות וניסיונות חוזרים: צריך להטמיע טיפול חזק בשגיאות כדי לנהל בעיות פוטנציאליות כמו בעיות בחיבור לרשת או חוסר זמינות זמני של אחד מהמסד הנתונים. מומלץ להטמיע מנגנונים לניסיון חוזר במקרה של כשלים זמניים.
• הגדרה: אפשרות להגדיר את טווחי האסימונים, פרטי החיבור לשני מסדי הנתונים והלוגיקה של ההשוואה.
• שיפור הביצועים: אפשר להתנסות עם מספר התהליכים המקבילים ועם גודל טווחי האסימונים כדי לבצע אופטימיזציה של תהליך האימות עבור הסביבה הספציפית ונפח הנתונים שלכם. במהלך האימות, עוקבים אחרי העומס על אשכולות Cassandra ו-Spanner.

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

• השוואה בין Spanner ו-Cassandra מופיעה בסקירה הכללית על Cassandra.
• הדרכה: איך להתחבר ל-Spanner באמצעות Cassandra Adapter