במסמך הזה מפורטות שיטות מומלצות לשימוש ב-Search API. אנחנו משתמשים במירכאות בודדות ('') כדי לתחום מחרוזות של שאילתות. כך אפשר להגדיר שאילתה שמכילה
ביטויים של כמה מילים שמוקפים במירכאות כפולות, בלי ליצור בלבול:
'field:"some text" some-value'.
קריאות ל-Index.put() ול-Index.delete() באצווה
כשמוסיפים או מוחקים מסמכים מאינדקס, אפשר להעביר עד 200 מסמכים בכל פעם. השיטה הזו יעילה יותר מאשר טיפול בכל אחד מהם בנפרד.
שימוש בדירוג המסמך כדי למיין מראש מסמכים
כברירת מחדל, תוצאות החיפוש מוחזרות לפי דירוג בסדר יורד. בנוסף, כברירת מחדל, Search API מגדיר את הדירוג של כל מסמך לפי מספר השניות שעברו מאז 1 בינואר 2011. כך, המסמכים העדכניים ביותר מוצגים ראשונים. אבל אם אתם לא צריכים למיין את המסמכים לפי הזמן שבו הם נוספו, אתם יכולים להשתמש בדרגה למטרות אחרות. נניח שיש לכם אפליקציה לנדל"ן. הלקוחות רוצים בעיקר למיין לפי מחיר. כדי להגדיר מיון ברירת מחדל יעיל, אפשר להגדיר את הדירוג לפי מחיר הבית.
אם אתם צריכים כמה סדרים למיון, כמו מחיר מהנמוך לגבוה ומחיר מהגבוה לנמוך, אתם יכולים ליצור אינדקס נפרד לכל סדר. לאינדקס אחד יהיה rank = price ולאינדקס השני rank = MAXINT-price (כי rank חייב להיות חיובי).
שימוש בדרגה כמפתח המיון ישפר את ביצועי החיפוש. כדי לציין מפתחות מיון אחרים, צריך להשתמש באפשרויות מיון, שמגבילות את מספר תוצאות החיפוש ל-10,000 מסמכים. במקרה כזה, סדר המיון שנקבע לפי הדירוג יקבע אילו מסמכים ייכללו במיון. מידע נוסף על אפשרויות המיון
שימוש בשדות אטום לנתונים בוליאניים
אחסון נתונים בוליאניים בשדות מספרים הוא לא יעיל. במקום זאת, צריך להשתמש בשדות של atom ולהקצות את הקבועים המועדפים (True/False, yes/no, 0/1).
הפיכת השלילי לחיובי
נניח שיש לכם מונח מיוחד לזיהוי מסעדות שהמטבח שלהן לא מוגדר. אם רוצים להחריג את המסעדות האלה, אפשר להשתמש ב-'NOT cuisine:undefined' בתור השאילתה. עם זאת, העלות של ההערכה הזו גבוהה יותר (גם מבחינת פעולות לחיוב וגם מבחינת זמן חישוב) מאשר ההערכה ההפוכה, כלומר חיפוש מסעדות שהמטבח שלהן ידוע. במקום שדה אחד, cuisine (סוג המטבח), אפשר להשתמש בשני שדות, cuisine ו-cuisine_known, כאשר האחרון הוא שדה אטומי. במסעדות שבהן מוגדר סוג המטבח, מגדירים את השדה הראשון לסוג המטבח בפועל ואת השדה השני לערך "yes". אם אתם לא יודעים מה סוג המטבח במסעדה, אתם יכולים להגדיר את סוג המטבח כ-"" (מחרוזת ריקה) ואת cuisine_known כ-"no". עכשיו, כדי למצוא מסעדות שהמטבח שלהן ידוע, מריצים שאילתה 'cuisine_known:yes', שהיא מהירה בהרבה מהשלילה.
הפיכת דיסיונקציות לקוניונקציות
הפעולה 'OR' היא פעולה יקרה גם מבחינת פעולות שניתנות לחיוב וגם מבחינת זמן חישוב. נניח שרוצים לחפש את 'cuisine:Japanese OR cuisine:Korean'. אפשרות אחרת היא להוסיף לאינדקס מסמכים עם קטגוריות כלליות יותר של מטבח. במקרה כזה, אפשר לפשט את השאילתה ל-'cuisine:Asian'.
הסרת טאוטולוגיות מהשאילתות
נניח שאתם רוצים למצוא את כל המסעדות בטורונטו. בהנחה שלמסמכים שלכם יש רק שדה אחד בשם city, אם תשתמשו בשאילתה 'city:toronto AND NOT city:montreal' תקבלו את אותן תוצאות כמו בשאילתה 'city:toronto', כי אם city מוגדר כ-"toronto" הוא לא יכול להיות מוגדר כ-"montreal". השאילתה השנייה רצה הרבה יותר מהר כי היא כוללת רק מונח אחד.
השאילתה הראשונה מבצעת שלושה שלבים: קודם היא מוצאת רשימה של מסמכים שבהם העיר מוגדרת כ-'toronto', אחר כך היא מוצאת רשימה של כל הערים שבהן העיר לא מוגדרת כ-'montreal', ולבסוף היא מחשבת את החיתוך של שתי הרשימות.
צמצום הטווח לפני המיון
נניח שהאפליקציה שלכם מאחסנת מידע על מסעדות ברחבי העולם, ואתם רוצים להציג את המסעדות הכי קרובות למשתמש הנוכחי. אחת הדרכים לעשות זאת היא למיין את המסמכים התואמים לפי המרחק ממיקום המשתמש. אבל אם יש לכם מיליון מסעדות, הפעלת שאילתה כמו
'cuisine:japanese' עם ביטוי המיון
distance(geopoint(x, y), restaurant_loc) תיקח הרבה זמן.
מומלץ להוסיף מסננים לשאילתה כדי להתחיל עם קבוצה בולטת יותר של מסמכים נבחרים למיון. פתרון אחד הוא ליצור קטגוריות גיאוגרפיות, כמו מדינה, מחוז ועיר – אפשר להסיק את העיר והמחוז ממיקום המשתמש. השאילתה תהפוך ל-'cuisine:japanese AND city:<user-city>'. סביר להניח שלא תצטרכו יותר למיין מיליון מסמכים.
שימוש בקטגוריות מצומצמות כדי להימנע ממיון או לצמצם אותו
אם משתמשים בדרגה כדי למיין מסעדות לפי מחיר, אפשר ליצור שדה price_range שמכיל קטגוריות מחיר: price_0_10, price_11_20, price_21_30, price_31_40, price_41_lots. אחר כך תוכלו למצוא את כל המסעדות שהמחיר בהן הוא בין 21 $ל-40$, בלי למיין אותן בכלל, באמצעות השאילתה 'price_range:price_21_30 OR price_range:price_31_40'. במקרים רבים, הקטגוריות המתאימות לא ברורות כל כך, אבל בעזרת הטכניקה הזו אפשר לדחות מספר גדול של מסמכים לפני שמצמצמים את החיפוש באמצעות שאילתות יקרות כמו '... AND price>25 AND price<35'.
אל תתנו ניקוד להתאמות אלא אם אתם צריכים
הניקוד משמש כדי לציין עד כמה מסמך מסוים תואם לשאילתה. עם זאת, אם אתם לא מתכוונים למיין לפי הניקוד, אל תבקשו ניקוד. הפעולה הזו רק תאט את החיפוש.