מצב העמידות שמוגדר כברירת מחדל ב-IndexedDB משתנה מ-strict ל-relaxed מ-Chrome 121. השינוי הזה נועד לשפר את הביצועים ולהתאים לדפדפנים מובילים אחרים, כמו Firefox ו-Safari. בפוסט בבלוג מוסבר על השינוי הזה ומה המשמעות שלו למפתחי אתרים.
מצבי עמידות של IndexedDB
IndexedDB, ממשק API אינטרנטי חזק לאחסון כמויות גדולות של נתונים מובְנים, מציע שני מצבי עמידות ל-readwrite עסקאות:
strict: מצב זה מורה באופן מפורש למערכת ההפעלה לרוקן שינויים בדיסק לפני הנפקת האירועcomplete.relaxedהמצב הזה מסתמך על התנהגות הדחה של מערכת ההפעלה שמוגדרת כברירת מחדל, ויוצר את האירועcompleteאחרי השינויים ששמורים במאגר הנתונים הזמני של מערכת ההפעלה, שבדרך כלל נמחק כל כמה שניות.
חשוב לציין ש-strict לא מבטיח שהשינויים למעשה נכתבים באופן מיידי בדיסק. גם אחרי שאתר מסוים מפעיל קריאה ל-put(), יש פרק זמן מוגבל שבמהלכו תקלה בחשמל יכולה לגרום לכך שהשינוי לא יועבר לדיסק, ולכן הוא לא יועבר לדיסק בפעם הבאה שהאפליקציה תפעל.
בכל הנוגע לעמידות של strict, האירוע complete של טרנזקציית IndexedDB לא מופעל עד אחרי שהנתונים נכתבים בפועל, אבל עם העמידות של relaxed, הנתונים עדיין נמצאים בתהליך הכתיבה כשהאירוע complete מופעל. (למידע נוסף על התהליך המלא, עיינו בהסבר הזה).
לכן, strict מיועד רק לפעולות שבהן חייבים לדעת שהוא נכתב לפני שמבצעים את הפעולה הבאה. העברת נתונים היא דוגמה לכך שנדרשת עמידות לstrict. כשעוברים מחנות גיבוי אחת לאחרת, אין צורך למחוק את הפורמט הישן עד שהפורמט החדש ייכתב. כך, העמידות של strict מאפשרת תרחיש העברה שיכול להתאושש מכשל באמצע התהליך.
שינוי מצב ברירת המחדל של עמידות
ההיבט הקריטי של השינוי הזה הוא מצב העמידות שמוגדר כברירת מחדל לעסקאות של readwrite ב-Chrome. עד עכשיו, ברירת המחדל הייתה strict, מה שהבטיח כתיבה מיידית של הדיסק לשינויים בנתונים. עם זאת, עקב שיקולי ביצועים ובהתאם לדפדפנים מובילים אחרים שמשתמשים ב-relaxed, Chrome מתכנן לשנות את ברירת המחדל גם ל-relaxed.
השינוי הזה נועד ליצור איזון טוב יותר בין הביצועים ועמידות הנתונים. השימוש ב-strict מבטיח עמידות מקסימלית של נתונים, אבל לעיתים קרובות relaxed מספיק לאפליקציות אינטרנט רבות ויכול לשפר את הביצועים באופן משמעותי בדרכים הבאות
- מהירות - בדוגמאות מהעולם האמיתי, צוות Chrome ראה שיפורי מהירות בין פקטור של 3 ל-30.
- עמידות הדיסקים, במיוחד במכשירים עם דיסק און קי (SSD).
- חיי סוללה ארוכים יותר.
- שיפור במהירות הקריאה. הודות לארכיטקטורה של IndexedDB, שבה טרנזקציות קריאה חסומות בדרך כלל מאחורי טרנזקציות כתיבה, מהירות הקריאה משתפרת כהשפעה משנית.
- המכשיר כולו מושפע מכך לטובה, כי הפעולות בדיסק הן משאב מערכת משותף.
יכולת פעולה הדדית ותאימות
היבט חשוב אחד של השינוי הזה הוא ההשפעה שלו על יכולת הפעולה ההדדית והתאימות. Chromium משפר את יכולת הפעולה ההדדית על ידי התאמה להתנהגות של ספקי דפדפנים מובילים אחרים. התקן עצמו מאפשר הטמעות שונות, והמטרה של שינוי זה היא ליצור הרמוניה של יישומים אלה. מידע היסטורי נוסף לגבי השינוי הזה מופיע בבעיה הזו ב-GitHub.
מה המשמעות מבחינת מפתחי אתרים?
בעקבות השינוי הזה לא מופיעה פלטפורמת API חדשה. ה-API הקיים IndexedDB לא משתנה, והשינוי הזה משפיע בעיקר על התנהגות ברירת המחדל של טרנזקציות readwrite. אתם יכולים להגדיר את מצב העמידות המועדף עליכם כשיוצרים עסקאות, וכך לשלוט בעמידות ובביצועים של הנתונים. דוגמת הקוד הבאה מראה איך להחזיר את ההתנהגות הישנה על ידי הגדרת הערך durability ל-strict במערך האפשרויות האופציונלי.
let db;
const DBOpenRequest = window.indexedDB.open("toDoList", 4);
DBOpenRequest.onsuccess = (event) => {
db = DBOpenRequest.result;
};
const transaction = db.transaction(
['toDoList'],
'readwrite',
{ durability: 'strict' });
בדיקת השינוי באופן מקומי לפני המשלוח
השינוי ייכנס לתוקף ב-Chrome בגרסה 121. כדי לבדוק את ההתנהגות החדשה לפני כן באופן מקומי, צריך להחליף את מצב הדגל #indexed-db-default-durability-relaxed ב-chrome://flags.
מידע נוסף
כדי לקבל פרטים טכניים ועדכונים נוספים לגבי השינוי הזה, אפשר לעיין בבאג המעקב ובערך 'סטטוס הפלטפורמה של Chrome'.
לסיכום, המעבר של Chrome לשינוי מצב העמידות שמוגדר כברירת מחדל ב-IndexedDB נועד לשפר את הביצועים תוך שמירה על תאימות לדפדפנים מובילים אחרים. ברוב המקרים, ההמלצה שלנו היא לא לעשות דבר, מכיוון שברירת המחדל החדשה תספק שיפורי ביצועים. במקרה הצורך, אפשר להמשיך לציין את מצב העמידות המועדף עליכם, ולקבל שליטה על עמידות הנתונים ועל הביצועים ביישומי האינטרנט.
אישורים
המאמר הזה נסקר על ידי Evan Stede ו-Rachel Andrew.