ב-Google Cloud Search SDK יש מספר פרמטרים של הגדרה באספקה של Google, שמשמשים את כל המחברים. אם יודעים איך לכוונן את ההגדרות האלה, תוכלו לייעל מאוד את הוספת הנתונים לאינדקס. במדריך הזה מפורטות כמה בעיות שעשויות להופיע במהלך ההוספה לאינדקס, יחד עם ההגדרות שמשמשות כדי לפתור אותן.
תפוקת ההוספה לאינדקס נמוכה עבור FullTraversalConnector
בטבלה הבאה מפורטות ההגדרות האישיות לשיפור התפוקה של FullTraversalConnector:
ההגדרה | התיאור | ברירת המחדל | כדאי לנסות לשנות את ההגדרה |
---|---|---|---|
traverse.partitionSize |
המספר של ApiOperation() שיש לעבד בקבוצות לפני אחזור APIOperation() נוספות. ה-SDK ממתין לעיבוד של המחיצה הנוכחית לפני שהוא מאחזר פריטים נוספים. ההגדרה הזו תלויה בנפח הזיכרון הזמין. למחיצות קטנות יותר, כמו 50 או 100, נדרש פחות זיכרון, אבל יותר זמן המתנה עבור ה-SDK. |
50 | אם יש לך הרבה זיכרון פנוי, כדאי לנסות להגדיל את partitionSize ל-1,000 או יותר. |
batch.batchSize |
מספר הבקשות שמקובצות יחד. בסיום החלוקה למחיצות, ה-SDK ימתין עד שכל הבקשות המקובצות יעובדו מהמחיצה. קבוצות גדולות יותר דורשות זמן המתנה ארוך יותר. | 10 | כדאי לנסות להקטין את גודל הקבוצה. |
batch.maxActiveBatches |
מספר הקבוצות המותרות להפעלה בו-זמנית. | 20 | אם תקטין את batchSize , עליך להקפיץ את maxActiveBatches בהתאם לנוסחה הבאה: maxActiveBatches = (partitionSize / batchSize ) + 50. לדוגמה, אם partititionSize הוא 1,000 ו-batchSize הוא 5, הערך של maxActiveBatches צריך להיות 250. ה-50 הנוספים יהוו מאגר נתונים זמני לבקשות לניסיון חוזר. העלייה הזו מאפשרת למחבר לקבץ את כל הבקשות ללא חסימה. |
traverse.threadPoolSize |
מספר הרתיכות שהמחבר יוצר כדי לאפשר עיבוד מקביל. איטרטור יחיד מאחזר פעולות (בדרך כלל RepositoryDoc אובייקטים) באופן סידורי, אבל תהליך הקריאות ל-API במקביל באמצעות מספר threadPoolSize של שרשורים. כל שרשור מעבד פריט אחד בכל פעם. כברירת מחדל, 50 פריטים יעובדו בו-זמנית לכל היותר ב-50 פריטים, והעיבוד של פריט בודד יימשך כ-4 שניות (כולל הבקשה להוספה לאינדקס). |
50 | צריך לנסות להגדיל את הערך של threadPoolSize בכפולה של 10. |
לבסוף, כדאי להשתמש בשיטה setRequestMode()
כדי לשנות את מצב בקשת ה-API (ASYNCHRONOUS
או SYNCHRONOUS
).
למידע נוסף על פרמטרים של קובצי תצורה, קראו את המאמר פרמטרים של הגדרות שסופקו על ידי Google.
תפוקת ההוספה לאינדקס נמוכה עבור ListTraversalConnector
כברירת מחדל, מחבר שמטמיע את ListTraversalConnnector משתמש במעבר יחיד כדי להוסיף את הפריטים שלכם לאינדקס. כדי להגדיל את התפוקה של ההוספה לאינדקס, תוכלו ליצור כמה כלים למעברים לכל אחד מהם עם הגדרה משלו, תוך התמקדות בסטטוסים של פריטים ספציפיים (NEW_ITEM
, MODIFIED
וכן הלאה). בטבלה הבאה מפורטות הגדרות ההגדרות כדי לשפר את התפוקה:
ההגדרה | התיאור | ברירת המחדל | כדאי לנסות לשנות את ההגדרה |
---|---|---|---|
repository.traversers = t1, t2, t3, ... | יוצר כלי מעבר אחד או יותר, כאשר t1, t2, t3, ... הוא השם הייחודי של כל אחד מהם. לכל משתמש מעבר בעל שם יש קבוצת הגדרות משלו שמזוהות באמצעות השם הייחודי של העובר, למשל traversers.t1.hostload ו-traversers.t2.hostload . | כלי מעבר אחד | שימוש בהגדרה הזו כדי להוסיף משתמשים נוספים |
traversers.t1.hostload = n | מזהה את מספר ה-threads, n, שצריך להשתמש בהם כדי להוסיף פריטים לאינדקס בו-זמנית. | 5 | ניתן להתנסות בכוונון של n בהתאם לכמות העומס שרוצים להוסיף למאגר. מתחילים עם ערכים של 10 ומעלה. |
schedule.pollQueueIntervalSecs = s | מזהה את מספר השניות, s, שצריך להמתין לפני הצבעה חוזרת . מחבר התוכן ממשיך לבדוק פריטים כל עוד ה-API מחזיר פריטים בתגובה לסקר. כשהתשובה לסקר ריקה, המחבר ימתין s שניות לפני שינסה שוב. בהגדרה הזו נעשה שימוש רק על ידי ListingConnector | 10 | צריך להוריד את המספר ל-1. |
traverser.t1.pollRequest.statuses = status1, status2, … | מציינת את הסטטוסים status1, status2, … של הפריטים שיש להוסיף לאינדקס. לדוגמה, אם הגדרת את status1 ל-NEW_ITEM ו-status2 ל-MODIFIED , מורה למבקר t1 להוסיף לאינדקס רק פריטים עם הסטטוסים האלה. | משתמש מעבר אחד בודק את כל הסטטוסים | כדאי להתנסות בשימוש במודלים שונים של תעבורה בו-זמנית כדי לקבל סטטוסים שונים. |
למידע נוסף על פרמטרים של קובצי תצורה, קראו את המאמר פרמטרים של הגדרות שסופקו על ידי Google.
ה-SDK מפסיק לזמן קצוב או מפריע בזמן העלאה של קבצים גדולים
אם קורה הזמן הקצוב לתפוגה של ה-SDK או שה-SDK מופיע בזמן העלאה של קבצים גדולים, צריך לציין זמן קצוב לתפוגה גדול יותר באמצעות traverser.timeout=s
(כאשר s = מספר השניות). הערך הזה מציין את משך הזמן הנדרש ל-threads של worker כדי לעבד פריט. הזמן הקצוב לתפוגה שמוגדר כברירת מחדל ב-SDK הוא 60 שניות לשרשורים של מעברים. בנוסף, אם אתם נתקלים בתזמון של בקשות API נפרדות, תוכלו להשתמש בשיטות הבאות כדי להגדיל את הערכים של הזמן הקצוב לתפוגה של בקשות:
פרמטר של זמן קצוב לתפוגה של בקשה | התיאור | ברירת המחדל |
---|---|---|
indexingService.connectTimeoutSeconds |
הזמן הקצוב לתפוגה של חיבור לאינדקס הוא בקשות API. | 120 שניות. |
indexingService.readTimeoutSeconds |
זמן קצוב לתפוגה של קריאה להוספה לאינדקס של בקשות API. | 120 שניות. |