הגדרת מאגרי חיבורים
חלק מספריות הלקוח של Cloud Bigtable מאפשרות להגדיר את מספר ערוצי ה-gRPC במאגר החיבורים של הלקוח, שנקרא גם מאגר ערוצים. ברוב המקרים, הגדרת ברירת המחדל נכונה ואין צורך לשנות אותה.
הגודל של מאגרי החיבורים משתנה אוטומטית לפי הצורך כשמשתמשים בספריית הלקוח של Cloud Bigtable ל-Java בגרסה 2.23.0 ואילך, וכשמשתמשים בלקוח Cloud Bigtable HBase ל-Java בגרסה 2.9.1 ואילך.
בדף הזה מוסבר איך לקבוע את הגודל האופטימלי של מאגר החיבורים לאפליקציה, ומוצגים בו קטעי קוד שמראים איך להגדיר את מאגרי החיבורים.
לפני שקוראים את הדף הזה, מומלץ לקרוא את הסקירה הכללית על מאגרי חיבורים של Bigtable כדי להבין איך הם פועלים והאם כדאי לשנות את המאגרים שלכם.
ספריות הלקוח הבאות מציעות מאגרי חיבורים ומאפשרות להגדיר את מספר המאגרים:
- ספריית לקוח Go ל-Cloud Bigtable
- לקוח Cloud Bigtable HBase ל-Java
- ספריית לקוח של Cloud Bigtable ל-Java
- ספריית לקוח C++ ל-Cloud Bigtable
קביעת הגודל האופטימלי של מאגר החיבורים
כדי להשאיר מקום לתנודות בתנועה, מומלץ שבמאגר החיבורים יהיו בערך פי שניים חיבורים מהמספר הנדרש לרוויה מקסימלית. חיבור יכול לטפל במספר מקסימלי של 100 בקשות בו-זמניות, ולכן מספר אופטימלי של בקשות בהמתנה לכל חיבור הוא בין 10 ל-50. הקונספט הזה מוסבר בפירוט במאמר בנושא מאגרי חיבורים.
אחרי שמבצעים שינויים, עוקבים אחרי התנועה ומשנים את מספר החיבורים במאגר לפי הצורך.
השלבים הבאים יעזרו לכם לחשב את המספר האופטימלי של חיבורים במאגר הערוצים באמצעות מדדים בצד הלקוח, כמו אלה שזמינים ב-OpenCensus.
- מהמדדים בצד הלקוח, אוספים את הפרטים הבאים:
- המספר המקסימלי של שאילתות לשנייה (QPS) לכל לקוח כשהאפליקציה מפעילה עומס עבודה טיפוסי.
- זמן האחזור הממוצע (זמן התגובה לבקשה יחידה) באלפיות השנייה.
- כדי לקבוע את מספר הבקשות שאפשר לשלוח ברצף בכל שנייה, מחלקים את המספר 1,000 בערך החביון הממוצע.
- מחלקים את השאילתות לשנייה בשניות במספר הבקשות הסדרתיות לשנייה.
- מחלקים את התוצאה ב-50 בקשות לכל ערוץ כדי לקבוע את גודל המאגר האופטימלי המינימלי של הערוצים. (אם החישוב שלכם נמוך מ-2, בכל מקרה צריך להשתמש לפחות ב-2 ערוצים כדי להבטיח יתירות).
- מחלקים את אותה התוצאה ב-10 בקשות לכל ערוץ כדי לקבוע את הגודל המקסימלי האופטימלי של מאגר הערוצים.
השלבים האלה מופיעים במשוואות הבאות:
(QPS sec ÷ (1,000 ÷ latency ms)) ÷ 50 streams = Minimum optimal number of connections
(QPS sec ÷ (1,000 ÷ latency ms)) ÷ 10 streams = Maximum optimal number of connections
דוגמה
האפליקציה שלכם בדרך כלל שולחת 50,000 בקשות בשנייה, וזמן האחזור הממוצע הוא 10 אלפיות השנייה. מחלקים את 1,000 ב-10 אלפיות השנייה כדי לקבוע שאפשר לשלוח 100 בקשות ברצף בשנייה. מחלקים את המספר הזה ב-50,000 כדי לקבל את רמת המקביליות שנדרשת לשליחת 50,000 QPS: 500. בכל ערוץ יכולות להיות לכל היותר 100 בקשות בו-זמנית, והשימוש בערוץ היעד הוא בין 10 ל-50 סטרימינג בו-זמנית. לכן, כדי לחשב את הערך המינימלי, מחלקים את 500 ב-50 ומקבלים 10. כדי למצוא את המקסימום, מחלקים את 500 ב-10 ומקבלים 50. המשמעות היא שגודל מאגר הערוצים בדוגמה הזו צריך להיות בין 10 ל-50 חיבורים.
הגדרת גודל המאגר
בדוגמאות הקוד הבאות אפשר לראות איך מגדירים את מספר המאגרים בספריות הלקוח שמאפשרות להגדיר את גודל המאגר.
המשך
HBase
הדוגמה הזו רלוונטית רק לגרסאות של ספריות לקוח שקודמות לגרסה 2.9.1, שבה הוצגה האפשרות של שינוי גודל אוטומטי.
Java
הדוגמה הזו רלוונטית רק לגרסאות של ספריית הלקוח שקדמו לגרסה 2.23.0, שבה הוצגה האפשרות של שינוי גודל אוטומטי.