मेमोरी-मैप की गई फ़ाइलें: पेशेवर और विपक्ष?

Question

मुझे एक ही मशीन (दो अलग-अलग JVMs) पर चल रहे दो जावा अनुप्रयोगों के बीच डेटा साझा करने की आवश्यकता है। मैं सटीक हूं कि साझा किया जाने वाला डेटा बड़ा है (लगभग 7 जीबी)। एप्लिकेशन को डेटा को बहुत तेजी से एक्सेस करना होगा क्योंकि उन्हें आने वाली क्वेरी का जवाब बहुत अधिक दर पर देना होगा। मैं नहीं चाहता कि अनुप्रयोग प्रत्येक को डेटा की प्रतिलिपि रखें।

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

मेरा पहला सवाल यह है कि इस परिदृश्य में डेटा साझा करने के लिए दो अनुप्रयोगों के लिए अलग-अलग संभावनाएं क्या हैं (मेरा मतलब है कि डेटा की मात्रा बहुत बड़ी है और इस डेटा तक पहुंच बहुत तेज होनी चाहिए)? मैं सटीक हूं कि यह प्रश्न स्मृति-मैप किए गए I/O से संबंधित नहीं है, यह सिर्फ यह जानने के लिए कि एक ही समस्या को हल करने के अन्य तरीके क्या हैं।

मेरा दूसरा प्रश्न स्मृति-मैप की गई फ़ाइलों का उपयोग करने के पेशेवरों और विपक्ष क्या हैं?

धन्यवाद

Answer 1

मेरा पहला सवाल दो आवेदन डेटा को साझा करने के लिए अलग अलग संभावनाएं क्या कर रहे हैं?

S.Lott बताते हैं, वहाँ एक तंत्र की बहुत है:

• ओएस-स्तर message queues
• ओएस-स्तर POSIX shared memory segments
• ओएस स्तर (प्रक्रिया मृत्यु के बाद जारी रहती है) memory mappings (अज्ञात या फ़ाइल समर्थित हो सकता है)
• ओएस-स्तर anonymous pipes (यूनिडायरेक्शनल)
• ओएस-स्तर named pipes (यूनिडायरेक्शनल)
• ओएस-स्तर sockets (द्विदिश) - चाहे AF_UNIX या AF_INET या AF_INET6
• ओएस-स्तर shared global memory - मल्टी-थ्रेडेड कार्यक्रमों के लिए उपयुक्त
• फ़ाइलों
में भंडारण डेटा
• आवेदन स्तरीय message queues
• आवेदन स्तरीय blackboard-style tuplespaces
• आवेदन स्तरीय key/value stores
• आवेदन स्तरीय remote procedure call frameworks - many are available
• आवेदन स्तरीय web-based frameworks

मेरे दूसरे प्रश्न है पेशेवरों और स्मृति-मैप की गई फ़ाइलों का उपयोग कर के विपक्ष क्या हैं?

सकारात्मक:

• बहुत तेजी से - आप डेटा, संभावित zero-copy तंत्र कोई गति दंड के साथ डेटा पर सीधे संचालित करने के लिए इस्तेमाल किया जा सकता का उपयोग कैसे पर निर्भर करता है। केयर एक सुसंगत तरीके में वस्तुओं अद्यतन करने के लिए लिया जाना चाहिए। शायद 25 साल (दे या लेने के लिए), and apparently Windows has mechanisms too के लिए यूनिक्स सिस्टम पर उपलब्ध -
• बहुत पोर्टेबल होना चाहिए।

विपक्ष:

• एकल प्रणाली बंटवारे। यदि आप अपने मशीन को एकाधिक मशीनों पर वितरित करना चाहते हैं, तो साझा स्मृति एक अच्छा विकल्प नहीं है। Distributed shared memory systems are available, लेकिन वे सोचने के तरीके के लिए गलत इंटरफेस की तरह बहुत महसूस करते हैं।
• यहां तक ​​कि एक सिस्टम पर, यदि स्मृति एक NUMA node पर स्थित है, लेकिन एकाधिक नोड्स से प्रोसेसर द्वारा उपयोग की आवश्यकता है, तो इंटर नोड अनुरोध प्रत्येक नोड को स्मृति के अपने स्वयं के खंड देने की तुलना में प्रोसेसिंग को धीमा कर सकता है।
• आप केवल पॉइंटर्स स्टोर नहीं कर सकते हैं - सभी को ऑफसेट आधार पते पर संग्रहीत किया जाना चाहिए, क्योंकि स्मृति को विभिन्न प्रक्रियाओं में विभिन्न स्थानों पर मैप किया जा सकता है। मुझे नहीं पता कि जावा ऑब्जेक्ट्स के लिए इसका क्या अर्थ है, हालांकि संभवतः किसी स्मार्ट ने जावा प्रोग्रामर को पारदर्शी बनाने के लिए अपनी पूरी कोशिश की है। यदि आप अपने प्रदत्त तंत्र का उपयोग नहीं कर रहे हैं, तो आपको शायद स्वयं को काम करना होगा। (वास्तविक संकेत जावा में के बिना, शायद यह नहीं बहुत भारी है।)
• अद्यतन कर रहा है लगातार बहुत मुश्किल साबित हो गया है वस्तुओं। संदेश-पासिंग सिस्टम में immutable objects पास करने के बजाय आम तौर पर कम समवर्ती बग वाले प्रोग्राम होते हैं। (Erlang में समवर्ती प्रोग्रामिंग बहुत प्राकृतिक और सीधी-आगे महसूस करती है। imperative languages में समवर्ती प्रोग्रामिंग नए समवर्ती नियंत्रणों का एक बड़ा ढेर पेश करने का प्रयास करता है: semaphores, mutexes, spinlocks, monitors)।

Answer 2

मेमोरी मैप की फ़ाइलों सिर में दर्द की तरह लगता है। एक सरल विकल्प और कम त्रुटि प्रवण क्लस्टर जागरूक कैश के साथ साझा डेटाबेस का उपयोग करना होगा। इस तरह से केवल डेटाबेस पर लिखते हैं और पढ़ते हैं कैश से परोसा जा सकता है।

कैसे हाइबरनेट में यह करने के लिए देखने के http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache