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

שירותי הענן של אמזון הודיעו ב־5 בנובמבר על זמינות כללית של bulk put items, אפשרות חדשה לטעינת נתונים מקובצי Amazon S3 אל טבלאות קיימות במסד הנתונים DynamoDB. עדכוני קטלוג, השלמת שדות ורענון תוצאות ניתוח יכולים כך להתבצע כמשימה מנוהלת, במקום לחייב את צוות הפיתוח לבנות את כל תהליך הקריאה והכתיבה בעצמו.

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

מה השתנה לעומת יבוא לטבלה חדשה

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

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

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

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

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

בלי תנאי כתיבה, מידע חדש עלול להידרס

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

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

הסתיימה בהצלחה אינה אומרת שכל הרשומות נכתבו

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

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

דוח השגיאות הוא גם קובץ שדורש הרשאות

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

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

ביטול עוצר את ההמשך, לא מבטל את העבר

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

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

בחירת המסלול היא בחירת זמן ועלות

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

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

החשבון כולל גם אינדקסים ופלט

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

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

הטבלה אינה המערכת היחידה שצריך לנטר

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

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

לפני ההפעלה, מבררים התאמה ולא רק זמינות

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

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

מצאתם טעות או תוכן לא ראוי? דווחו לנו >>