AWS השיקה את Bulk put items ל‑Amazon DynamoDB: עבודה אסינכרונית מנוהלת שקוראת קבצים מ‑Amazon S3 וכותבת את הרשומות ישירות לטבלת DynamoDB קיימת. החידוש מכוון למצב שבו הטבלה כבר משרתת תעבורה חיה, אך צריך להזרים אליה קטלוג גדול, העשרה, backfill או נתוני הגירה — בלי לבנות צינור קליטה ייעודי ובלי לצרוך את קיבולת הקריאה והכתיבה של הטבלה.
ההבדל לעומת Import from S3
Import from S3 נועד ליצור טבלה חדשה מהקבצים. Bulk put items, לעומת זאת, כותב לתוך טבלה קיימת. הפריטים הופכים זמינים לקריאה בזמן שהם נכתבים, והעבודה מתבצעת במסלול קיבולת נפרד שאינו מתחרה בתעבורת היישום.
לפי AWS, הכתיבות אינן מופיעות במדד ConsumedWriteCapacityUnits של הטבלה ואינן צורכות את קיבולת הקריאה או הכתיבה שלה. את התקדמות העבודה והכשלים עוקבים באמצעות DescribeBulkOperation ודוח פלט שנכתב ל‑S3.
איך העבודה מתבצעת
מפעילים StartBulkPutItems ומספקים:
- מיקום קובצי הקלט ב‑S3.
- שם או ARN של טבלת היעד הקיימת.
- מיקום S3 לדוח הפלט.
- רמת ביצועים: Standard כברירת מחדל או Accelerated.
קובצי הקלט יכולים להיות בפורמט DynamoDB JSON בשורות או Amazon Ion, עם דחיסה אופציונלית ב‑gzip או zstd. DynamoDB קוראת את האובייקטים, מאמתת כל רשומה, מטפלת בניסיונות חוזרים וכותבת דוח על פריטים שלא נקלטו.
תנאים לכל רשומה
כל פריט יכול לכלול Condition Expression משלו. כך ניתן להגדיר כתיבה רק כאשר המפתח אינו קיים, או להגן על רשומה חדשה באמצעות מספר גרסה. זה חשוב במיוחד כאשר היישום ממשיך לכתוב לאותם מפתחות בזמן עבודת ה‑bulk.
AWS מזהירה שאחרי כשל פנימי ייתכן שפריט מסוים ייכתב שוב. בלי תנאי גרסה, כתיבת bulk חוזרת עלולה לדרוס עדכון חדש יותר של היישום. לכן, עבור מפתחות פעילים, כדאי לשאת מאפיין גרסה ולהחיל תנאי שמונע החלפה של ערך חדש בערך ישן.
מגבלות שכדאי להכיר
- אין תמיכה בטבלאות Global Tables.
- מותרת עבודת Bulk put items פעילה אחת לכל טבלה.
- ב‑Standard גודל הקלט המרבי לעבודה הוא 100GB; ב‑Accelerated עד 1TB.
- ניתן לכלול עד 50,000 אובייקטים, עד 5GB לכל אובייקט.
- ביטול העבודה אינו מבצע rollback: פריטים שכבר נכתבו נשארים בטבלה וזמינים לקריאה.
טבלת היעד צריכה להיות במצב ACTIVE, או במצב UPDATING עבור שינוי שאינו מתנגש בכתיבות bulk. אי אפשר להתחיל בזמן יצירת אינדקס משני, שחזור מגיבוי או מעבר אל או מ‑Global Table.
Streams דורשים תשומת לב
אם DynamoDB Streams או Kinesis Data Streams פעילים, כל כתיבת bulk מייצרת רשומת Stream בקצב העבודה. צרכן שתוכנן לקצב הרגיל עלול להישאר מאחור. מאחר ש‑DynamoDB Streams שומר רשומות 24 שעות, פיגור ארוך עלול לגרום לאובדן רצף. AWS ממליצה להשתמש בפרמטר MaxWriteRequestUnits כדי להגביל את קצב הכתיבה ולהגן על הצרכנים במורד הזרם.
מתי זה מתאים
הפיצ'ר מתאים לרענון יומי של קטלוגים, העשרת מיליוני פריטים, backfill של מאפיין חדש והעברת נתונים לטבלה שממשיכה לשרת משתמשים. הוא פחות מתאים כאשר נדרשת טרנזקציה אחת אטומית לכל האוסף או rollback מלא במקרה של ביטול.
השורה התחתונה
Bulk put items מצמצם את שכבת התשתית סביב טעינה המונית ל‑DynamoDB, אך אינו מבטל את הצורך בתכנון נתונים. לפני הפעלה בייצור יש לבדוק תנאי גרסה, קצב Streams, הרשאות S3/KMS, מכסות ודוח הכשלים. השירות מנהל את הצינור — האחריות על סמנטיקת העדכון נשארת אצל הצוות.
מקורות ראשיים: הודעת AWS; AWS Database Blog; מגבלות ושיקולי תפעול.
קרדיט תמונה: יצירה: Conny Schneider, מתוך דף המקור ב‑Unsplash. שימוש בהתאם ל‑Unsplash License, המתיר שימוש מסחרי ולא‑מסחרי באתר ובסושיאל ללא צורך באישור; הקרדיט נשמר אף שאינו חובה.
