מצב העמידות שמוגדר כברירת מחדל ב-IndexedDB משתנה מ-strict ל-relaxed החל מגרסה 121 של Chrome. ההתאמה הזו נועדה לשפר את הביצועים ולהתאים את המודעות לדפדפנים מרכזיים אחרים כמו Firefox ו-Safari. בפוסט בבלוג מוסבר על פרטי השינוי הזה ועל המשמעות שלו למפתחי אתרים.
מצבי עמידות של IndexedDB
IndexedDB הוא ממשק API חזק לאינטרנט לאחסון כמויות גדולות של נתונים מובְנים, שמציע שני מצבי עמידות לעסקאות readwrite:
strict: המצב הזה מורה באופן מפורש למערכת ההפעלה למחוק את השינויים בדיסק לפני שהיא מנפיקה את האירועcomplete.relaxedהמצב הזה מסתמך על התנהגות ברירת המחדל של OS flushing, ומפעיל את האירוע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.
לסיכום, המטרה של שינוי ברירת המחדל של מצב העמידות ב-IndexedDB ב-Chrome היא לשפר את הביצועים תוך שמירה על תאימות לדפדפנים מרכזיים אחרים. ברוב המקרים, ההמלצה שלנו היא לא לעשות דבר, כי הגדרת ברירת המחדל החדשה תספק שיפורים בביצועים. אם צריך, אפשר להמשיך לציין את מצב העמידות המועדף, ולשלוט בעמידות ובביצועים של הנתונים באפליקציות האינטרנט.
תודות
הבדיקה של המאמר בוצעה על ידי Evan Stade ו-Rachel Andrew.