သင့်အက်ပ်သို့ ရှာဖွေမှု ထည့်နည်း: ရိုးရှင်းသော စစ်ထုတ်မှုမှ စာသားအပြည့်ရှာဖွေမှုအထိ

အက်ပ်သို့ ရှာဖွေမှု ထည့်ရန် အလုပ်ဖြစ်သည့် ရိုးရှင်းဆုံးနည်းဖြင့် စတင်ပါ- server route ကို ခေါ်သော ရှာဖွေရေးအကွက်တစ်ခု ဖြစ်ပြီး ၎င်းသည် ဒေတာဘေ့စ် row များကို အကော်လံအနည်းငယ်နှင့် query ကို ကိုက်ညီအောင် စစ်ထုတ်ပေးသည်၊ အမျိုးအစား သို့မဟုတ် စျေးနှုန်းကဲ့သို့ စစ်ထုတ်မှုများ ထည့်ပါ။ ထိုနည်းဖြင့် မလုံလောက်သောအခါ- ရလဒ်များကို အဆင့်သတ်မှတ်ခြင်း၊ စကားလုံး stemming သို့မဟုတ် မှတ်တမ်းအများအပြား လိုအပ်သည့်အခါ သင့်ဒေတာဘေ့စ်၏ full-text search သို့ ပြောင်းပါ၊ typo ကို အားကောင်းစွာ ခံနိုင်ရန် သို့မဟုတ် ဒေတာအလွန်ကြီးမားသည့်အခါ ချက်ချင်းရလဒ်လိုအပ်မှသာ hosted search engine သို့ ပြောင်းပါ။ မည်သည့်နည်းလမ်းကို ရွေးသည်ဖြစ်စေ ရှာဖွေမှုသည် ခွင့်ပြုချက်များကို လေးစားရမည်- အသုံးပြုသူသည် ခွင့်မပြုသော မှတ်တမ်းများကို ဘယ်သောအခါမှ မတွေ့ရမည်။

သင့်အက်ပ်အတွက် "ရှာဖွေမှု" ဆိုသည်မှာ

ရှာဖွေမှုသည် အမျိုးမျိုးသော အရာများကို ဆိုလိုပြီး အက်ပ်အများစုသည် တစ်ခုထက်ပို လိုအပ်သည်-

စာသားဖြင့် ရှာဖွေခြင်း- စာရိုက်ကွက်တစ်ခု — “'garden' ပါဝင်သော စာရင်းများကို ရှာပါ”။
စစ်ထုတ်မှုများ- အမျိုးအစား၊ မြို့၊ စျေးနှုန်းအကွာအဝေး၊ ရက်စွဲ၊ အခြေအနေ ကဲ့သို့ ဖွဲ့စည်းထားသော ရွေးချယ်မှုများ။
စီစဉ်ခြင်း- အသစ်ဆုံး၊ အစေ့အနည်းဆုံး၊ အသင့်တော်ဆုံး။
အလိုအလျောက်ရှာပေးခြင်း- ရိုက်နေစဉ် အကြံပြုချက်များ။
စာလုံးမှားခံနိုင်မှု- “restuarant” ဟု ရိုက်လျှင်လည်း “restaurant” ကို ရှာတွေ့ရမည်။

directory၊ job board သို့မဟုတ် store တစ်ခုအတွက် စာရေးရာနေရာထက် စစ်ထုတ်မှုများက ပိုအရေးကြီးလေ့ရှိသည်။ ကိရိယာမရွေးမီ ဤတို့ထဲမှ မည်သည်တို့ကို တကယ်လိုအပ်သည်ကို ဆုံးဖြတ်ပါ။

သင့်ရွေးချယ်စရာများ

နည်းလမ်း	အလုပ်လုပ်ပုံ	သင့်တော်သည်	ကန့်သတ်ချက်များ
browser ထဲတွင် စစ်ထုတ်ခြင်း	list ကို ဖွင့်ပြီး JavaScript ဖြင့် စစ်ထုတ်သည်	လူသိများသော သေးငယ်သော list များ (ရာနှင့်ချီသော ပစ္စည်း)	ဒေတာအားလုံးကို ဖော်ကြည့်သူတိုင်းထံ ပို့သည်; list ကြီးလျှင် နှေးသည်
ဒေတာဘေ့စ် pattern ကိုက်ညီမှု	“နာမည်တွင် စာသားပါဝင်” ဟူသော server query၊ case-insensitive	အသေးစား မှ အလယ်အလတ် အက်ပ်များ၊ admin tools	ranking မရှိ; table ကြီးလျှင် နှေးနိုင်; stemming မရှိ
ဒေတာဘေ့စ် full-text search	Postgres က စကားလုံးများကို index လုပ်ပြီး ကိုက်ညီမှုများကို ranking ပေးသည်	အကြောင်းအရာ များသော အက်ပ်အများစု	typo ကို အားနည်းသည်၊ fuzzy matching ထပ်ထည့်မှသာ ကောင်းသည်
Fuzzy matching (trigrams)	Postgres က စာလုံးအစဉ်အတန်းများကို တူညီမှု တိုင်းတာသည်	နာမည်များ၊ တိုသော field များ၊ typo ခံနိုင်မှု	extension နှင့် index လိုအပ်; tuning ကြိုးစားရသည်
Hosted search engine	သီးခြား ဝန်ဆောင်မှုတစ်ခုက သင့်ဒေတာကို index လုပ်သည် (Algolia၊ Meilisearch၊ Typesense၊ Elasticsearch နှင့် အခြား)	ကြီးမားသော catalog များ၊ ချက်ချင်းရှာဖွေမှု၊ typo ကို အားကောင်းစွာ ခံနိုင်မှု	ထပ်တူ ထိန်းသိမ်းရမည့် ဝန်ဆောင်မှု၊ ပေးချေရမည့်၊ လုံခြုံအောင် ထိန်းရမည့် ဝန်ဆောင်မှု

သင့်ဒေတာ Postgres ထဲတွင် ရှိနေပြီးသားဆိုလျှင် ၎င်း၏ ထည့်သွင်းပြီးသား full-text search သည် ခိုင်မာသော အလယ်အလတ်ရွေးချယ်မှု ဖြစ်သည်။ စာသားကို စကားလုံးများအဖြစ် ခွဲပြီး stem များ (ဥပမာ “running” သည် “run” နှင့် ကိုက်ညီသည်) အဖြစ် လျှော့ချကာ အဖြစ်များသော စကားလုံးများကို လျစ်လျူရှုပြီး ကိုက်ညီမှု ကောင်းမွန်ပုံအလိုက် ရလဒ်များကို ranking ပေးနိုင်သည်။ သင့်လျော်သော index ဖြင့် table ကြီးများပေါ်တွင်ပင် မြန်ဆန်နေဆဲ ဖြစ်သည်။

အသုံးပြုနိုင်သော prompt ဥပမာများ

ရိုးရှင်းစွာ စတင်ရန်-

listings စာမျက်နှာသို့ ရှာဖွေရေးအကွက်နှင့် စစ်ထုတ်မှုများ ထည့်ပါ။ ရှာဖွေမှုသည် query ကို title နှင့် description တို့နှင့် case-insensitive ဖြင့် ကိုက်ညီစေရမည်။ စစ်ထုတ်မှုများ- အမျိုးအစား (dropdown)၊ မြို့ (dropdown) နှင့် အမြင့်ဆုံးစျေးနှုန်း။ ရှာဖွေမှုကို server ပေါ်တွင် paginated API route ဖြင့် ပြုလုပ်ပြီး စာမျက်နှာတစ်ခုလျှင် ရလဒ် ၂၀ ပြပါ။ ရှာဖွေမှုနှင့် စစ်ထုတ်မှုများကို URL ထဲတွင် ထားပါ၊ ထို့ကြောင့် ရလဒ်များကို မျှဝေနိုင်ပြီး back ခလုတ် အလုပ်လုပ်ပါစေ။ ဘာမှမကိုက်ညီပါက ရိုးရိုးသာမည်သော empty state ကို ပြပါ။

full-text search သို့ အဆင့်မြှင့်ခြင်း-

listing ရှာဖွေမှုကို title (ပိုမြင့်သော အလေးချိန်) နှင့် description ပေါ်တွင် Postgres full-text search သို့ ပြောင်းပါ။ သင့်လျော်သော index ထည့်ပြီး ရလဒ်များကို relevance ဖြင့် ranking ပေးပါ၊ ရှိပြီးသား စစ်ထုတ်မှုများနှင့် pagination ကို ထိန်းထားပါ။ ရှိပြီးသား ဒေတာကို မပြောင်းပါနှင့်။

အမည်များအတွက် typo ခံနိုင်မှု ထည့်ခြင်း-

business name ပေါ်တွင် fuzzy matching ထည့်ပါ၊ ထို့ကြောင့် စာလုံးမှားသေးငယ်သည့် ရိုက်မှုများကိုလည်း ရလဒ်ပေးနိုင်စေရန်။ ရနိုင်ပါက trigram similarity ကို index နှင့်အတူ သုံးပါ၊ မရနိုင်ပါက လက်ရှိရှာဖွေမှုသို့ ပြန်သွားပါ။

အဆင့်အလိုက် နည်းလမ်း

လူတွေ ရှာသည့်အရာများကို စာရင်းပြုစုပါ။ မည်သည့် field များ (title၊ description၊ tags၊ name)? မည်သည့် စစ်ထုတ်မှုများ? ဖြစ်နိုင်လျှင် အသုံးပြုသူ အနည်းငယ်ကို မေးကြည့်ပါ။
server ဘက်မှ စတင်ပါ။ query နှင့် စစ်ထုတ်မှုများကို လက်ခံပြီး ရလဒ် စာမျက်နှာတစ်ခုကိုသာ ပြန်ပေးသည့် API route ထည့်ပါ။ အားလုံးကို browser ထဲသို့ မတင်ပါနှင့်။
query ထဲတွင် ခွင့်ပြုချက်များကို ကျင့်သုံးပါ။ အသုံးပြုသူများက မိမိ၏ မှတ်တမ်းများ သို့မဟုတ် ထုတ်ပြန်ပြီးသားများကိုသာ မြင်ရလျှင် ထိုအခြေအနေသည် ရှာဖွေမှု query တွင် ရှိနေရမည်။
ပထမနေ့မှစ၍ pagination ထည့်ပါ။ စာမျက်နှာနံပါတ် သို့မဟုတ် “ပိုကြည့်ရန်” ခလုတ်။
ရှာဖွေမှုအခြေအနေကို URL ထဲတွင် ထားပါ (ဥပမာ ?q=garden&city=leeds)။ မျှဝေနိုင်သော link များ၊ အလုပ်လုပ်သော back ခလုတ်၊ နှင့် သင်လိုချင်ပါက search engine များက စစ်ထုတ်ထားသော စာမျက်နှာများကို crawl လုပ်နိုင်သည်။
ရိုက်နေစဉ် ရှာဖွေမှုကို debounce လုပ်ပါ။ စာရိုက်ခြင်း ရပ်ပြီးနောက် မီလီစက္ကန့် ရာနှင့်ချီ စောင့်ပြီးမှ query ပို့ပါ၊ ထို့ကြောင့် ကီးတစ်ချက်လျှင် request တစ်ခု မပို့ရ။
မည်သည့် column များကို စစ်ထုတ်ပြီး ရှာသည်ကို သိပြီးနောက် index ထည့်ပါ။
အဆင့်မြှင့်ပါ- full-text search၊ ထို့နောက် fuzzy matching၊ ထို့နောက် hosted engine — ရိုးရှင်းသော အဆင့်က အမှန်တကယ် အသုံးပြုသူများအတွက် မလုံလောက်မှသာ။
တကယ်နှင့်ဆင်တူသော ဒေတာဖြင့် စမ်းသပ်ပါ- row ရာနှင့် ထောင်ချီ၊ ထူးခြားသော စာလုံးများ၊ hosted engine မလိုဘဲ query ကွက်လပ်၊ အလွန်ရှည်သော query၊ သင် ထောက်ပံ့သော အခြားဘာသာစကားများ။

အများဆုံးဖြစ်သော အမှားများ

ဇယားတစ်ခုလုံးကို browser ထဲသို့ တင်ခြင်း။ ပစ္စည်း ၅၀ အတွက် ကောင်းသော်လည်း ၅၀,၀၀၀ အတွက် ခံစားရခက်ပြီး အသုံးပြုသူ မမြင်သင့်သော မှတ်တမ်းများအပါအဝင် အားလုံးကို ဖော်ထုတ်ပေးသည်။
ခွင့်ပြုချက်ကို လျစ်လျူရှုသော ရှာဖွေမှု။ ရှာဖွေမှုသည် အသုံးများသော လုံခြုံရေးယိုစိမ့်မှု ဖြစ်သည်- ကိုယ်ပိုင် သို့မဟုတ် မကြေညာရသေးသော မှတ်တမ်းသည် “ကိုယ်ပိုင်သာ” သို့မဟုတ် “ထုတ်ပြန်ပြီးသာ” ဟူသော အခြေအနေကို query မှ မေ့သွားသဖြင့် ပေါ်လာသည်။
raw user input မှ SQL တည်ဆောက်ခြင်း။ အမြဲ parameterised query သုံးပါ။ AI builder များက များသောအားဖြင့် ထိုသို့ သုံးသော်လည်း string များကို ကပ်ထည့်နေသည်ကို တွေ့လျှင် စစ်ဆေးပါ။
empty state မရှိခြင်း။ အကြံပြုချက် (filter ရှင်းရန်၊ စာလုံးပြန်စစ်ရန်) ပါသော “ရလဒ်မရှိ” စာသားက လူများ ထွက်မသွားစေပါ။
index မရှိခြင်း။ စမ်းသပ်ဒေတာဖြင့် ရှာဖွေမှု ကောင်းနေပြီး အမှန်ဒေတာ ကြီးလာသည်နှင့် နှေးလာသည်။
ရှာဖွေရေး ဝန်ဆောင်မှုသို့ ချက်ချင်း ခုန်ဝင်ခြင်း။ ထိုအခါ ဒေတာ မိတ္တူတစ်ခုကို ထပ်တူထိန်းရမည်၊ ဖျက်ခြင်းကို ကိုင်တွယ်ရမည်၊ ကီးအသစ်များကို လုံခြုံအောင် ထိန်းရမည် — မြင်သာသော အကျိုးအမြတ်မရှိဘဲ အများအားဖြင့် ဖြစ်သည်။
မိုဘိုင်းကို မေ့ခြင်း။ စစ်ထုတ်မှုများသည် ဖုန်းပေါ်တွင် ထိုင်ရမည်; အဖုံးဖွင့်အိတ် သို့မဟုတ် ခေါက်သိမ်းနိုင်သော panel က sidebar ထက် များသောအားဖြင့် ပိုကောင်းသည်။

စစ်ဆေးစာရင်း

မည်သည့် field များ ရှာဖွေခံရသလဲ၊ မည်သည့် စစ်ထုတ်မှုများ ရှိသလဲ သိပြီး
ရှာဖွေမှုသည် server ပေါ်တွင် ပြေးပြီး paginated ရလဒ် ပြန်ပေးသည်
query သည် အက်ပ်၏ ကျန်အပိုင်းများနှင့် တူညီသော ခွင့်ပြုချက်များကို ကျင့်သုံးသည်
အသုံးပြုသူ input ကို parameter အဖြစ်သာ ပေးပို့ပြီး SQL ထဲ ကပ်မထည့်ပါ
ရှာဖွေမှုအခြေအနေသည် URL ထဲတွင် ရှိသည်
စာရိုက်ခြင်းကို debounce လုပ်ထားသည်
ရှာဖွေသော နှင့် စစ်ထုတ်သော column များကို index ထားသည်
empty၊ ရလဒ်မရှိ နှင့် error အခြေအနေများ ရှင်းလင်းသည်
အမှန်ဆန်သော ဒေတာပမာဏနှင့် ရှုပ်ထွေးသော input ဖြင့် စမ်းသပ်ပြီး

Mythex ဖြင့် ရှာဖွေမှု ထည့်ခြင်း

Mythex ပေါ်တွင် တည်ဆောက်ထားသော အက်ပ်တွင် ဒေတာသည် များသောအားဖြင့် ပရောဂျက်၏ ကိုယ်ပိုင် Postgres ဒေတာဘေ့စ် တွင် နေထိုင်သည်၊ ထို့ကြောင့် အထက်ပါ prompt များဖြင့် စတင်နိုင်သည်- ပထမ pattern ကိုက်ညီမှု၊ ထို့နောက် ranking လိုအပ်သောအခါ Postgres full-text search။ hosted search engine လိုချင်ပါက ကိုယ်ပိုင် အကောင့်နှင့် key ကို သုံးပါ၊ project secret အဖြစ် သိမ်းပါ၊ ထို့နောက် Integrate any API တွင် ဖော်ပြထားသည့်အတိုင်း server မှ index လုပ်ပြီး query လုပ်ရန် agent ကို တောင်းဆိုပါ။

ရှာဖွေမှုသည် အက်ပ်အများအပြား၏ အဓိကဖြစ်သည်- ထုတ်ကုန်၏ ကျန်အပိုင်းများနှင့် မည်သို့ ကိုက်ညီသည်ကို သိရန် directory website တည်ဆောက်နည်း၊ job board တည်ဆောက်နည်း နှင့် marketplace တည်ဆောက်နည်း တို့ကို ကြည့်ပါ။

မေးခွန်းများ

အက်ပ်တစ်ခုသို့ ရှာဖွေမှု ထည့်ရန် အလွယ်ဆုံးနည်းလမ်းက ဘာလဲ?

သင့်ဒေတာသည် ဒေတာဘေ့စ်ထဲတွင် ရှိနေလျှင် အကော်လံအနည်းငယ်ပေါ်တွင် case-insensitive ကိုက်ညီမှုဖြင့် row များကို စစ်ထုတ်သည့် server route သည် အလွယ်ဆုံး စတင်နည်းဖြစ်သည်။ browser ထဲတွင် ရှိပြီးသား သေးငယ်သော list အတွက်ဆိုလျှင် browser ထဲတွင်ပင် စစ်ထုတ်ခြင်းက ပိုရိုးရှင်းသည်။

ရှာဖွေမှုအတွက် Algolia သို့မဟုတ် Elasticsearch လိုအပ်ပါသလား?

အစပိုင်းတွင် များသောအားဖြင့် မလိုအပ်ပါ။ Postgres full-text search က စကားလုံးကိုက်ညီမှု၊ ranking နှင့် row ထောင်ပေါင်းများစွာ/သန်းပေါင်းများစွာကို ကောင်းစွာ ကိုင်တွယ်နိုင်သည်။ hosted search engine သည် typo ကို အားကောင်းစွာ ခံနိုင်ရန်၊ ရိုက်သည်နှင့် ချက်ချင်းရလဒ် ပေးရန် သို့မဟုတ် အဆင့်မြင့် relevance tuning လိုအပ်သောအခါတွင်သာ တန်ဖိုးရှိသည်။

typo ရှိရင် ရှာဖွေမှုက ဘာကြောင့် ရလဒ်မတွေ့တာလဲ?

အခြေခံ ကိုက်ညီမှုနှင့် ရိုးရိုး full-text search သည် ရိုက်ထားသော စကားလုံး (သို့မဟုတ် ၎င်း၏ stem) ကိုသာ ရှာသောကြောင့် စာလုံးမှားရိုက်ပါက လွဲသွားသည်။ fuzzy matching လိုအပ်သည်၊ ဥပမာ Postgres ရှိ trigram similarity သို့မဟုတ် typo ကို ခံနိုင်သော search engine သုံးရမည်။

ရှာဖွေမှုကို browser ထဲတွင် ဆောင်ရွက်သင့်သလား၊ server ပေါ်တွင် ဆောင်ရွက်သင့်သလား?

လူသိများသော သေးငယ်သော list ထက်ကျော်သည့် မည်သည့်အရာအတွက်မဆို server ပေါ်တွင် ဆောင်ရွက်ပါ။ server-side ရှာဖွေမှုသည် တိုးချဲ့နိုင်ပြီး ခွင့်ပြုချက်များကို လေးစားပြီး သင့်ဒေတာအစုံလုံးကို ဖော်ကြည့်သူတိုင်းထံ မပို့ပါ။