העלאות שניתן להמשיך

הגדרה

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

מבוא

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

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

  • העלאה שניתן להמשיך חייבת להסתיים בתוך שבוע מרגע שהתחילה.

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

  • העלאה שניתן להמשיך שהסתיימה נחשבת לפעולה ברמה A אחת.

איך להשתמש בהעלאות שניתן להמשיך בכלים שונים ובממשקי API

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

המסוף

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

שורת הפקודה

gcloud

כלי שורת הפקודה של Google Cloud משתמש בהעלאות שניתן להמשיך כשמעלים נתונים ל-Cloud Storage באמצעות הפקודות gcloud storage cp ו-gcloud storage rsync. אם ההעלאה נקטעת, אתם יכולים להריץ שוב את אותה הפקודה שבה השתמשתם בהתחלה כדי להמשיך את ההעלאה מאותה הנקודה. כשממשיכים העלאה שכוללת כמה קבצים, כדאי להשתמש בדגל --no-clobber כדי למנוע העלאה מחדש של קבצים שההעלאה שלהם כבר הסתיימה.

‏gsutil

כלי שורת הפקודה של gsutil משתמש בהעלאות שניתן להמשיך כשמעלים נתונים ל-Cloud Storage באמצעות הפקודות gsutil cp ו-gsutil rsync. אם ההעלאה נקטעת, אתם יכולים להריץ שוב את אותה הפקודה שבה השתמשתם בהתחלה כדי להמשיך את ההעלאה מאותה הנקודה. כשממשיכים העלאה של gsutil cp שכוללת כמה קבצים, כדאי להשתמש בדגל -n כדי למנוע העלאה מחדש של קבצים שההעלאה שלהם כבר הסתיימה.

אפשר להגדיר מה הגודל המינימלי שממנו אתם רוצים להשתמש בהעלאות שניתן להמשיך, באמצעות הפרמטר resumable_threshold בקובץ התצורה של boto. ערך ברירת המחדל של הפרמטר resumable_threshold הוא 8MiB‎.

ספריות לקוח

C++‎

פונקציות שונות ב-storage::Client פועלות באופנים שונים:

  • הפונקציה Client::WriteObject() תמיד משתמשת בהעלאה שניתן להמשיך.
  • הפונקציה Client::InsertObject() תמיד משתמשת בהעלאה פשוטה או בהעלאה מרובת חלקים.
  • הפונקציה Client::UploadFile() יכולה להשתמש בהעלאה שניתן להמשיך, בהעלאה פשוטה או בהעלאה מרובת חלקים.

כברירת מחדל, כשהאובייקט גדול מ-20MiB‎, הפונקציה UploadFile() תשתמש בהעלאה שניתן להמשיך. אחרת, היא תשתמש בהעלאה פשוטה או בהעלאה מרובת חלקים. כדי לשנות את הסף הזה אתם יכולים להגדיר אותו בשדה MaximumSimpleUploadsSizeOption כשאתם יוצרים את האובייקט storage::Client.

הגודל שמוגדר כברירת מחדל למאגר הנתונים הזמני הוא 8MiB‎, ואפשר לשנות אותו באמצעות האפשרות UploadBufferSizeOption.

הגודל של מאגר הנתונים הזמני שמשתמשים בו בספריית הלקוח של C++‎ שווה לגודל של מקטע הנתונים. הגודל של מאגר הנתונים הזמני חייב להיות כפולה של 256KiB‎ (כלומר, 256x1024‎ בייטים). כשמשתמשים בפונקציה WriteObject() או בפונקציה UploadFile(), כדאי להביא בחשבון את יחסי הגומלין בין מהירות ההעלאה לבין השימוש בזיכרון. השימוש במאגרי נתונים זמניים קטנים בזמן שמעלים אובייקטים גדולים עשוי להאט את ההעלאה. בניתוח המפורט ב-GitHub מוסבר בהרחבה על הקשר בין מהירות ההעלאה לבין הגודל של מאגר הנתונים הזמני ב-C++‎.

C#‎

ספריית הלקוח של C#‎ תמיד משתמשת בהעלאות שניתן להמשיך. כדי להתחיל העלאה שניתן להמשיך קוראים לפונקציה CreateObjectUploader.

הגודל של מאגר הנתונים הזמני שמשתמשים בו בספריית הלקוח של C#‎ שווה לגודל של מקטע הנתונים. הגודל שמוגדר כברירת מחדל למאגר הנתונים הזמני הוא 10MB‎, ואפשר לשנות אותו באמצעות הגדרה של הפרמטר ChunkSize ב-UploadObjectOptions. הגודל של מאגר הנתונים הזמני חייב להיות כפולה של 256KiB‎ (כלומר, 256x1024‎ בייטים). השימוש במאגרי נתונים זמניים גדולים בדרך כלל מזרז את ההעלאה, אבל שימו לב שיש יחסי גומלין בין מהירות ההעלאה לבין השימוש בזיכרון.

Go

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

כשהאובייקט קטן מ-Writer.ChunkSize, או כש-Writer.ChunkSize מוגדר ל-0 (כלומר, השבתת החלוקה למקטעי נתונים), תמיד תתבצע העלאה מרובת חלקים. ‫אי אפשר לנסות לשלוח בקשות מחדש לאובייקט Writer, אם ChunkSize מוגדר ל-0.

הגודל של מאגר הנתונים הזמני שמשתמשים בו בספריית הלקוח של Go שווה לגודל של מקטע הנתונים. הגודל של מאגר הנתונים הזמני חייב להיות כפולה של 256KiB‎ (כלומר, 256x1024‎ בייטים). השימוש במאגרי נתונים זמניים גדולים בדרך כלל מזרז את ההעלאה, אבל שימו לב שיש יחסי גומלין בין מהירות ההעלאה לבין השימוש בזיכרון. אם אתם מפעילים כמה העלאות שניתן להמשיך בו-זמנית, חשוב להגדיר את הגודל של Writer.ChunkSize לערך שקטן מ-16MiB‎ כדי למנוע עומס יתר על הזיכרון.

שימו לב שהאובייקט יווצר ב-Cloud Storage רק אחרי שתפעילו את הפונקציה Writer.Close() ללא שגיאות. אם הבקשה נכשלת, הפונקציה Writer.Close תחזיר שגיאה.

Java

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

גודל ברירת המחדל של מאגר הנתונים הזמני הוא 15MiB‎. אפשר להגדיר את מאגר הנתונים הזמני על ידי קריאה לשיטה WriteChannel#setChunkSize(int) או על ידי העברת הפרמטר bufferSize לשיטה Storage#createFrom. הגודל המינימלי של מאגר הנתונים הזמני הוא 256KiB‎. כשקוראים לפונקציה WriteChannel#setChunkSize(int), הגודל של מאגר הנתונים הזמני מותאם אוטומטית למכפלה של 256KiB‎ בתוך הפונקציה.

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

אם אתם מעלים כמויות קטנות יותר של נתונים, מומלץ להשתמש בשיטה Storage#create(BlobInfo, byte[], Storage.BlobTargetOption...) או בשיטה Storage#create(BlobInfo, byte[], int, int, Storage.BlobTargetOption...).

‏Node.js

העלאות שניתן להמשיך מתבצעות באופן אוטומטי. כדי להשבית אותן, צריך להגדיר את resumable ב-UploadOptions ל-false. כשמשתמשים בשיטה createWriteStream, ההעלאות שניתן להמשיך מנוהלות אוטומטית.

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

הגודל של שטח האחסון הזמני שמשתמשים בו בספריית הלקוח של Node.js שווה לגודל של מקטע הנתונים. הגודל של מאגר הנתונים הזמני חייב להיות כפולה של 256KiB‎ (כלומר, 256x1024‎ בייטים). השימוש במאגרי נתונים זמניים גדולים בדרך כלל מזרז את ההעלאה, אבל שימו לב שיש יחסי גומלין בין מהירות ההעלאה ובין השימוש בזיכרון.

PHP

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

הגודל של שטח האחסון הזמני שמשתמשים בו בספריית הלקוח של PHP שווה לגודל של מקטע הנתונים. גודל ברירת מחדל לשטח האחסון הזמני של העלאה שניתן להמשיך הוא ‎256KiB. אפשר לשנות אותו באמצעות הגדרה של המאפיין chunkSize. הגודל של מאגר הנתונים הזמני חייב להיות כפולה של 256KiB‎ (כלומר, 256x1024‎ בייטים). השימוש במאגרי נתונים זמניים גדולים בדרך כלל מזרז את ההעלאה, אבל שימו לב שיש יחסי גומלין בין מהירות ההעלאה לבין השימוש בזיכרון.

Python

כשהאובייקט גדול מ-‎8MiB, תמיד תתבצע העלאה שניתן להמשיך. כשהאוביקט קטן מ-‎8MiB, תמיד תתבצע העלאה מרובת חלקים. לא ניתן לשנות את הסף הזה. הגודל של שטח האחסון הזמני שמשתמשים בו בספריית הלקוח של Python שווה לגודל של מקטע הנתונים. גודל ברירת מחדל לשטח האחסון הזמני של העלאה שניתן להמשיך הוא ‎100MiB. אפשר לשנות אותו באמצעות הגדרה של המאפיין blob.chunk_size.

אם רוצים לבצע תמיד העלאה שניתן להמשיך, בלי קשר לגודל האובייקט, משתמשים במחלקה storage.BlobWriter או בשיטה storage.Blob.open(mode='w'). בשיטות האלה, גודל ברירת המחדל של שטח האחסון הזמני הוא ‎40MiB. אפשר גם לנהל העלאות שניתן להמשיך באמצעות Resumable Media.

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

Ruby

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

ממשקי API ל-REST

‫API ל-JSON

כדי להתחיל העלאה שניתן להמשיך ב-API ל-JSON של Cloud Storage, משתמשים בבקשת POST Object ומעבירים לשאילתה את הפרמטר uploadType=resumable. הבקשה הזו מחזירה URI של הסשן, שאותו מעבירים לבקשת PUT Object (אחת או יותר) כדי להעלות את הנתונים של האובייקט. אם אתם רוצים ליצור לוגיקה משלכם של העלאה שניתן להמשיך, תוכלו להיעזר בהסבר המפורט במאמר ביצוע העלאות שניתן להמשיך.

‫API ל-XML

כדי להתחיל העלאה שניתן להמשיך ב-API ל-XML של Cloud Storage, משתמשים בבקשת POST Object ומעבירים את הכותרת x-goog-resumable: start. הבקשה הזו מחזירה URI של הסשן, שאותו מעבירים לבקשת PUT Object (אחת או יותר) כדי להעלות את הנתונים של האובייקט. אם אתם רוצים ליצור לוגיקה משלכם של העלאה שניתן להמשיך, תוכלו להיעזר בהסבר המפורט במאמר ביצוע העלאות שניתן להמשיך.

העלאות שניתן להמשיך בגודל לא ידוע

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

למידע נוסף, ראו העלאת נתונים בסטרימינג.

ביצועים של העלאות

בחירת האזורים לסשן

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

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

העלאה במקטעי נתונים

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

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

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

אם אתם משתמשים ב-API ל-JSON או ב-API ל-XML והלקוח מקבל הודעת שגיאה, אפשר לבצע שאילתה בשרת לגבי ההיסט הקבוע ולהמשיך בהעלאה של הבייטים שנותרו מההיסט הזה. אם אתם משתמשים במסוף Google Cloud, ב-gsutil, ב-gcloud או בספריות לקוח, הנושא הזה מטופל בשבילכם באופן אוטומטי. במאמר התנהגות העלאה שניתן להמשיך תוכלו לקרוא הנחיות נוספות לגבי איסוף נתונים בספריות לקוח ספציפיות.

לתשומת ליבכם

הקטע הבא שימושי אם אתם מפתחים לקוח משלכם ששולח בקשות העלאה שניתן להמשיך ישירות ל-API ל-JSON או ל-API ל-XML.

מזהי URI של סשנים

כשמתחילים העלאה שניתן להמשיך, Cloud Storage מחזיר URI של סשן, שאותו מעבירים לבקשות הבאות להעלאת הנתונים עצמם. דוגמה ל-URI של סשן ב-API ל-JSON:

https://storage.googleapis.com/upload/storage/v1/b/my-bucket/o?uploadType=resumable&name=my-file.jpg&upload_id=ABg5-UxlRQU75tqTINorGYDgM69mX06CzKO1NRFIMOiuTsu_mVsl3E-3uSVz65l65GYuyBuTPWWICWkinL1FWcbvvOA

דוגמה ל-URI של סשן ב-API ל-XML:

 https://storage.googleapis.com/my-bucket/my-file.jpg?upload_id=ABg5-UxlRQU75tqTINorGYDgM69mX06CzKO1NRFIMOiuTsu_mVsl3E-3uSVz65l65GYuyBuTPWWICWkinL1FWcbvvOA

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

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

  • קוד סטטוס 410 Gone אם עבר פחות משבוע מאז התחלת ההעלאה.
  • קוד סטטוס 404 Not Found אם עבר יותר משבוע מאז התחלת ההעלאה.

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

בדיקות תקינות

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

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

נתונים שנשלחו מחדש

כש-Cloud Storage מעביר בייטים בהעלאה שניתן להמשיך, אי אפשר להחליף את הבייטים האלה ו-Cloud Storage מתעלם מניסיונות כאלה. לכן שימו לב שאסור להעביר נתונים אחרים כשאתם מריצים לאחור את ההעברה, להיסט שכבר שלחתם בעבר.

לדוגמה, נניח שאתם מעלים אובייקט בגודל 100,000 בייטים והחיבור מתנתק. כשאתם בודקים את הסטטוס של ההעברה, מתברר ש-50,000 בייטים הועלו ונשלחו ללא שגיאות. אם תנסו להפעיל מחדש את ההעלאה בהיסט 40,000 בייטים, Cloud Storage יתעלם מהבייטים שתשלחו בהיסט 40,000 עד 50,000. ‫Cloud Storage יתחיל לשמור נתונים שתשלחו מהבייט בהיסט 50,001 והלאה.

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