שיטות מומלצות לשיפור קצב העברת הנתונים

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

תפוקת נתונים

קצב העברת הנתונים הוא כמות המשאבים, כמו משאבי FHIR או מופעי DICOM, או בייטים שה-Cloud Healthcare API קולט בכל שנייה.

מגבלות על תפוקת הנתונים

הרשימה הבאה מתארת סיבות אפשריות להגבלת קצב העברת הנתונים:

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

ניסיון חוזר של בקשות שנכשלו

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

שימוש בהשהיה מעריכית לפני ניסיון חוזר עם רעידות ובתורים קבועים של ניסיונות חוזרים

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

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

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

כדאי להשתמש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) כשמנסים לשלוח שוב את הבקשות האלה:

• פעולות שמשנות משאב FHIR או חבילה של משאבי FHIR.

• בקשות LRO סינכרוניות. אם מתרחשת שגיאה כשה-LRO מתחיל או אם ה-LRO נכשל, צריך לנסות שוב.

  ל-LRO יש שגיאות ייחודיות שעשויות לדרוש מכם להטמיע את אסטרטגיות הניסיון החוזר הבאות:

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

דוגמה לאלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

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

1. שליחת בקשה ל-Cloud Healthcare API.

2. אם הבקשה נכשלת, צריך להמתין ‎1 + random-fraction‎ שניות, ולאחר מכן לנסות שוב את הבקשה.

3. אם הבקשה נכשלת, צריך להמתין ‎2 + random-fraction‎ שניות, ולאחר מכן לנסות שוב את הבקשה.

4. אם הבקשה נכשלת, צריך להמתין ‎4 + random-fraction‎ שניות, ולאחר מכן לנסות שוב את הבקשה.

5. צריך להמשיך בדפוס הזה ולהמתין ‎2ⁿ + random-fraction‎ שניות אחרי כל ניסיון חוזר, עד זמן של maximum-backoff.

6. אחרי deadline שניות צריך להפסיק לנסות מחדש את הבקשה.

במימוש האלגוריתם, צריך להשתמש בערכים הבאים:

• לפני כל ניסיון חוזר, זמן ההמתנה הוא min((2n + random-fraction), maximum-backoff), שבו n מתחיל ב-0 וגדל ב-1 בכל ניסיון חוזר.

• מחליפים את random-fraction בערך עשרוני אקראי שקטן מ-1 או שווה לו. צריך להשתמש בערך שונה בכל ניסיון חוזר. הוספת ערך אקראי הזה מונעת סנכרון של לקוחות ושליחה של מספר גדול של ניסיונות חוזרים בו-זמנית.

• מחליפים את maximum-backoff במספר השניות המקסימלי שצריך להמתין בין הניסיונות החוזרים. הערכים האופייניים הם 32 או 64 (‎2⁵ או ‎2⁶) שניות. צריך לבחור את הערך המתאים ביותר לתרחיש לדוגמה שלכם.

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

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

הטמעה של הגבלת קצב של יצירת בקשות בצד הלקוח באמצעות ניהול תנועה

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

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

אפשר להטמיע ניהול תנועה לפעולות סינכרוניות של יצירה, מחיקה, עדכון ומחיקה (CRUD), כולל fhir.executeBundle.

הדרישות בנוגע לעיצוב התנועה

כדי להטמיע את התכונה 'ניהול תנועה', המערכת שלכם צריכה להטמיע את הפעולות הבאות:

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

במקרים הבאים, יכול להיות שיהיה צורך בעיצוב תנועה רק בשלב אחד בצינור:

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

הטמעה של הגבלת קצב של יצירת בקשות באזורים אחרים במערכת

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

• ויסות נתונים (throttle) בצד הלקוח ב-Apache Beam. במאמר שינוי גודל אוטומטי אופקי מוסבר איך לשלוט בהגבלת הקצב באמצעות הדגלים numWorkers ו-maxNumWorkers.

• המחלקות RateLimiter ב-Java מתוך קבוצת ספריות הליבה של Java של Google Guava.

• מודול ratelimiter של Python.

כדי לשלוט בזרימת הנתונים, משתמשים בספריית הלקוח של Pub/Sub ברמה גבוהה.

בחירה בין עיבוד אסינכרוני לעיבוד סינכרוני

שכבת proxy בצד הלקוח שעוטפת בקשות ל-Cloud Healthcare API, כמו שמוצג בקטע טיפול בשגיאות בכמה שכבות, יכולה גם לשלוט בהגבלת קצב הבקשות בשירותים שמשתמשים ב-Cloud Healthcare API. בהתאם לסוג התנועה שרוצים לעצב, בוחרים באחת מהאפשרויות הבאות:

אסינכרוני

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

סינכרוני

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

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

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

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

• אם יש ניתוק בין הלקוח לשכבת ה-proxy, צריך לבצע פעולות נוספות כדי לוודא שהנתונים שונו לפי הבקשה.

שימוש ב-Cloud Tasks

משתמשים ב-Cloud Tasks כדי להעביר בקשות לתור. מערכת Cloud Tasks מגדירה ועוקבת אחרי המכסות הבאות Google Cloud באופן אוטומטי:

• גודל מקסימלי של פרץ וצירוף מקסימלי של בקשות באמצעות האובייקט RateLimits
• ניסיון חוזר של הגבלות באמצעות האובייקט RetryConfig

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

כשמשתמשים ב-Cloud Tasks, חשוב לזכור את הנקודות הבאות:

• ‫Cloud Tasks לא מבטיח מסירה אחת בדיוק. בשיטת המסירה 'בדיוק פעם אחת', השרת מזהה בקשות שמכילות נתונים משוכפלים ומתעלם מהן. מידע נוסף זמין במאמר בנושא אחרי Lambda: עיבוד בדיוק פעם אחת ב-Dataflow, חלק 1.
• הגודל המקסימלי של משימה עשוי להיות קטן בהרבה מהגודל המקסימלי של חבילת FHIR ב-Cloud Healthcare API. מידע נוסף מופיע במאמרים מכסות ומגבלות של Cloud Tasks ומכסות ומגבלות של Cloud Healthcare API.
• יש בעיות ומגבלות ב-Cloud Tasks.

שילוב של חבילות FHIR עם מגבילי קצב

ניסיון חוזר לשליחת חבילות FHIR עם השהיה אקספוננציאלית ומגבילי קצב עוזר לשמור על תפוקת נתונים גבוהה ולנהל עליות פתאומיות בעומס.

לקוח יכול לשלוח חבילות FHIR של עסקאות ושל בקשות מקובצות ל-Cloud Tasks, ששולח את הבקשות בחבילה ל-Cloud Healthcare API. אם מגביל הקצב מלא או חורג מהמכסה כי הוא הגיע לגודל התור המקסימלי ונגמר לו המקום בדיסק, הלקוח יכול להטמיע נסיגה אקספוננציאלית כדי להוסיף את החבילות לתור.

כדי למנוע מצב שבו התור של מגביל הקצב יתמלא, צריך לעקוב אחרי המשאבים הבאים:

• מכסות של פעולות FHIR ב-Cloud Healthcare API
• מכסות של הגבלת קצב
• שגיאות בהגבלת קצב של יצירת בקשות

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

שימוש בחיבורי HTTP מתמשכים (ניתנים לשימוש חוזר)

כברירת מחדל, Cloud Healthcare API פותח חיבור TCP חדש לכל בקשת CRUD. הפעולה הזו דורשת לחיצת יד של TCP, שיכולה לגרום לתקורה ולפגוע בביצועים. כדי לשפר את הביצועים, כדאי להשתמש ב-HTTP keep-alive כדי להשאיר את חיבור ה-TCP פתוח לכמה בקשות.

כדי להשתמש ב-HTTP keep-alive ב-HTTP/1.1, צריך להגדיר את הכותרת Connection לערך keep-alive:

Connection: keep-alive

פרוטוקול HTTP/2 משתמש בחיבור TCP אחד לבקשות עוקבות ובמקביל, וכך נמנעת התקורה באופן אוטומטי.

ספריית Python‏ requests משתמשת ב-HTTP keep-alive כברירת מחדל. אם אתם משתמשים ב-Node.js, צריך להגדיר את keepAlive ל-true כשיוצרים אובייקט http.Agent, ואז להעביר את האובייקט בבקשה.

שימוש במסגרת לבדיקה

תוכנית לבדיקת ה-framework מוודאת שהקוד שלכם פועל ועוזרת לכם:

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

שימוש ב-Cloud Monitoring

מומלץ להשתמש ב-Cloud Monitoring כדי לעקוב אחרי סביבות הבדיקה והייצור. כדאי לפעול לפי ההמלצות הבאות:

• שילוב של Cloud Tasks עם שירותים אחרים שלGoogle Cloud רישום ביומן ומעקב, כמו יומני ביקורת של Cloud.
• יוצרים מדדים מותאמים אישית באמצעות Cloud Monitoring API כדי לעקוב אחרי מדדים מרכזיים כמו ניסיונות חוזרים, גודל התור ומשך ההמתנה בתור.
• יצירת יעדים למדידת רמת השירות (SLOs) ומדדים לרמת השירות (SLIs) עבור הסביבות. המלצות מופיעות במאמר מבוא ל-SLI.
• יוצרים מדיניות התראות באמצעות Google Cloud Observability. מדיניות התראות מודיעה לכם על בעיות כמו עומס על המערכת או צורך בהתערבות אנושית.
• כדאי ליצור מדריכים לתפעול כדי שאדמינים של המערכת ידעו מה לעשות אם מדיניות ההתראות שולחת התראה.

• אפשר להשתמש במדריכים לתפעול בסביבת ביניים כדי להגיב לתרחישים הבאים:

  • בקשות שמצטברות בגלל הגבלת קצב
  • דחייה בגלל חריגה ממגבלות המכסה
  • עליות חדות בתנועת הגולשים

מניעת שגיאות 429 Resource Exhausted operation_too_costly

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

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

במקרה של שגיאה, המונח 'עלות' מתייחס לשימוש במשאבים ולתפוקת הנתונים, ולא לעלויות החיוב.

שגיאה 429 Too Many Requests לא תמיד מעידה על בעיה במכסה. השגיאה יכולה להתרחש כששרת FHIR של Cloud Healthcare API מזהה מחלוקת נעילה מוגזמת ברשומות של מסד הנתונים. הסיבה לכך יכולה להיות ביצוע של הרבה פעולות בחבילת FHIR או שילוב של פעולות CRUD.

למשל, נבחן את התרחיש הבא:

1. חבילת עסקאות FHIR שמעדכנת משאב Patient ומשאבי FHIR אחרים נועלת את משאב Patient עד שהעסקה מסתיימת.

2. כמה חבילות FHIR מנסות לעדכן את משאב המטופל במקביל, ומתרחשת תחרות על נעילה. תשובות שגיאה כוללות את השדה diagnostics עם הטקסט Resource type: PATIENT.

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

3. בסופו של דבר, שרת FHIR של Cloud Healthcare API מזהה הצטברות של טרנזקציות ומבצע הורדת עומס על ידי החזרת שגיאות operation_too_costly. כך מגבילים את התנועה ומונעים שגיאות נוספות.

   השגיאות operation_too_costly מגבילות את כל פעולות ה-CRUD של FHIR בGoogle Cloud פרויקט, וזה משפיע על כל האפליקציות שמחוברות לפרויקט.

פתרון בעיות במקרה של שגיאות 429 Too Many Requests

כדי לפתור בעיות שקשורות לשגיאות 429 Too Many Requests, מחפשים ב-Cloud Logging. שגיאות שמכילות את operation_too_costly מציינות שיש התנגשות נעילה. אם השגיאות נגרמות בגלל מיצוי משאבים, צריך לבדוק אם יש בעיות במכסת המשאבים.

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

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

כדי לפתור את השגיאה, עוברים לקישור FHIR transactional bundle aborted due to cumulative heavy load בשדה diagnostics.

הימנעו מחבילות גדולות

הסיכוי לשגיאה 429 Too Many Requests גבוה יותר כשמדובר בחבילות גדולות של עסקאות. חבילות בכל גודל יכולות ליצור צווארי בקבוק של תפוקה. כדאי לבדוק חבילות שונות כדי למצוא את הגודל האופטימלי.

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

אם חבילות של בקשות בכמות גדולה גדולות או שיש להן QPS גבוה, יכולות להתרחש שגיאות 429 Too Many Requests ו-413 Request Entity Too Large וצווארי בקבוק של קצב העברת הנתונים.

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

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

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

תפוקה של LRO

מידע על קצב העברת הנתונים של פעולות LRO

אפשרויות לאחסון נתוני FHIR

אם נפח נתוני ה-FHIR שלכם קטן עד בינוני, אפשר להשתמש ב-fhir.create כדי לאחסן את הנתונים. כדי לאחסן כמויות גדולות של משאבי FHIR, משתמשים ב-fhir.executeBundle או ב-fhirStores.import. מידע על כל שיטה זמין במאמר אפשרויות ייבוא של FHIR.

ייבוא משאבי FHIR

כשמחליטים אם להשתמש בייבוא FHIR, כדאי להביא בחשבון את הנקודות הבאות:

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

• הייבוא של FHIR פשוט יותר מאשר השימוש בחבילות FHIR. לדוגמה, אתם לא צריכים:

  • חלוקת חבילות גדולות לחבילות קטנות יותר
  • ניהול לוחות זמנים
  • ניסיון חוזר לתיקון שגיאות זמניות ברמת המשאב או החבילה

• בייבוא FHIR לא נאכפת שלמות רפרנציאלית. מידע נוסף זמין במאמר FHIR referential integrity.

• אל תשתמשו בייבוא FHIR אם חשוב לכם שהנתונים יהיו עדכניים. הייבוא יכול להיות מהיר, אבל יכול להיות שיהיו עיכובים של שעות או ימים.

• ייבוא FHIR מתבצע בצורה טובה יותר כשיש פחות פעולות LRO בפרויקט. Google Cloud

• אם האפליקציה שלכם יכולה לטפל בשגיאות ובכשלים בכמות גדולה של משאבים, תוכלו לייבא נתונים בפורמט FHIR במהירות גבוהה.

שימוש בחבילות FHIR

במקרים הבאים, כדאי להשתמש בחבילות FHIR במקום בייבוא FHIR:

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

• חובה לאכוף את השלמות ההפניה.

• צריך לאכוף אימות של פרופיל FHIR.

• צריך לשלוח התראות Pub/Sub כשמשאבי FHIR מאוחסנים. ייבוא FHIR לא תומך בהתראות Pub/Sub.

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

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

יש מגבלות על חבילות FHIR:

• המכסה והחיוב חלים על כל פעולה בחבילה כאילו כל פעולה בוצעה בנפרד. לדוגמה, אם בחבילה יש 10 פעולות POST, 5 פעולות GET ופעולה אחת DELETE, המכסה והחיוב שחלים על החבילה זהים לאלה שחלים על הפעולות האלה אם הן מבוצעות בנפרד.

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

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

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

אפשרויות לאחסון נתוני DICOM

אפשר להשתמש בשיטות הבאות כדי להשיג קצב העברת נתונים גבוה כששולחים נתונים ממערכת Picture Archiving and Communication System‏ (PACS) אל Cloud Healthcare API:

Cloud Healthcare API DICOM adapter בקוד פתוח, באמצעות פרוטוקול DICOM message service element (DIMSE)

המתאם מבצע אופטימיזציה של קצב העברת הנתונים כשמסנכרנים PACS עם Cloud Healthcare API. לפני שמבצעים סנכרון, מריצים בדיקות ביצועים ומוודאים שהמתאם יכול לשמור על קצב העברת נתונים מקסימלי.

משתמשים במתאם הזה אם אי אפשר להעלות קובצי DICOM ל-Cloud Storage באמצעות Storage Transfer Service או אפשרות העברה אחרת. לדוגמה, יכול להיות שלא תוכלו לעמוד בדרישות הבאות של Storage Transfer Service:

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

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

dicomStores.import

כדאי להשתמש בשיטה הזו כדי לאחסן נפחים גדולים של נתוני DICOM.

‫DICOMweb Store Transaction

אפשר להשתמש בשיטה הזו כדי לאחסן נתוני DICOM באופן פרוגרמטי.

ניהול נפח אחסון לשיפור קצב העברת הנתונים

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

תכנון מכסת שימוש לתנועה צפויה

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

בתרשים הבא מוצגות בקשות ל-Cloud Healthcare API שגודלן עקבי ונשלחות בדפוסים צפויים:

איור 1. העומס המצטבר של טעינת API לפי שעה במערכי נתונים ובמאגרי נתונים ב Google Cloud פרויקט

.

תכנון מכסות לבקשות בנפח גדול

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

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

איור 2. התפלגות לא סדירה של השימוש במשאבים שנגרמת בגלל משימה גדולה באצווה בשעות השיא.

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

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

שליחת בקשה להגדלת המכסה

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

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

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

מידע נוסף על קצב העברת הנתונים זמין במאמר ניהול התעבורה ועומס העבודה ב- Google Cloud.