आवेदन के लिए इन-मेमोरी सर्च इंडेक्स बहुत अधिक मेमोरी लेता है - कोई सुझाव?

Question

हमारे डेस्कटॉप एप्लिकेशन में, हमने inverted index का उपयोग करके एक सरल खोज इंजन लागू किया है।

दुर्भाग्यवश, हमारे कुछ उपयोगकर्ता डेटासेट बहुत बड़े हो सकते हैं, उदा। उलटा इंडेक्स बनने से पहले ~ 1 जीबी मेमोरी लेना। उलटा इंडेक्स स्वयं बहुत मेमोरी लेता है, जितना डेटा अनुक्रमित होता है (एक और 1 जीबी रैम)।

स्पष्ट रूप से यह स्मृति त्रुटियों के साथ समस्याएं पैदा करता है, क्योंकि 32 बिट विंडोज़ प्रति 2 जीबी मेमोरी प्रति सेकंड की सीमा है, या कम स्पेस कंप्यूटर वाले उपयोगकर्ता स्मृति मांग से निपटने के लिए संघर्ष करते हैं।

हमारे औंधा सूचकांक एक के रूप में संग्रहीत किया जाता है:

Dictionary<string, List<ApplicationObject>> 

और यह बनाई गई है डेटा लोड होने के दौरान जब प्रत्येक वस्तु के इस तरह संसाधित किया जाता है कि applicationObject के प्रमुख स्ट्रिंग और विवरण शब्द उल्टे सूचकांक में जमा हो जाती है।

तो, मेरा सवाल है: क्या खोज सूचकांक को अधिक कुशलता से अंतरिक्ष-वार स्टोर करना संभव है? शायद एक अलग संरचना या रणनीति का उपयोग करने की जरूरत है? वैकल्पिक रूप से एक प्रकार का संपीड़ित डिक्शनरी बनाना संभव है? चूंकि यह बहुत सारे तारों को संग्रहित कर रहा है, इसलिए मैं अपेक्षा करता हूं कि यह अत्यधिक संपीड़ित हो।

Answer 1

यदि यह 1 जीबी होने जा रहा है ... इसे डिस्क पर रखें। बर्कले डीबी जैसे कुछ का प्रयोग करें। यह अभी भी बहुत तेज होगा।

यहाँ एक परियोजना है कि यह करने के लिए एक .net इंटरफेस प्रदान करता है है:

http://sourceforge.net/projects/libdb-dotnet

Answer 2

मैं bobwienholt से सहमत हैं, लेकिन आप डेटासेट का अनुक्रमण रहे हैं, तो मैं इन कहीं एक डेटाबेस से आया मान। क्या यह खोजने के लिए समझ में आता है कि DTSearch या Lucene.net जैसे खोज इंजन के साथ?

Answer 3

मैं कुछ समाधान देखें:

1. आप एक सरणी में ApplicationObjects है, तो दुकान बस सूचकांक - छोटे हो सकता है।
2. यूटीएफ -8 का उपयोग करके, आप शब्दकोश को स्टोर करने के लिए थोड़ा सी ++/सीएलआई का उपयोग कर सकते हैं।
3. सभी विभिन्न तार भंडारण परेशान न हों, एक Trie

Answer 4

का उपयोग मैं आप पा सकते हैं आप बहुत छोटी सूचियों का एक बहुत मिल गया है संदेह है।

मेरा सुझाव है कि आप मोटे तौर पर आवृत्ति की तरह पता लगाते हैं - आपकी कितनी शब्दकोश प्रविष्टियों में एकल तत्व सूचियां हैं, कितने तत्वों की सूची है। आप संभावित रूप से कई अलग-अलग शब्दकोशों को स्टोर कर सकते हैं - एक के लिए "मैं केवल तब तक एक तत्व मिला "(प्रत्यक्ष मैपिंग)" मेरे पास दो तत्व हैं "(दो संदर्भों के साथ एक जोड़ी संरचना में मानचित्र) आदि जब तक यह मूर्खतापूर्ण न हो जाए - संभवतः लगभग 3 प्रविष्टियों में - जिस बिंदु पर आप सामान्य पर वापस जाते हैं सूचियों। एक साधारण इंटरफ़ेस के पीछे पूरी तरह से Encapsulate (प्रवेश प्रविष्टि/प्रविष्टियों को पुनः प्राप्त करें)। इस तरह आपके पास बहुत कम बर्बाद जगह होगी (ज्यादातर खाली बफर, मायने रखता है आदि)।

यदि इनमें से कोई भी बहुत समझ में नहीं आता है, तो मुझे बताएं और मैं कुछ कोड के साथ आने का प्रयास करूंगा।

Answer 5

क्या इंडेक्स केवल इसमें जोड़ा गया है या आप इसे से भी हटाते हैं?

Answer 6

आप ल्यूसीन के दृष्टिकोण को ले सकते हैं। सबसे पहले, आप यादृच्छिक एक्सेस इन-मेमोरी स्ट्रीम (System.IO.MemoryStream) बनाते हैं, यह स्ट्रीम ऑन-डिस्क एक को मिरर करती है, लेकिन इसका केवल एक हिस्सा (यदि आपके पास गलत हिस्सा है, तो डिस्क से दूसरे को लोड करें) । इससे एक सिरदर्द होता है, आपको अपने शब्दकोश के लिए फ़ाइल-मैप करने योग्य प्रारूप की आवश्यकता होती है। विकिपीडिया में paging technique का विवरण है।

फ़ाइल-मैप्पेबल परिदृश्य पर। यदि आप परावर्तक खोलते हैं और डिक्शनरी क्लास को प्रतिबिंबित करते हैं तो आप देखेंगे कि बाल्टी शामिल है। आप शायद इन बाल्टीओं में से प्रत्येक पृष्ठ और भौतिक फ़ाइल के रूप में उपयोग कर सकते हैं (इस तरह आवेषण तेजी से होते हैं)। फिर आप फ़ाइल में "आइटम x हटाए गए" मान को डालने से मूल्यों को भी कम कर सकते हैं और प्रत्येक फ़ाइल को अक्सर साफ़ कर देता है।

वैसे, बाल्टी समान हैंश के साथ मूल्य रखती है। यह बहुत महत्वपूर्ण है कि आपके मूल्य जो आप GetHashCode() विधि को ओवरराइड करते हैं (और संकलक आपको बराबर() के बारे में चेतावनी देगा ताकि वह भी ओवरराइड हो)। यदि आप ऐसा करते हैं तो आपको लुकअप में एक महत्वपूर्ण गति वृद्धि मिलेगी।

Answer 7

आपकी मेमोरी संरचना को पारदर्शी रूप से वापस करने के लिए मेमोरी मैप किए गए फ़ाइल Win32 API का उपयोग करने के बारे में कैसे?

http://www.eggheadcafe.com/articles/20050116.asp में इसे सक्षम करने के लिए आवश्यक PInvokes है।