ठीक है, मैं इसे इस तरह से काम करता हुआ देख रहा हूँ।
मुझे मोंगोडीबी के साथ एक ही समस्या है। MongoDB खोज क्षमताओं को "प्रस्तावित" करता है, लेकिन MySQL की तरह ही आपको उनका उपयोग तब तक नहीं करना चाहिए जब तक कि आप IO, CPU और मेमोरी की समस्याओं से ग्रसित न हों और सामान्य रूप से आपकी अनुक्रमणिका से निपटने के लिए बहुत अधिक सर्वरों का उपयोग करने के लिए मजबूर न हों।
यदि Sphinx (या अन्य खोज तकनीक) का उपयोग कर रहे हैं तो संपूर्ण विचार एक प्रदर्शनकारी अनुक्रमणिका खोजकर्ता के द्वारा प्रति सर्वर लागत कम करना है।
हालांकि स्फिंक्स स्टोरेज इंजन नहीं है। तालिकाओं में सटीक संबंधों को क्वेरी करना उतना आसान नहीं है, उन्होंने इसे SphinxQL के साथ थोड़ा सुधारा है लेकिन पूर्ण पाठ अनुक्रमणिका की प्रकृति के कारण यह अभी भी एक अभिन्न जुड़ाव नहीं करता है जैसा कि आप MySQL में प्राप्त करेंगे।
इसके बजाय मैं MySQL के भीतर संबंधों को संग्रहीत करता हूं लेकिन स्फिंक्स के भीतर "उपयोगकर्ताओं" की अनुक्रमणिका रखता हूं।
मेरी वेबसाइट में मेरे पास व्यक्तिगत रूप से 2 इंडेक्स हैं:
- मुख्य (जिसमें उपयोगकर्ता, वीडियो, चैनल और प्लेलिस्ट शामिल हैं)
- सहायता (सिस्टम खोज में सहायता)
ये हर मिनट में एक बार डेल्टा अपडेट होते हैं। चूंकि रीयलटाइम इंडेक्स अभी भी कभी-कभी थोड़ा प्रयोगात्मक होते हैं और मैंने व्यक्तिगत रूप से उच्च प्रविष्टि/हटाने की दर के साथ समस्याओं को देखा है, मैं अद्यतनों को अपडेट करता रहता हूं। इसलिए मैं अपनी साइट की मुख्य खोज योग्य वस्तुओं को अपडेट करने के लिए डेल्टा इंडेक्स का उपयोग करूंगा क्योंकि यह रीयलटाइम इंडेक्स (मेरे अपने परीक्षणों से) की तुलना में कम संसाधन गहन और अधिक प्रदर्शनकारी है।
हटाने की प्रक्रिया के लिए ध्यान दें और डेल्टा के माध्यम से आपका स्फिंक्स संग्रह क्या नहीं है, आपको अपने डेल्टा इंडेक्स के लिए एक किललिस्ट और कुछ फिल्टर की आवश्यकता होगी। यहाँ मेरी अनुक्रमणिका से एक उदाहरण दिया गया है:
source main_delta : main
{
sql_query_pre = SET NAMES utf8
sql_query_pre =
sql_query = \
SELECT id, deleted, _id, uid, listing, title, description, category, tags, author_name, duration, rating, views, type, adult, videos, UNIX_TIMESTAMP(date_uploaded) AS date_uploaded \
FROM documents \
WHERE id>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ) OR update_time >( SELECT last_index_time FROM sph_counter WHERE counter_id=1 )
sql_query_killlist = SELECT id FROM documents WHERE update_time>=( SELECT last_index_time FROM sph_counter WHERE counter_id=1 ) OR deleted = 1
}
यह हर मिनट में एक बार हटाने और जोड़ने की प्रक्रिया करता है जो एक वास्तविक वेब ऐप के लिए काफी वास्तविक समय है।
तो अब हम जानते हैं कि हमारे इंडेक्स को कैसे स्टोर किया जाता है। मुझे रिश्तों के बारे में बात करने की ज़रूरत है। स्फिंक्स (भले ही इसमें स्फिंक्सक्यूएल है) डेटा में इंटीग्रल जॉइन नहीं करेगा, इसलिए मैं व्यक्तिगत रूप से स्फिंक्स के बाहर संबंध बनाने की सलाह दूंगा, इतना ही नहीं बल्कि जैसा कि मैंने कहा कि इस संबंध तालिका को उच्च भार मिलेगा, इसलिए यह कुछ ऐसा है जो प्रभावित कर सकता है स्फिंक्स इंडेक्स।
मैं सभी आईडी चुनने के लिए एक प्रश्न करूंगा और आईडी के उस सेट का उपयोग करके मुख्य इंडेक्स को विशिष्ट दस्तावेज़ आईडी पर फ़िल्टर करने के लिए स्फिंक्स एपीआई पर "फ़िल्टर" विधि का उपयोग करूंगा। एक बार यह हो जाने के बाद आप सामान्य रूप से स्फिंक्स में खोज सकते हैं। इससे निपटने के लिए मैंने अब तक पाया है कि यह सबसे अधिक प्रदर्शन करने वाला तरीका है।
हर समय याद रखने वाली महत्वपूर्ण बात यह है कि स्फिंक्स एक खोज तकनीक है जबकि MySQL एक भंडारण तकनीक है। इसे ध्यान में रखें और आपको ठीक होना चाहिए।
संपादित करें
जैसा कि @ एनबी ने कहा (जिसे मैंने अपने उत्तर में अनदेखा कर दिया) स्फिंक्स में स्फिंक्सएसई है। हालांकि आदिम और अभी भी इसके विकास के परीक्षण चरण के रूप में (रीयलटाइम इंडेक्स के समान) यह स्फिंक्स को एक वास्तविक माईसाम/इनो डीबी प्रकार का भंडारण प्रदान करता है। यह कमाल का है। हालांकि चेतावनी हैं (जैसा कि किसी भी चीज़ के साथ):
- भाषा आदिम है
- जुड़ें आदिम हैं
हालांकि यह वह काम कर सकता/सकती है जिसकी आप तलाश कर रहे हैं, इसलिए इस पर ध्यान देना सुनिश्चित करें।
