डेटा संरचना जो कुशल टैग आधारित लुकअप की अनुमति देती है

मैं निम्नलिखित के समान डेटा के भंडारण के लिए एक अत्यधिक कुशल डेटा संरचना की तलाश कर रहा हूं।

आईडी टैग ऑर्डर 1 ऑर्डर 2 
--------------------------
1 1,2 1 1
2 2,5 2 3
3 1,7 4 7
४ ६ ३ ०

मुझे लगता है कि यह मेरे टैग की अभिव्यक्ति से युक्त सभी आईडी की एक सूची देना होगा इस तरह से इस संरचना क्वेरी करने के लिए सक्षम होना चाहिए - समर्थन ANDऔर ORऔर NOTसंचालन। उदाहरण के लिए। ((1 या 2) और 7 नहीं)

मुझे परिणामों के क्रम को निर्दिष्ट करने में सक्षम होने की भी आवश्यकता है (ऑर्डर 1 या ऑर्डर 2) और वैकल्पिक ऑफसेट के साथ लौटे अधिकतम पंक्तियों को निर्दिष्ट करने में सक्षम होना चाहिए। पहले 30-100 के परिणाम लाने के लिए प्रदर्शन महत्वपूर्ण है।

अंत में, मुझे "टैग संबंधों" को देखने के लिए एक सस्ते तरीके की आवश्यकता है, उदाहरण के लिए मैं यह जानना चाहता हूं कि कौन से टैग "1" या टैग से संबंधित हैं और किस आवृत्ति में हैं। मतलब जो टैग 1 या 2 ... आवृत्ति द्वारा आदेश के रूप में एक ही सेट में दिखाई देते हैं।

इस तरह के काम के लिए क्या डेटा संरचना (या संरचनाओं का सेट) का कोई भी विचार अत्यधिक कुशल होगा?

(मैं इसे साइटों के एसई परिवार के टैग किए गए पृष्ठों को फिर से डिज़ाइन करने के लिए अवधारणा के प्रमाण के रूप में उपयोग करना चाहूंगा )

ds.data-structures application-of-theory db.databases

— सैम केसर
स्रोत

बस एक टिप्पणी (शायद तुच्छ)। आप एक रिलेशनल डेटाबेस मैनेजमेंट सिस्टम पर निर्भर क्यों नहीं हैं? आप <id, टैग> जोड़े के साथ एक तालिका को परिभाषित कर सकते हैं और टैग कॉलम पर एक इंडेक्स जोड़ सकते हैं। तब आप डेटा निकालने के लिए मानक SQL प्रश्नों का उपयोग कर सकते हैं। RDBMS कुशलतापूर्वक क्वेरी ऑप्टिमाइज़ेशन और आउटपुट सॉर्टिंग का "गंदा" कार्य करेगा।

— मारजियो दे बियासी

@, भाव उच्च स्तर पर अविश्वसनीय रूप से अक्षम हैं, स्व-स्वप्न बुरे सपने बन जाते हैं।

— सैम केसर

@ नम: ठीक है। आपका कार्य काफी सामान्य है इसलिए मैंने सोचा कि एक अच्छा RDBMS (डेटा खनन उपकरण के साथ) काम कर सकता है। मैं फर्श को एक डेटा संरचना विशेषज्ञ के पास छोड़ देता हूं। :-)

— मार्जियो डी बियासी

मेरा मानना है कि AND, OR, के सभी संयोजनों को अनुमति देना मुश्किल नहीं है, यह एक डेटा संरचना बनाना मुश्किल है जो सभी वस्तुओं के माध्यम से सूचीबद्ध नहीं करता है (शायद यह 3-CNF तक सीमित हो सकता है?)। यदि ऐसी कोई सीमा मौजूद नहीं है, तो शायद रिकॉर्ड्स (निर्दिष्ट क्रम में) के माध्यम से चलाएं जब तक आपको 30-100 न मिलें जो आपकी टैग आवश्यकताओं को पूरा करते हैं। हालांकि, सामान्य तौर पर, मैं आपके लिए भारी उठाने के लिए डेटाबेस का उपयोग करने के वोर के सुझाव से सहमत हूं।

— bbejot 15

एक विशेषज्ञ नहीं है, लेकिन मुझे लगता है कि अगर आप टैग के बारे में पूछ सकते हैं तो कुछ प्रतिबंध नहीं लगाएंगे तो यह मुश्किल होने वाला है। उन्हें CNFs तक सीमित करना (जैसा कि bbejot ने सुझाव दिया है) एक तरीका है, दूसरा उन विभिन्न टैगों की संख्या को सीमित कर रहा है जिनके बारे में क्वेरी एक छोटी संख्या (6 के अनुसार) पूछ सकती है।

— केवह

जवाबों:

यह वास्तव में एक कुशल डेटा संरचना का जवाब नहीं है, बल्कि @bbejot और @Kaveh की टिप्पणियों पर विस्तार के साथ एक हाथ से लहराते हुए तर्क देते हैं कि क्यों वर्तमान प्रश्न को देखते हुए हमें ऐसी चीज की उम्मीद नहीं करनी चाहिए जो खोज के लिए बहुत बेहतर है पूरा डेटाबेस। तर्क एसएटी से कमी, घातीय समय परिकल्पना और बहुत सारे हाथ लहराते पर आधारित है।

$n$ $x$ $|x| = n$ $x_j = 1$ $j$ $x_j = 0$ $1$ $2^n$ $k$ $k$ $AND$ $OR$ $NOT$ $n$ $2^n$

हमें क्वेरी की लंबाई (एसएटी में कमी करके) में कुशल खोज की उम्मीद नहीं करनी चाहिए। हमें घातीय समय की परिकल्पना द्वारा डेटाबेस में सभी वस्तुओं को देखने की तुलना में बहुत बेहतर उम्मीद नहीं करनी चाहिए।

$n$ $1$

— Artem Kaznatcheev
स्रोत

अच्छा अवलोकन। प्रत्येक प्रश्न में अधिकतम 5 टैग हैं, इसलिए टैग के बारे में एक क्वेरी 5-CNF के बराबर है।

— केवह

धन्यवाद! हाँ हम 5-CNF को और अधिक यहाँ मान सकते हैं, टैगिंग व्यवहार यादृच्छिक नहीं है। सामान्य तौर पर लोग सबसे आम टैग के साथ सामान टैग करेंगे, ताकि कुछ अन्य शॉर्टकट के लिए अनुमति देगा।

— सैम केसर

@Kaveh, हमने स्मृति संरचना में एक रोल करना समाप्त किया। कुछ गैर-तुच्छ शॉर्टकट हैं, सॉर्ट एक अड़चन है, हीप सॉर्ट या संशोधित त्वरित सॉर्ट का उपयोग करके आप पूर्ण प्रकार का प्रदर्शन करने की आवश्यकता के बिना कुशलतापूर्वक शीर्ष एन का चयन करने की अनुमति देते हैं। पूर्व-गणना प्रकार आपको अधिक कुशलता से पिवोट्स लेने और पूर्ण स्कैन की आवश्यकता होने पर सॉर्ट से बचने की अनुमति देता है। मल्टीथ्रेडिंग चयनों को गति देता है। उपयोगकर्ताओं द्वारा संरचनाओं के साथ बातचीत करने से पहले बहुत सारे कार्य पृष्ठभूमि के लिए स्थगित किए जा सकते हैं। आश्चर्यजनक रूप से हमारी इन-मेमोरी संरचनाएं स्टैक ओवरफ्लो डेटा सेट पर खोज के लिए 0ms औसत हैं।

— सैम केसर

@SamSaffron - इस सुविधा का विवरण एमएसओ ने कहां दिया है? हमें यहां बग रिपोर्ट मिली है ।

— केविन वर्मेयर

यह एक बहुत सीधा जवाब है, लेकिन मुझे लगता है कि प्रभावी:

Map Tag ([Id],[Id]) $O(log (n))$

Map Id (Set Tag)Id $O(n * log (m))$

— sclv
स्रोत

मैं इस बात से सहमत हूँ कि कुछ सरल संरचनाएँ जैसे नक्शा कई बार यहाँ आया सबसे अच्छा तरीका हो सकता है। मेमोरी सस्ती है और कई कैश को बनाए रखना बहुत मुश्किल नहीं है

— सैम केसर