अपने ऐप्स में त्वरित सर्वर‑साइड खोज के लिए Meilisearch

सर्वर-साइड त्वरित खोज से अपेक्षाएँ

सर्वर-साइड खोज का मतलब है कि क्वेरी आपके सर्वर (या समर्पित सर्च सर्विस) पर प्रोसेस होती है, न कि ब्राउज़र के अंदर। आपका ऐप एक सर्च रिक्वेस्ट भेजता है, सर्वर उसे इंडेक्स के खिलाफ चलाता है, और रैंक किए हुए परिणाम लौटाता है।

यह तब मायने रखता है जब आपका डेटासेट क्लाइंट पर भेजने के लिए बहुत बड़ा हो, जब आपको प्लेटफ़ॉर्म्स के बीच लगातार रेलेवेंसी चाहिए, या जब एक्सेस कंट्रोल अनिवार्य हो (उदा., आंतरिक टूल जहाँ यूजर केवल वही देख पाए जो उसके लिए मान्य हो)। यह वही डिफ़ॉल्ट चुनाव भी है जब आप एनालिटिक्स, लॉगिंग और अनुमान्य प्रदर्शन चाहते हैं।

यूज़र क्या अपेक्षा करते हैं (और तुरंत नोटिस करते हैं)

लोग सर्च इंजनों के बारे में नहीं सोचते—वे अनुभव को न्याय करते हैं। एक अच्छा “तुरंत” सर्च फ़्लो आमतौर पर मतलब रखता है:

• तेज़ फ़ीडबैक: जैसे‑जैसे यूज़र टाइप करता है, परिणाम जल्दी अपडेट हों, बिना अजीब रोक के।
• टाइपो टूट नहीं डालते: गलत वर्तनी, बदली हुई अक्षर क्रम, और आंशिक शब्द भी सही आइटम ढूँढ लें।
• उपयोगी नियंत्रण: फ़िल्टरिंग (श्रेणी, स्टेटस, प्राइस रेंज), सॉर्टिंग (नवीनतम, सस्ता), और फेसैट्स (काउंट्स प्रति फ़िल्टर) नैचुरल लगें।
• प्रासंगिक क्रम: “सबसे अच्छे” परिणाम पहले आएँ, सिर्फ़ नवीनतम या कीवर्ड‑भरे नहीं।

यदि इनमें से कोई गायब है, तो यूज़र्स अलग क्वेरीज आज़माकर, ज़्यादा स्क्रॉल करके, या खोज छोड़ कर प्रतिक्रिया देते हैं।

यह गाइड आपको क्या करने में मदद करेगा

यह लेख Meilisearch के साथ उस अनुभव को बनाने के लिए एक व्यवहारिक वॉकथ्रू है। हम कवर करेंगे कि इसे सुरक्षित तरीके से कैसे सेट करें, इंडेक्सेड डेटा को कैसे संरचित और सिंक करें, रेलेवेंसी और रैंकिंग नियम कैसे ट्यून करें, फ़िल्टर/सॉर्ट/फेसैट कैसे जोड़ें, और सुरक्षा तथा स्केलिंग के बारे में कैसे सोचें ताकि आपके ऐप के बढ़ने पर भी सर्च तेज़ रहे।

सर्वर-साइड सर्च की ताकत कहाँ है

Meilisearch अच्छा फ़िट है उन जगहों के लिए:

• डॉक्यूमेंटेशन और नॉलेज बेस (पेज तेज़ी से ढूँढें, टाइपो सहनशील)
• प्रोडक्ट कैटलॉग और मार्केटप्लेस (फ़िल्टर्स और सॉर्टिंग आवश्यक)
• आंतरिक टूल्स (रिकॉर्ड्स पर अनुमति‑आधारित खोज)
• कंटेंट साइट्स (आर्टिकल्स, गाइड्स, FAQs पर सर्च)

यहाँ लक्ष्य: ऐसे परिणाम जो तुरंत, सटीक और भरोसेमंद महसूस हों—बिना सर्च को एक बड़ा इंजीनियरिंग प्रोजेक्ट बनाए।

Meilisearch — सरल भाषा में

Meilisearch एक सर्च इंजन है जिसे आप अपने ऐप के साथ चलाते हैं। आप इसे डॉक्यूमेंट्स भेजते हैं (जैसे प्रोडक्ट्स, आर्टीकल्स, यूज़र्स, या सपोर्ट टिकट्स), और यह एक इंडेक्स बनाता है जो तेज़ सर्च के लिए ऑप्टिमाइज़्ड होता है। आपका बैकएंड (या फ्रंटेंड) Meilisearch को HTTP API के माध्यम से क्वेरी करता है और मिलीसेकंड में रैंक किए हुए परिणाम पाता है।

आउट‑ऑफ‑द‑बॉक्स क्या मिलता है

Meilisearch आधुनिक सर्च से अपेक्षित फीचर पर ध्यान देता है:

• टाइपो टॉलरेंस ताकि “iphnoe” भी “iPhone” ढूँढ ले।
• प्रासंगिकता नियंत्रण (रैंकिंग नियम) ताकि आप तय कर सकें कि आपके व्यवसाय के लिए “बेस्ट मैच” क्या है।
• फ़िल्टर्स, सॉर्टिंग और फेसैट्स ताकि यूज़र्स कैटेगरी, प्राइस रेंज, उपलब्धता या टैग्स जैसी विशेषताओं से परिणाम संकुचित कर सकें।

यह डिजाइन किया गया है ताकि यह उत्तरदायी और सहनशील लगे, भले ही क्वेरी छोटी, हल्की‑सी गलत या अस्पष्ट हो।

Meilisearch क्या नहीं है

Meilisearch आपकी प्राथमिक डेटाबेस का विकल्प नहीं है। आपका डेटाबेस लेखन, ट्रांज़ैक्शन्स और constraints के लिए स्रोत सत्य बना रहता है। Meilisearch उन फ़ील्ड की एक प्रति रखता है जिन्हें आप searchable, filterable, या displayable बनाना चुनते हैं।

एक अच्छा मानसिक मॉडल है: डेटाबेस डेटा स्टोर और अपडेट के लिए, Meilisearch तेज़ी से खोज करने के लिए।

प्रदर्शन की अपेक्षाएँ (क्या गति को प्रभावित करता है)

Meilisearch बहुत तेज़ हो सकता है, पर परिणाम कुछ व्यावहारिक फ़ैक्टर पर निर्भर करते हैं:

• डेटा का आकार और रूप (डॉक्यूमेंट्स की संख्या, फ़ील्ड्स की संख्या, आप कितना टेक्स्ट इंडेक्स कर रहे हैं)
• हार्डवेयर (CPU, RAM, डिस्क)
• कॉन्फ़िगरेशन (कौन‑से attributes searchable/filterable/sortable हैं, और आप कितनी बार रीइंडेक्स करते हैं)

छोटे‑मध्यम डेटासेट के लिए, आप अक्सर एक ही मशीन पर चला सकते हैं। जैसे‑जैसे आपका इंडेक्स बढ़ेगा, आप यह सोचेंगे कि क्या इंडेक्स करना है और अपडेट कैसे रखें—इन विषयों को हम बाद के सेक्शनों में कवर करेंगे।

अपने इंडेक्स और डेटा मॉडल की योजना बनाना

कुछ भी इंस्टॉल करने से पहले तय करें कि आप वास्तव में क्या खोजने जा रहे हैं। Meilisearch तभी “तुरंत” लगेगा जब आपके इंडेक्स और डॉक्यूमेंट्स उस तरीके से मेल खाते हों जिस तरह लोग आपके ऐप को ब्राउज़ करते हैं।

एंटिटीज को इंडेक्स में मैप करें

सबसे पहले अपने सर्चेबल एंटिटीज़ की सूची बनाएं—आमतौर पर products, articles, users, help docs, locations, आदि। कई ऐप्स में सबसे साफ़ तरीका है एक इंडेक्स प्रति एंटिटी टाइप (उदा., products, articles)। इससे रैंकिंग नियम और फ़िल्टर्स पूर्वानुमान्य रहते हैं।

यदि आपका UX एक बॉक्स में कई प्रकार खोजता है (“सब कुछ खोजें”), तो आप अलग‑अलग इंडेक्स रख सकते हैं और बैकएंड में परिणाम मर्ज कर सकते हैं, या बाद में एक समर्पित "ग्लोबल" इंडेक्स बना सकते हैं। तब तक सब कुछ एक ही इंडेक्स में फोर्स न करें जब तक फ़ील्ड्स और फ़िल्टर्स वास्तव में मेल न खाते हों।

प्राथमिक कुंजी और डॉक्यूमेंट का आकार चुनें

प्रत्येक डॉक्यूमेंट को एक स्थिर पहचानकर्ता (primary key) चाहिए। कुछ ऐसा चुनें जो:

• कभी बदलता नहीं (या बहुत ही दुर्लभ रूप से बदलता है)
• इंडेक्स में यूनिक हो
• पहले से आपके डेटाबेस में मौजूद हो (उदा., id, sku, slug)

डॉक्यूमेंट के आकार के लिए, जहाँ संभव हो फ्लैट फ़ील्ड्स पसंद करें। फ्लैट स्ट्रक्चर फिल्टर और सॉर्ट के लिए आसान होते हैं। नेस्टेड फ़ील्ड ठीक हैं जब वे एक तंग, अपरिवर्तनीय बंडल को दर्शाते हैं (उदा., author ऑब्जेक्ट), पर अपनी पूरी रिलेशनल स्कीमा जैसा नेस्टिंग न बनाएं—सर्च डॉक्यूमेंट्स read‑optimized होने चाहिए, न कि database‑shaped।

फ़ील्ड्स को वर्गीकृत करें: searchable, filterable, displayed

डॉक्यूमेंट डिज़ाइन का व्यावहारिक तरीका है कि हर फ़ील्ड को एक रोल दें:

• Searchable: टेक्स्ट जिस पर लोग टाइप करते हैं (title, name, description)
• Filterable: वे एट्रिब्यूट्स जो constraint के रूप में उपयोग होते हैं (category, price range, status, tags)
• Displayed: UI को जो वापस किया जाएगा (title, thumbnail URL, short snippet)

यह एक आम गलती रोकता है: किसी फ़ील्ड को “बस‑मामूली” इंडेक्स करना और बाद में यह आश्चर्य हो कि परिणाम शोर वाले या फ़िल्टर धीमे क्यों हैं।

बहुभाषी सामग्री की योजना बनाएं

“भाषा” आपके डेटा में अलग‑अलग अर्थ रख सकती है:

• दस्तावेज़ की भाषा (प्रत्येक आर्टिकल में lang: "en")
• यूज़र का लोकेल (UI भाषा)
• मिश्रित‑भाषा फ़ील्ड (प्रोडक्ट नाम कई भाषाओं में)

जल्दी निर्णय लें कि आप प्रति‑भाषा अलग इंडेक्स उपयोग करेंगे (सरल और पूर्वानुमान्य) या एकल इंडेक्स में भाषा फ़ील्ड्स (कम इंडेक्स, अधिक लॉजिक)। सही उत्तर इस बात पर निर्भर करता है कि क्या यूज़र्स एक समय में एक भाषा में खोजते हैं और आप अनुवाद कैसे स्टोर करते हैं।

Meilisearch को सुरक्षित तरीके से इंस्टॉल और चलाना

Meilisearch चलाना सीधा है, पर "डिफ़ॉल्ट से सुरक्षित" बनाने के लिए कुछ जानबूझ कर फैसले लेने पड़ते हैं: आप इसे कहाँ तैनात करते हैं, डेटा कैसे परसेव होता है, और मास्टर की कैसे संभाली जाती है।

तैनाती विकल्प (जो आप ऑपरेट कर सकें चुनें)

• Docker (सबसे सामान्य): शुरू करने में तेज़, अपग्रेड आसान, वातावरण के बीच सुसंगत। इसे एक पर्सिस्टेंट वॉल्यूम के साथ जोड़ें।
• VM या बेयर मेटल: जब आपके पास मानक Linux डिप्लॉयमेंट पाइपलाइन हो (systemd, log rotation, बैकअप)।
• मैनेज्ड होस्टिंग: यदि आपकी टीम सर्वर मेंटेन नहीं करना चाहती, किसी managed Meilisearch प्रदाता या प्लेटफ़ॉर्म पर देखें जो इसे add-on के रूप में देता हो। आप लचीलापन के बदले ऑपरेशंस को सरल बनाएंगे।

वातावरण के मूल बातें: स्टोरेज, मेमोरी, बैकअप, मॉनिटरिंग

Storage: Meilisearch अपना इंडेक्स डिस्क पर लिखता है। डेटा डायरेक्टरी को विश्वसनीय, परसिस्टेंट स्टोरेज पर रखें (эпhemeral कंटेनर स्टोरेज नहीं)। ग्रोथ के लिए क्षमता प्लान करें: बड़े टेक्स्ट फ़ील्ड और कई एट्रिब्यूट्स के साथ इंडेक्स तेजी से बढ़ सकते हैं।

Memory: peak लोड के तहत सर्च रिस्पॉन्सिव रखने के लिए पर्याप्त RAM अलोकेट करें। स्वैपिंग दिखाई दे तो परफ़ॉर्मेंस प्रभावित होगी।

Backups: Meilisearch डेटा डायरेक्टरी का बैकअप लें (या स्टोरेज लेयर पर स्नैपशॉट्स का उपयोग करें)। कम से कम एक बार रिस्टोर टेस्ट करें; रिस्टोर न हो सकने वाला बैकअप सिर्फ़ फ़ाइल है।

Monitoring: CPU, RAM, डिस्क उपयोग और डिस्क I/O ट्रैक करें। प्रोसेस हेल्थ और लॉग एरर्स भी मॉनिटर करें। कम से कम अलर्ट रखें यदि सर्विस बंद हो या डिस्क स्पेस कम हो।

मास्टर की सुरक्षित रूप से सेट और स्टोर करें

लोकल डेवलपमेंट के बाहर हमेशा Meilisearch को master key के साथ चलाएँ। इसे किसी सीक्रेट मैनेजर या एन्क्रिप्टेड एन्वायरनमेंट वेरिएबल स्टोर में रखें (न कि Git में, न ही plain‑text .env में)।

उदाहरण (Docker):

docker run -d --name meilisearch \
  -p 7700:7700 \
  -v meili_data:/meili_data \
  -e MEILI_MASTER_KEY="$(openssl rand -hex 32)" \
  getmeili/meilisearch:latest

नेटवर्क नियमों पर भी विचार करें: एक निजी इंटरफ़ेस पर बाइंड करें या इनबाउंड एक्सेस को प्रतिबंधित करें ताकि केवल आपका बैकएंड Meilisearch तक पहुँच सके।

पहले‑स्टार्ट चेकलिस्ट

• तैनाती विधि चुनें (Docker/VM/managed) और सुनिश्चित करें कि persistent storage कॉन्फ़िगर है।
• MEILI_MASTER_KEY को सुरक्षित सीक्रेट स्टोर के साथ सेट करें।
• सर्विस स्टार्ट करें और पुष्टि करें कि यह सही नेटवर्क से पहुँच योग्य है।
• हेल्थ/वर्ज़न रेस्पॉन्स सत्यापित करें:

curl -s http://localhost:7700/version

• लॉग कलेक्ट हो रहे हैं और बेसिक अलर्ट मौजूद हैं (प्रोसेस डाउन, कम डिस्क)।
• एक प्रारंभिक बैकअप लें (यहां तक कि असली डेटा से पहले भी) और रिस्टोर स्टेप्स दस्तावेज़ करें।

डॉक्यूमेंट्स इंडेक्स करना और सिंक रखना

Meilisearch इंडेक्सिंग असिंक्रोनस है: आप डॉक्यूमेंट भेजते हैं, Meilisearch एक टास्क कतार में डालता है, और केवल उस टास्क के सफल होने के बाद वे डॉक्यूमेंट्स सर्चेबल होते हैं। इंडेक्सिंग को एक जॉब सिस्टम की तरह व्यवहार करें, न कि एक सिंगल रिक्वेस्ट।

एक साधारण इंडेक्सिंग फ़्लो (add → wait → verify)

1. डॉक्यूमेंट जोड़ें (सुनिश्चित करें कि हर एक का एक स्थिर यूनिक id है, आमतौर पर id).

curl -X POST 'http://localhost:7700/indexes/products/documents?primaryKey=id' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_WRITE_KEY' \
  --data-binary @products.json

2. टास्क का इंतज़ार करें। API रेस्पॉन्स में taskUid शामिल होता है। पोल करें जब तक वह succeeded (या failed) न हो।

curl -X GET 'http://localhost:7700/tasks/123' \
  -H 'Authorization: Bearer YOUR_WRITE_KEY'

3. काउंट्स और बेसिक सर्च सत्यापित करें। पुष्टि करें कि इंडेक्स में अपेक्षित संख्या में डॉक्यूमेंट हैं और एक सिंपल क्वेरी परिणाम लौटाती है।

curl -X GET 'http://localhost:7700/indexes/products/stats' \
  -H 'Authorization: Bearer YOUR_WRITE_KEY'

यदि काउंट्स मेल नहीं खाते, अनुमान न लगाएं—सबसे पहले टास्क एरर डिटेल्स चेक करें।

बैचिंग जो बाद में आपको हैरान न करे

बैचिंग का मतलब है कि टास्क्स पूर्वानुमान्य और रिकवरबल रहें।

• शुरुआत में 1,000–10,000 डॉक्यूमेंट प्रति बैच रखें, या पेलोड साइज से कैप करें (कई ऐप्स के लिए 5–15 MB प्रति रिक्वेस्ट अच्छा रहता है)।
• एक बड़े अपलोड की बजाय कई छोटे बैच पसंद करें; रिट्राई करना और खराब डेटा की पहचान करना आसान होता है।
• यदि आपके पास अक्सर बदलाव होते हैं, तो बैच में लगातार इंडेक्स करें (उदाहरण: हर मिनट) बजाय कि सब कुछ बार‑बार रीबिल्ड करने के।

अपडेट बनाम फुल रीइंडेक्स

addDocuments एक upsert की तरह काम करता है: एक ही primary key वाले डॉक्यूमेंट अपडेट होते हैं, नए इन्सर्ट होते हैं। इसे सामान्य अपडेट के लिए उपयोग करें।

पूर्ण रीइंडेक्स तब करें जब:

• आप डॉक्यूमेंट के आकार में महत्वपूर्ण बदलाव करते हैं,
• आपको व्युत्पन्न फ़ील्ड्स पुनः‑गणना करनी हों,
• आपका सिंक ड्रिफ्ट कर गया हो और आप क्लीन रसेट चाहते हों।

रिमूवल के लिए स्पष्ट रूप से deleteDocument(s) कॉल करें; अन्यथा पुराने रिकॉर्ड लटके रह सकते हैं।

आइडेम्पोटेंसी: जॉब फेल होने पर सुरक्षित रिट्राई

इंडेक्सिंग को रिट्राईेबल होना चाहिए। कुंजी है स्थिर डॉक्यूमेंट ids।

• यदि एक बैच अपलोड टाइमआउट हो जाता है, आप वही बैच दोबारा भेज सकते हैं: upsert + स्थिर ids मतलब डुप्लिकेट नहीं बनेंगे।
• लौटे हुए taskUid को अपने बैच/जॉब id के साथ स्टोर करें, और टास्क स्टेटस के आधार पर रिट्राई करें।
• यदि आप एक क्व्यू चलाते हैं, तो वर्कर को "at‑least‑once" सुरक्षित बनाएं: डुप्लिकेट्स हानिरहित होने चाहिए।

प्री‑प्रोडक्शन टेस्ट के लिए सीड डेटा

प्रोडक्शन डेटा से पहले, अपने असली फ़ील्ड्स के मेल वाला एक छोटा सेट (200–500 आइटम) इंडेक्स करें। उदाहरण: products सेट जिसमें id, name, description, category, brand, price, inStock, createdAt हों। यह टास्क फ़्लो, काउंट्स, और अपडेट/डिलीट व्यवहार को सत्यापित करने के लिए पर्याप्त है—बड़े इम्पोर्ट का इंतज़ार किए बिना।

आप नियंत्रित कर सकने वाले रेलेवेंसी और रैंकिंग नियम

सर्च "रेलेवेंसी" बस यह है: क्या पहले दिखाई देता है, और क्यों। Meilisearch इसे बिना अपना स्कोरिंग सिस्टम बनाए समायोज्य बनाता है।

सही एट्रिब्यूट्स से शुरुआत करें

दो सेटिंग्स यह तय करती हैं कि Meilisearch आपके कंटेंट के साथ क्या कर सकता है:

• searchableAttributes: वे फ़ील्ड जिन्हें Meilisearch क्वेरी करते समय देखता है (उदा.: title, summary, tags)। क्रम मायने रखता है: पहले वाले फ़ील्ड्स को अधिक महत्व दिया जाता है।
• displayedAttributes: वे फ़ील्ड्स जो रेस्पॉन्स में लौटती हैं। यह प्राइवेसी और पेलोड साइज के लिए मायने रखता है—अगर कोई फ़ील्ड डिस्प्ले नहीं है तो वह वापस नहीं भेजी जाएगी।

एक व्यावहारिक बेसलाइन यह है कि कुछ हाई‑सिग्नल फ़ील्ड्स searchable रखें (title, key text), और displayed फ़ील्ड्स को UI की जरूरत तक सीमित रखें।

रैंकिंग नियम परिणाम क्रम को कैसे प्रभावित करते हैं

Meilisearch मैचिंग डॉक्यूमेंट्स को ranking rules के माध्यम से सॉर्ट करता है—यह "टाई‑ब्रेकर्स" का एक पाइपलाइन है। वैचारिक रूप से, यह पसंद करता है:

1. क्वेरी के साथ अच्छी तरह मैच करने वाले परिणाम (टाइपो‑टॉलरेंस सहित), फिर
2. ऐसे परिणाम जहाँ मैच मजबूत हैं (करीब शब्द, अधिक महत्वपूर्ण attributes में मैच), फिर
3. आपके बिजनेस लॉजिक फिट होने वाले परिणाम (कस्टम सॉर्टिंग जैसे recency या popularity)।

इसे प्रभावी रूप से ट्यून करने के लिए आपको आंतरिकताओं को याद रखने की ज़रूरत नहीं; आप मुख्यतः चुनते हैं कौन‑से फ़ील्ड महत्वपूर्ण हैं और कब कस्टम सॉर्टिंग लागू करनी है।

सामान्य ट्यूनिंग लक्ष्य (उदाहरण के साथ)

लक्ष्य: “Title matches जीतें।” title को पहले रखें:

{
  "searchableAttributes": ["title", "subtitle", "description", "tags"]
}

लक्ष्य: “नया कंटेंट पहले आए।” सॉर्ट रूल जोड़ें और क्वेरी समय पर सॉर्ट करें (या कस्टम रैंकिंग सेट करें):

{
  "sortableAttributes": ["publishedAt"],
  "rankingRules": ["sort", "typo", "words", "proximity", "attribute", "exactness"]
}

फिर अनुरोध करें:

{ "q": "release notes", "sort": ["publishedAt:desc"] }

लक्ष्य: “लोकप्रिय आइटम प्रमोट करें।” popularity को sortable बनाकर और आवश्यकतानुसार उस पर सॉर्ट करके प्रमोट करें।

बदलावों का मूल्यांकन सरल before/after टेस्ट से करें

5–10 असली यूज़र क्वेरीज लें। बदलाव से पहले टॉप परिणाम सहेजें, फिर बदलें और तुलना करें।

उदाहरण:

• पहले: क्वेरी "apple" → Apple Watch band, Pineapple slicer, Apple iPhone case
• बाद में (title‑first + exactness): क्वेरी "apple" → Apple iPhone case, Apple Watch band, Pineapple slicer

यदि “बाद” की लिस्ट यूज़र इरादे से बेहतर मेल खाती है, तो सेटिंग्स रखें। यदि किन्हीं एज केस पर यह नुकसान पहुंचा रही है, तो एक‑एक करके चीज़ें बदलें (पहले attribute order, फिर ranking rules) ताकि आप जान सकें किससे सुधार आया।

वास्तविक दुनिया की खोज के लिए फ़िल्टर्स, सॉर्टिंग और फेसैट्स

एक अच्छा सर्च बॉक्स केवल “शब्द टाइप करो, मिलान पाओ” नहीं है। लोग परिणाम संकुचित करना चाहते हैं (“सिर्फ उपलब्ध आइटम”) और उन्हें क्रम देना चाहते हैं (“सबसे सस्ता पहले”)। Meilisearch में आप यह filters, sorting, और facets के साथ करते हैं।

फ़िल्टर्स और फेसैट्स (उसी विचार के दो पहलू)

एक filter वह नियम है जो आप रिज़ल्ट सेट पर लागू करते हैं। एक facet UI में वह है जो आप यूज़र्स को उन नियमों को बनाने में मदद करने के लिए दिखाते हैं (अक्सर चेकबॉक्स या काउंट्स के रूप में)।

गैर‑तकनीकी उदाहरण:

• Category: “Shoes”, “Jackets”, “Accessories”
• Price: “Under $50”, “$50–$100”
• Status: “In stock”, “Backorder”, “Archived”

तो यूज़र “running” खोज सकता है और फिर category = Shoes और status = in_stock फ़िल्टर कर सकता है। फेसैट्स काउंट्स दिखा सकते हैं जैसे “Shoes (128)” और “Jackets (42)” ताकि यूज़र समझ सकें क्या उपलब्ध है।

फ़िल्टरबल और sortable फ़ील्ड्स कॉन्फ़िगर करें (वरना काम नहीं करेंगे)

Meilisearch को उन फ़ील्ड्स की स्पष्ट अनुमति देनी पड़ती है जिनका आप फ़िल्टर या सॉर्ट के लिए उपयोग करेंगे।

• फ़ील्ड्स को filterable मार्क करें जब आप उन पर फ़िल्टर लगाएंगे: category, status, brand, price, created_at (यदि आप समय के अनुसार फ़िल्टर करते हैं), tenant_id (अगर आप ग्राहकों को अलग‑थलग करते हैं)।
• फ़ील्ड्स को sortable मार्क करें जब आप उन पर परिणाम क्रमबद्ध करना चाहेंगे: price, rating, created_at, popularity।

इस सूची को संकुचित रखें। हर चीज़ को filterable/sortable बनाने से इंडेक्स साइज बढ़ सकता है और अपडेट्स धीमे हो सकते हैं।

तेज़ रखने के लिए पेजिनेशन और लिमिट्स

भले ही आपके पास 50,000 मैच हों, यूज़र्स केवल पहला पेज देखते हैं। छोटे पेजेस (अक्सर 20–50 परिणाम) का उपयोग करें, sensibile limit सेट करें, और offset के साथ पेजिनेट करें (या यदि आप चाहें तो नए पेजिनेशन फीचर्स उपयोग करें)। अपने ऐप में अधिकतम पेज गहराई को कैप करें ताकि महंगे “page 400” रिक्वेस्ट्स न किए जाएँ।

synonyms और stop words (वैकल्पिक, सावधानी से उपयोग करें)

• Synonyms तब मदद करते हैं जब अलग शब्दों का समान अर्थ हो (उदा., “hoodie” ↔ “sweatshirt”)। इन्हें धीरे‑धीरे जोड़ें और सर्च एनालिटिक्स की समीक्षा करें—बहुत सारे synonyms आश्चर्यजनक मैच बना सकते हैं।
• Stop words सामान्य शब्दों को हटा देते हैं (“the”, “and”)। वे शोर घटा सकते हैं, पर सटीक खोजों को भी नुकसान पहुँचा सकते हैं जैसे प्रोडक्ट नाम (“The Who”, “A Team”)। केवल स्पष्ट समस्या होने पर ही stop words कस्टमाइज़ करें।

Meilisearch को अपने एप्लिकेशन बैकएंड में इंटीग्रेट करना

सर्वर‑साइड सर्च जोड़ने का साफ़ तरीका है Meilisearch को एक स्पेशलाइज़्ड डेटा सर्विस की तरह अपने API के पीछे मानना। आपका ऐप एक सर्च रिक्वेस्ट प्राप्त करता है, Meilisearch को कॉल करता है, फिर क्लाइंट को एक क्यूरेटेड रिस्पॉन्स लौटाता है।

एक सरल बैकएंड पैटर्न

ज्यादातर टीमें इस तरह के फ़्लो के साथ काम करती हैं:

1. क्लाइंट आपके एंडपॉइंट को कॉल करता है (उदा., GET /api/search?q=wireless+headphones&limit=20).
2. आपका बैकएंड इनपुट वैलिडेट करता है, बिजनेस नियम लागू करता है, और तय करता है किस इंडेक्स को क्वेरी करना है।
3. बैकएंड Meilisearch के Search API को यूज़र क्वेरी के साथ प्लस फ़िल्टर/सॉर्ट भेजता है।
4. बैकएंड परिणामों को पोस्ट‑प्रोसेस करता है (प्राइवेट फ़ील्ड्स छुपाना, DB के साथ मर्ज, परमिशन्स लागू करना)।
5. बैकएंड क्लाइंट को एक स्थिर रिस्पॉन्स आकार लौटाता है।

यह पैटर्न Meilisearch को बदला‑जाने योग्य बनाता है और फ्रंटएंड को इंडेक्स इंटरनल्स पर निर्भर होने से रोकता है।

यदि आप एक नया ऐप बना रहे हैं (या एक आंतरिक टूल रीबिल्ड कर रहे हैं) और इस पैटर्न को जल्दी लागू करना चाहते हैं, तो Koder.ai जैसा कोई प्लेटफ़ॉर्म React UI, Go बैकएंड, और PostgreSQL के साथ पूरा फ़्लो स्कैफ़ोल्ड कर सकता है—फिर Meilisearch को एकल /api/search एंडपॉइंट के पीछे इंटीग्रेट कर सकता है ताकि क्लाइंट सरल रहे और परमिशन्स सर्वर‑साइड रहें।

फ्रंटएंड बनाम बैकएंड क्वेरी करना (और क्यों बैकएंड सुरक्षित है)

Meilisearch क्लाइंट‑साइड क्वेरींग को सपोर्ट करता है, पर बैकएंड क्वेरी करना आम तौर पर सुरक्षित होता है क्योंकि:

• सीक्रेट्स प्राइवेट रहते हैं: आप प्रिविलेज्ड API कीज़ उजागर नहीं करते।
• ऑथराइज़ेशन सुसंगत है: आपका बैकएंड यह लागू कर सकता है कि "यह यूज़र क्या देख सकता है" इससे पहले कि हिट्स लौटाई जाएँ।
• आप क्वेरी जटिलता नियंत्रित करते हैं: प्रदर्शन की सुरक्षा के लिए फ़िल्टर्स, सॉर्ट विकल्प और पेजिनेशन सीमित करें।

पब्लिक डेटा के लिए क्लाइंट‑साइड क्वेरी काम कर सकती है बशर्ते कीज़ सीमित हों, पर यदि कोई भी यूज़र‑विशिष्ट दृश्यता नियम है, तो सर्च को अपने सर्वर के माध्यम से रूट करें।

प्रासंगिकता तोड़े बिना लोकप्रिय क्वेरीज को कैश करना

सर्च ट्रैफ़िक में अक्सर रिपीट्स होते हैं (“iphone case”, “return policy”)। अपने API लेयर पर कैशिंग जोड़ें:

• अनाम ट्रैफ़िक के लिए छोटे अवधि (उदा., 10–60 सेकंड) के लिए पूरा रेस्पॉन्स कैश करें।
• कैश कीज़ को सामान्यीकृत करें (whitespace ट्रिम करें, lowercase, फ़िल्टर/सॉर्ट समावेश करें)।
• सावधानीपूर्वक इनवैलिडेट करें: तेज़ी से बदलते इंडेक्स के लिए TTL छोटा रखें बजाय कि आक्रामक purge के।

रेट‑लिमिटिंग और अब्यूज़ कंट्रोल

सर्च को सार्वजनिक‑सामना वाला एंडपॉइंट मानें:

• प्रति‑IP या प्रति‑यूज़र रेट लिमिट लागू करें।
• अधिकतम limit और अधिकतम क्वेरी लंबाई सेट करें।
• स्पष्ट बॉट्स को सॉफ्ट‑ब्लॉक करने पर विचार करें जबकि असली यूज़र्स की अनुमति रहे।

सुरक्षा मूल बातें: कीज़, एक्सेस कंट्रोल, और मल्टी‑टेनेन्सी

Meilisearch अक्सर आपके ऐप के "पीछे" रखा जाता है क्योंकि यह संवेदनशील बिजनेस डेटा तेज़ी से लौटाता है। इसे एक डेटाबेस की तरह लॉक डाउन करें, और केवल वही एक्सपोज़ करें जो हर कॉलर को दिखना चाहिए।

API कीज़: मास्टर बनाम scoped (न्यूनतम अधिकार)

Meilisearch की एक master key होती है जो सब कुछ कर सकती है: इंडेक्स बनाना/हटाना, सेटिंग्स अपडेट करना, और पढ़ना/लिखना। इसे सर्वर‑ओनली रखें।

एप्लिकेशन के लिए सीमित क्रियाओं और सीमित इंडेक्स पर API कीज़ जेनरेट करें। एक सामान्य पैटर्न:

• बैकएंड जॉब्स: एक ऐसी की जो दस्तावेज़ लिख सके और सेटिंग्स अपडेट कर सके, पर केवल विशिष्ट इंडेक्स पर।
• ऐप सर्वर: सर्च के लिए रीड‑ओनली की।
• क्लाइंट (यदि आवश्यक): एक कड़ाई से scoped search‑only की जो सख्त फ़िल्टरों के साथ हो।

न्यूनतम अधिकार का मतलब है कि एक लीकेड की डेटा डिलीट या अनधिकृत इंडेक्स पढ़ नहीं सके।

मल्टी‑टेनेन्सी: अलग इंडेक्स या tenantId से फ़िल्टर

यदि आप कई ग्राहकों (टेनेट्स) को सेवा देते हैं, तो आपके पास दो मुख्य विकल्प हैं:

1) हर टेनेट के लिए एक इंडेक्स।

इसका तर्क सरल है और क्रॉस‑टेनेंट एक्सेस जोखिम कम रहता है। कमियाँ: ज़्यादा इंडेक्स मैनेज करना और सेटिंग्स अपडेट्स को सुसंगत लागू करना।

2) साझा इंडेक्स + tenant filter।

हर डॉक्यूमेंट पर tenantId फ़ील्ड रखें और हर सर्च पर tenantId = "t_123" जैसा फ़िल्टर लागू कराएँ। यह अच्छी तरह स्केल कर सकता है, पर सुनिश्चित करें कि हर रिक्वेस्ट हमेशा यह फ़िल्टर लागू करे (आदर्शतः scoped key के ज़रिये ताकि कॉलर्स इसे हटा न सकें)।

डेटा लीक रोकना: क्या लौट सकता है नियंत्रित करें

भले ही सर्च सही हो, परिणाम ऐसे फ़ील्ड्स लीक कर सकते हैं जिन्हें आप वापस नहीं भेजना चाहते (e-mails, internal notes, cost prices)। यह नियंत्रित करें:

• displayed/retrievable attributes को सुरक्षित allowlist पर रखें।
• संवेदनशील फ़ील्ड्स को केवल तभी इंडेक्स करें जब बिल्कुल जरूरी हो—और परिणामों में उन्हें न लौटाएँ।

एक त्वरित “worst‑case” टेस्ट करें: एक सामान्य शब्द खोजें और पुष्टि करें कि कोई प्राइवेट फ़ील्ड दिखाई नहीं देता।

बुनियादी ऑपरेशनल सुरक्षा

• नेटवर्क एक्सेस सीमित करें: localhost या प्राइवेट नेटवर्क पर बाइंड करें, और इनबाउंड ट्रैफ़िक केवल आपके ऐप सर्वर्स से अनुमति दें।
• यदि आपको TLS और रेट‑लिमिटिंग चाहिए तो Meilisearch को रिवर्स प्रॉक्सी के पीछे रखें।
• कीज़ को सीक्रेट मैनेजर में स्टोर करें (न कि सोर्स कंट्रोल या फ्रंटएंड बंडल्स में) और समय‑समय पर रोटेट करें।

यदि आप सुनिश्चित नहीं हैं कि कोई की क्लाइंट‑साइड होनी चाहिए, तो मान लें “नहीं” और सर्च सर्वर‑साइड रखें।

अनुमान के बिना प्रदर्शन और स्केलिंग

Meilisearch तेज़ है जब आप दो वर्कलोड्स को अलग रखते हैं: इंडेक्सिंग (लेखन) और सर्च क्वेरीज (पठन)। अधिकांश "रहस्यमयी धीमर" बस यही हैं कि ये दोनों CPU, RAM, या डिस्क पर प्रतिस्पर्धा कर रहे हैं।

प्रदर्शन आम तौर पर कहाँ बाधित होता है

इंडेक्सिंग लोड तब स्पाइक कर सकता है जब आप बड़े बैच इम्पोर्ट करते हैं, बार‑बार अपडेट करते हैं, या कई searchable फ़ील्ड जोड़ते हैं। इंडेक्सिंग बैकग्राउंड टास्क है, पर यह CPU और डिस्क बैंडविड्थ भी खपत करता है। यदि आपकी टास्क कतार बढ़े, तो सर्च धीरे लगने लगेगा भले ही क्वेरी वॉल्यूम नहीं बदला हो।

क्वेरी लोड ट्रैफ़िक के साथ बढ़ता है, पर फीचर्स भी काम बढ़ाते हैं: अधिक फ़िल्टर्स, अधिक फेसैट्स, बड़े रिज़ल्ट सेट्स, और ज़्यादा टाइपो‑टॉलरेंस प्रति रिक्वेस्ट काम बढ़ा सकते हैं।

डिस्क I/O अक्सर चुपचाप दोषी होता है। धीमे डिस्क (या साझा वॉल्यूम पर नॉइज़ी नेइबर्स) “तुरंत” को “कभी‑कभी” बना सकते हैं। NVMe/SSD स्टोरेज प्रोडक्शन के लिए सामान्य बेसलाइन है।

व्यावहारिक स्केलिंग स्टेप्स

सरल साइज़िंग से शुरू करें: Meilisearch को पर्याप्त RAM दें ताकि इंडेक्स गर्म रहे और पर्याप्त CPU दें ताकि पीक QPS संभाल सके। फिर चिंताओं को अलग करें:

• यदि इंडेक्सिंग रीड्स में हस्तक्षेप कर रही है, तो बड़े इम्पोर्ट ऑफ‑पीक शेड्यूल करें और कई छोटे अपडेट के बदले बड़े बैच वरीयता दें।
• हाई अवेलेबिलिटी और रीड कैपेसिटी के लिए रेप्लिकास जोड़ें (आपका ऐप रेप्लिकास में सर्च रिक्वेस्ट बैलेंस कर सकता है)।
• शार्डिंग: Meilisearch ऑटोमैटिक डिस्ट्रिब्यूटेड शार्डिंग नहीं करता। यदि आप एक नोड से बाहर निकलते हैं, तो आप आवेदन‑स्तर पर डेटा को विभाजित कर सकते हैं (उदा., प्रति‑टेनेट, क्षेत्र, या समय सीमा) कई इंडेक्स/क्लस्टर्स में।

क्या मॉनिटर करें (ताकि अनुमान न लगाना पड़े)

छोटा सा सिग्नल सेट ट्रैक करें:

• Search latency (p50/p95) और थ्रूपुट
• Task queue length / task processing time (उठती कतार का मतलब है इंडेक्सिंग संभाल नहीं पा रही)
• CPU, RAM, डिस्क उपयोग और डिस्क I/O wait
• एरर रेट्स (टाइमआउट, 4xx/5xx, failed tasks)

बैकअप और अपग्रेड की योजना

बैकअप सामान्य रूटीन होना चाहिए। Meilisearch के snapshot फीचर का उपयोग शेड्यूल पर करें, स्नैपशॉट्स को बॉक्स के बाहर स्टोर करें, और समय‑समय पर रिस्टोर टेस्ट करें। अपग्रेड के लिए, रिलीज नोट्स पढ़ें, नॉन‑प्रोड में स्टेज करें, और प्लान रखें कि यदि वर्ज़न चेंज इंडेक्सिंग बिहेवियर को प्रभावित करे तो रीइंडेक्स की आवश्यकता पड़ेगी।

यदि आप अपने ऐप प्लेटफ़ॉर्म में environment snapshots और rollback उपयोग करते हैं (उदा., Koder.ai के snapshots/rollback वर्कफ़्लो के माध्यम से), तो अपने सर्च रोलआउट को समान अनुशासन के साथ अलाइन करें: बदलने से पहले स्नैपशॉट लें, हेल्थ चेक सत्यापित करें, और जानें कि कैसे जल्दी से किसी ज्ञात‑अच्छे स्थिति पर वापस जाना है।

समस्या निवारण और व्यावहारिक रोलआउट चेकलिस्ट

साफ़ इंटीग्रेशन के बाद भी, सर्च समस्याएँ कुछ सामान्य बकेट्स में आती हैं। अच्छी ख़बर: Meilisearch आपको पर्याप्त दृश्यता देता है (tasks, logs, deterministic settings) ताकि आप जल्दी डिबग कर सकें—अगर आप व्यवस्थित तरीके से जाएँ।

अक्सर होने वाली समस्याएँ (और उनका आम मतलब)

• “मेरे फ़िल्टर्स काम नहीं कर रहे”: फ़ील्ड filterableAttributes में नहीं जोड़ा गया, या डॉक्यूमेंट्स ने उस फ़ील्ड को अपेक्षित आकृति में स्टोर नहीं किया (string vs array vs nested object)।
• “परिणाम अजीब तरह से रैंक हो रहे हैं”: ranking rules, synonyms, stop words, या sortableAttributes/rankingRules की कमी गलत आइटम ऊपर धकेल रही है।
• “सर्च पुराना डेटा दिखा रही है”: इंडेक्सिंग टास्क अभी भी प्रोसेसिंग में हैं, आप जिस इंडेक्स को पढ़ रहे हैं उस पर आप लिख नहीं कर रहे, या आपका सिंक पाइपलाइन अपडेट्स/डिलीट्स ड्रॉप कर रहा है।

ऐसा डिबगिंग वर्कफ़्लो जो समझ में रहे

सबसे पहले देखें कि क्या Meilisearch ने आपका आख़िरी चेंज सफलतापूर्वक लागू किया।

1. टास्क स्टेटस जांचें: हर settings चेंज और डॉक्यूमेंट अपडेट एक असिंक्रोनस टास्क बनाता है। यदि टास्क फेल हुआ है, तो पहले उसे ठीक करें (खराब पेलोड, गलत फ़ील्ड टाइप, oversized डॉक्यूमेंट)।
2. लॉग्स के साथ एक सवाल रखें: “क्या सर्वर ने मेरी रिक्वेस्ट स्वीकार की?” फिर “क्या उसने प्रोसेस करना समाप्त किया?”—एक बार में सब कुछ स्कैन न करें।
3. एक न्यूनतम पुनरुत्पादन योग्य क्वेरी बनाएं:
   • एक इंडेक्स चुनें।
   • ऐसी क्वेरी चुनें जो एक छोटा, स्थिर सेट लौटाती हो।
   • constraints एक‑एक करके जोड़ें: पहले filter, फिर sort, फिर facets।

यदि आप किसी परिणाम को समझा नहीं पाते, तो अस्थायी रूप से अपनी कॉन्फ़िगरेशन को पीछे हटाएँ: synonyms हटाएँ, ranking tweaks घटाएँ, और एक छोटे dataset पर टेस्ट करें। जटिल प्रासंगिकता समस्याएँ 50 डॉक्यूमेंट पर 5 मिलियन पर तुलना करने से कहीं आसान होती हैं।

रोलआउट रणनीति: ब्लास्ट रेडियस घटाएँ

• टेस्ट इंडेक्स पहले: your_index_v2 को पैरेलल में बनाएं, सेटिंग्स लागू करें, और प्रोडक्शन क्वेरीज का सैंपल रिप्ले करें।
• कैनरी रोलआउट: सर्च ट्रैफ़िक का एक छोटा प्रतिशत नई इंडेक्स या नई सेटिंग्स पर रूट करें, क्लिक‑थ्रू और “नो रिजल्ट” रेट्स की तुलना करें।
• Fallback बिहेवियर: तय करें कि यदि सर्च धीमा या अनुपलब्ध हो तो यूज़र्स क्या देखें—कैश्ड रिज़ल्ट, सरल क्वेरी, या एक मित्रवत “कृपया पुनः प्रयास करें” स्टेट। सर्च फ़ेल्योर को पूरे पेज को न तोड़ने दें।

अगले कदम चेकलिस्ट

• पुष्टि करें कि filterableAttributes और sortableAttributes आपकी UI आवश्यकताओं से मेल खाते हैं।
• हर डिप्लॉयमेंट के बाद इंडेक्सिंग टास्क सफलतापूर्वक समाप्त होते हैं यह सत्यापित करें।
• एक छोटा “सर्च हेल्थ” मॉनिटर जोड़ें (latency + task failures)।
• रोलबैक का अभ्यास करें: ट्रैफ़िक वापस पिछले इंडेक्स पर स्विच करना सीखें।

Related guides: /blog (search reliability, indexing patterns, and production rollout tips).