როგორ დავამატოთ ძიება თქვენს აპში: მარტივი ფილტრებიდან სრულტექსტურ ძიებამდე
აპში ძიების დასამატებლად დაიწყეთ უმარტივესით, რაც მუშაობს: საძიებო ველი, რომელიც სერვერულ მარშრუტს იძახებს, ეს მარშრუტი კი მონაცემთა ბაზის სტრიქონებს ფილტრავს მოთხოვნის რამდენიმე სვეტთან დამთხვევით, პლუს ფილტრები ისეთი რამისთვის, როგორიცაა კატეგორია ან ფასი. როცა ეს საკმარისი აღარ არის — გჭირდებათ რელევანტობით რანჟირება, სიტყვების ფუძეზე დაყვანა ან ბევრი ჩანაწერი — გადადით თქვენი მონაცემთა ბაზის სრულტექსტურ ძიებაზე, ხოლო ჰოსტირებულ საძიებო სისტემაზე გადადით მხოლოდ მაშინ, თუ ძლიერი შეცდომებისადმი მდგრადობა ან მყისიერი შედეგები დიდ მონაცემებზე გჭირდებათ. რასაც არ უნდა აირჩიოთ, ძიებამ უნდა პატივი სცეს უფლებებს: მომხმარებელმა არასდროს უნდა იპოვოს ჩანაწერები, რომელთა ნახვის უფლებაც არ აქვს.
რას ნიშნავს „ძიება“ თქვენი აპისთვის
ძიება რამდენიმე სხვადასხვა რამეს მოიცავს, და უმეტეს აპს ერთზე მეტი სჭირდება:
- საკვანძო სიტყვებით ძიება: ტექსტის ველი — „იპოვე განცხადებები, სადაც ნახსენებია „ბაღი““.
- ფილტრები: სტრუქტურირებული არჩევანი — კატეგორია, ქალაქი, ფასის დიაპაზონი, თარიღი, სტატუსი.
- დალაგება: უახლესი, იაფი, ყველაზე რელევანტური.
- ავტოშევსება: შემოთავაზებები წერისას.
- შეცდომებისადმი ტოლერანტობა: „restuarant“ მაინც პოულობს „restaurant“-ს.
დირექტორიის, ვაკანსიების დაფის ან მაღაზიისთვის ფილტრები ხშირად ტექსტის ველზე მეტ მნიშვნელობას იძენს. გადაწყვიტეთ, რომელი მათგანი გჭირდებათ სინამდვილეში, სანამ ინსტრუმენტს აირჩევთ.
თქვენი ვარიანტები
| მიდგომა | როგორ მუშაობს | რისთვისაა კარგი | შეზღუდვები |
|---|---|---|---|
| ფილტრაცია ბრაუზერში | სია იტვირთება და JavaScript-ით ფილტრავდება | პატარა საჯარო სიები (რამდენიმე ასეული ელემენტი) | ყველა მონაცემი ყველა ვიზიტორთან მიდის; დიდ სიებზე ნელია |
| მონაცემთა ბაზის ნიმუშით ძიება | სერვერული შეკითხვა „სახელი შეიცავს ტექსტს“, რეგისტრის გარეშე | პატარა და საშუალო აპები, ადმინისტრაციული ინსტრუმენტები | რანჟირება არ არის; დიდ ცხრილებზე შეიძლება შენელდეს; ფუძეზე დაყვანა არ არის |
| მონაცემთა ბაზის სრულტექსტური ძიება | Postgres ინდექსირებს სიტყვებს და არანჟირებს დამთხვევებს | შინაარსზე ორიენტირებული აპების უმეტესობა | სუსტია შეცდომებზე, თუ არ დაამატებთ fuzzy matching-ს |
| Fuzzy matching (trigram-ები) | Postgres ადარებს სიმბოლოთა მიმდევრობებს მსგავსებისთვის | სახელები, მოკლე ველები, შეცდომების ტოლერანტობა | სჭირდება გაფართოება და ინდექსი; მორგება შრომატევადია |
| ჰოსტირებული საძიებო სისტემა | ცალკე სერვისი ინდექსირებს თქვენს მონაცემებს (Algolia, Meilisearch, Typesense, Elasticsearch და სხვა) | დიდი კატალოგები, მყისიერი ძიება, მძიმე შეცდომების ტოლერანტობა | კიდევ ერთი სერვისი, რომელიც სინქრონიზებული, გადახდილი და დაცული უნდა იყოს |
თუ თქვენი მონაცემები უკვე Postgres-შია, მისი ჩაშენებული სრულტექსტური ძიება ძლიერი შუალედური ვარიანტია. ის ტექსტს სიტყვებად ყოფს, ამცირებს მათ ფუძეებამდე (ასე „running“ ემთხვევა „run“-ს), უგულებელყოფს გავრცელებულ სიტყვებს და შედეგებს დამთხვევის ხარისხით არანჟირებს. სწორი ინდექსით დიდ ცხრილებზეც სწრაფი რჩება.
მაგალითი პრომპტები
მარტივი დასაწყისი:
დაამატე საძიებო ველი და ფილტრები განცხადებების გვერდზე. ძიება უნდა ემთხვეოდეს მოთხოვნას სათაურსა და აღწერაში, რეგისტრის გათვალისწინების გარეშე. ფილტრები: კატეგორია (ჩამოსაშლელი), ქალაქი (ჩამოსაშლელი) და მაქსიმალური ფასი. ძიება გააკეთე სერვერზე გვერდებად დაყოფილი API მარშრუტით, თითო გვერდზე 20 შედეგი. ძიებისა და ფილტრების მდგომარეობა შეინახე URL-ში, რომ შედეგების გაზიარება და უკან დაბრუნების ღილაკი მუშაობდეს. თუ არაფერი მოიძებნა, აჩვენე მეგობრული ცარიელი მდგომარეობა.
გადასვლა სრულტექსტურ ძიებაზე:
გადაიყვანე განცხადებების ძიება Postgres-ის სრულტექსტურ ძიებაზე სათაურზე (მაღალი წონით) და აღწერაზე. დაამატე სწორი ინდექსი, შედეგები დაარანჟირე რელევანტობით და შეინარჩუნე არსებული ფილტრები და გვერდებად დაყოფა. არცერთი არსებული მონაცემი არ შეცვალო.
სახელებისთვის შეცდომების ტოლერანტობის დამატება:
დაამატე fuzzy matching ბიზნესის სახელზე, რომ მცირე შეცდომებიც შედეგებს პოულობდეს. გამოიყენე trigram მსგავსება, თუ ხელმისაწვდომია, ინდექსით, და თუ არა — დაუბრუნდი მიმდინარე ძიებას.
ნაბიჯ-ნაბიჯ
- ჩამოწერეთ, რას ეძებენ ხალხი. რომელი ველები (სათაური, აღწერა, ტეგები, სახელი)? რომელი ფილტრები? თუ შეგიძლიათ, ჰკითხეთ რამდენიმე რეალურ მომხმარებელს.
- დაიწყეთ სერვერზე. დაამატეთ API მარშრუტი, რომელიც იღებს მოთხოვნასა და ფილტრებს და აბრუნებს ერთ გვერდს შედეგებით. ყველაფერი ბრაუზერში არ ჩატვირთოთ.
- გამოიყენეთ უფლებები შეკითხვაში. თუ მომხმარებლები მხოლოდ საკუთარ ჩანაწერებს ან მხოლოდ გამოქვეყნებულ ჩანაწერებს ხედავენ, ეს პირობა იმავე შეკითხვაში უნდა იყოს, რაც ძიება.
- დაამატეთ გვერდებად დაყოფა პირველი დღიდანვე — ნომრებით გვერდები ან „მეტის ჩატვირთვა“.
- ძიების მდგომარეობა URL-ში შეინახეთ (მაგალითად
?q=garden&city=leeds). ეს იძლევა გაზიარებად ბმულებს, მუშა უკან ღილაკს, და საძიებო სისტემებს შეუძლიათ გაფილტრული გვერდების მოძებნაც, თუ გინდათ. - დაამუშავეთ ძიება წერისას გაჩერებით (debounce). რამდენიმე ასეული მილიწამი დაელოდეთ წერის შეწყვეტამდე, სანამ შეკითხვას გაგზავნით, რომ ყოველ ღილაკზე მოთხოვნა არ წავიდეს.
- დაამატეთ ინდექსები, როცა უკვე იცით, რომელ სვეტებზე ძებნით და ფილტრავთ.
- გააუმჯობესეთ სრულტექსტურ ძიებამდე, შემდეგ fuzzy matching-მდე, შემდეგ კი ჰოსტირებულ სისტემამდე — მხოლოდ მაშინ, როცა უფრო მარტივი ნაბიჯი რეალურ მომხმარებლებთან ვერ მუშაობს.
- ატესტეთ რეალურ ჰგავს მონაცემებზე: ასეულობით-ათასობით სტრიქონი, უცნაური სიმბოლოები, ცარიელი მოთხოვნები, ძალიან გრძელი მოთხოვნები, სხვა ენები, თუ მათ უჭერთ მხარს.
გავრცელებული შეცდომები
- მთელი ცხრილის ბრაუზერში ჩატვირთვა. 50 ელემენტისთვის კარგია, 50 000-ისთვის ტანჯვაა, და ყოველ ჩანაწერს ავლენს — მათ შორისაც, რომლებსაც მომხმარებელი ვერ უნდა ხედავდეს.
- ძიება, რომელიც უფლებებს უგულებელყოფს. ძიება ხშირი გაჟონვის წერტილია: პირადი ან მონახაზი ჩანაწერი ჩნდება, რადგან შეკითხვამ დაივიწყა „მხოლოდ ჩემი“ ან „მხოლოდ გამოქვეყნებული“ პირობა.
- SQL-ის აგება მომხმარებლის ნედლი შეყვანისგან. ყოველთვის გამოიყენეთ პარამეტრიზებული შეკითხვები. AI ბილდერი ჩვეულებრივ ასე აკეთებს, მაგრამ შეამოწმეთ, თუ სტრიქონები ერთმანეთზე ილეწება.
- ცარიელი მდგომარეობის არქონა. „შედეგი არ არის“ წინადადებით (გაასუფთავეთ ფილტრები, შეამოწმეთ მართლწერა) ხალხს ფეხით არ გააძევებს.
- ინდექსების არქონა. ძიება სატესტო მონაცემებზე კარგად მუშაობს და რეალური მონაცემების ზრდასთან ერთად შენელდება.
- ძიების სერვისისკენ პირდაპირ ხტომა. მაშინ მონაცემების მეორე ასლი უნდა სინქრონიზაციაში ჰქონდეთ, წაშლები დაამუშაოთ და კიდევ ერთი გასაღებების კომპლექტი დაიცვათ — ხშირად უხილავი სარგებლის გამო.
- მობილურის დავიწყება. ფილტრები ტელეფონზე უნდა ეტეოდეს; ფილტრების უჯრა ან ჩაკეცვადი პანელი ჩვეულებრივ უკეთ მუშაობს, ვიდრე გვერდითი პანელი.
ჩამონათვალი
- იცით, რომელი ველები იძებნება და რომელი ფილტრები არსებობს
- ძიება სერვერზე მუშაობს და გვერდებად დაყოფილ შედეგებს აბრუნებს
- შეკითხვა ისევე ამოწმებს უფლებებს, როგორც აპის დანარჩენი ნაწილი
- მომხმარებლის შეყვანა პარამეტრებად გადაეცემა და არასდროს მიეწება SQL-ს
- ძიების მდგომარეობა URL-შია
- წერა გაჩერებით (debounce) მუშაობს
- ძიებადი და ფილტრირებადი სვეტები ინდექსირებულია
- ცარიელი, შედეგის გარეშე და შეცდომის მდგომარეობები ნათელია
- ატესტირებულია რეალისტური მონაცემთა მოცულობით და არასუფთა შეყვანით
ძიების დამატება Mythex-ით
Mythex-ზე აგებულ აპში მონაცემები ჩვეულებრივ პროექტის საკუთარ Postgres მონაცემთა ბაზაშია, ამიტომ შეგიძლიათ ზემოთ მოცემული პრომპტებით დაიწყოთ: ჯერ ნიმუშით ძიება, შემდეგ კი Postgres-ის სრულტექსტური ძიება, როცა რანჟირება დაგჭირდებათ. თუ გსურთ ჰოსტირებული საძიებო სისტემა, გამოიყენეთ თქვენი ანგარიში და გასაღები, შეინახეთ იგი პროექტის საიდუმლოებად და სთხოვეთ აგენტს, რომ ინდექსირება და მოთხოვნა სერვერიდან გააკეთოს, როგორც Integrate any API-შია აღწერილი.
ძიება ბევრი აპის გულია: იხილეთ როგორ ავაშენოთ დირექტორიის ვებსაიტი, როგორ ავაშენოთ ვაკანსიების დაფა და როგორ ავაშენოთ მარკეტფლეისი, რომ ნახოთ, როგორ ერგება ის პროდუქტის დანარჩენ ნაწილს.
კითხვები
რა არის ძიების დამატების ყველაზე მარტივი გზა აპში?
თუ მონაცემები მონაცემთა ბაზაშია, სერვერის მარშრუტი, რომელიც სტრიქონებს ფილტრავს რამდენიმე სვეტში, რეგისტრის გათვალისწინების გარეშე, ყველაზე მარტივი დასაწყისია. პატარა სიისთვის, რომელიც უკვე ბრაუზერშია ჩატვირთული, ფილტრაცია ბრაუზერში კიდევ უფრო მარტივია.
ძიებისთვის Algolia ან Elasticsearch მჭირდება?
ჩვეულებრივ არა თავდაპირველად. Postgres-ის სრულტექსტური ძიება კარგად უძლებს სიტყვების დამთხვევას, რანჟირებას და ათასობით-მილიონ სტრიქონს. ჰოსტირებული საძიებო სისტემა მაშინ ღირს, როცა გჭირდებათ ძლიერი შეცდომებისადმი მდგრადობა, მყისიერი შედეგები დიდ მონაცემებზე ან მოწინავე რელევანტობის რეგულირება.
რატომ ვერ პოულობს ჩემი ძიება შედეგებს შეცდომით დაწერილი სიტყვებისთვის?
ძირითადი დამთხვევა და სტანდარტული სრულტექსტური ძიება სიტყვებს ისე ეძებს, როგორც აკრიფეთ (ან მათ ფუძეს), ამიტომ არასწორი მართლწერა ვერ პოულობს. საჭიროა ზუსტი დამთხვევა (fuzzy matching), მაგალითად Postgres-ის trigram მსგავსება ან საძიებო სისტემა შეცდომების ტოლერანტობით.
ძიება ბრაუზერში უნდა ხდებოდეს თუ სერვერზე?
სერვერზე, ყველაფერში, რაც მცირე საჯარო სიას სცილდება. სერვერული ძიება მასშტაბირდება, პატივს სცემს უფლებებს და მთელ მონაცემთა ნაკრებს არ აგზავნის ყოველ ვიზიტორთან.