דף זה תורגם על ידי Cloud Translation API.

כוונון הגדרות המחבר

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

התפוקה של ההוספה לאינדקס נמוכה ב-FullTraversalConnector

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

הגדרה	תיאור	ברירת מחדל	שינוי בהגדרות שכדאי לנסות
`traverse.partitionSize`	מספר ה-`ApiOperation()` שיעובדו באצוות לפני אחזור של `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.

לבסוף, אפשר להשתמש ב-method‏ 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`	מציין את מספר השרשורים, `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` יבצע אינדוקס רק של פריטים עם הסטטוסים האלה.	בודק אחד בודק את כל הסטטוסים	אפשר לערוך ניסויים עם סורקים שונים שבודקים סטטוסים שונים.