हम एक महत्वपूर्ण जावा एसई / एमएस SQL ​​/ db4o सिस्टम विकसित करने वाली एक बड़ी कंपनी विभाग हैं। कई वर्षों के लिए, परियोजना को एक प्रोटोटाइप से औद्योगिक संचालन में बदल दिया गया और db4o एक गणना ब्रेक में बदल गया, मैं db4o से आधुनिक noSQL तकनीक पर स्विच करना चाहता था। परीक्षण और त्रुटि मूल योजना से बहुत दूर चली गई - db4o को मना करना संभव था, लेकिन एक समझौता की कीमत पर। बिल्ली प्रतिबिंब और कार्यान्वयन विवरण के तहत।

क्या db4o तकनीक मृत है?

Habré पर db4o के बारे में इतने सारे प्रकाशन नहीं मिल पाए हैं। Stackoverflow पर, कुछ प्रकार की अवशिष्ट गतिविधि एक पुराने प्रश्न पर एक ताजा टिप्पणी या एक ताजा अनुत्तरित प्रश्न की तरह है । विकी आमतौर पर मानता है कि वर्तमान स्थिर संस्करण 2011 की तारीख है।

यह एक सामान्य धारणा बनाता है: प्रौद्योगिकी अप्रासंगिक है। यहां तक ​​कि आधिकारिक पुष्टि भी थी: एक्टियन ने नए ग्राहकों के लिए वाणिज्यिक db4o उत्पाद की पेशकश को सक्रिय रूप से आगे बढ़ाने और बढ़ावा नहीं देने का फैसला किया।

Db4o की गणना कैसे की गई

ऑब्जेक्ट ओरिएंटेड डेटाबेस का आलेख परिचय db4o की मुख्य विशेषता के बारे में बात करता है - एक डेटा योजना की पूर्ण अनुपस्थिति। आप कोई भी वस्तु बना सकते हैं

User user1 = new User("Vasya", "123456", 25); 

और फिर इसे डेटाबेस फ़ाइल में लिखें

 db.Store(user1) 

रिकॉर्ड की गई वस्तु को उस रूप में Query.execute () विधि का उपयोग करके पुनर्प्राप्त किया जा सकता है जिसमें इसे सहेजा गया था।

परियोजना की शुरुआत में, यह रिलेशनल टेबल की संरचना से परेशान किए बिना, सभी प्रस्तुत किए गए डेटा के साथ ऑडिट ट्रेल के प्रदर्शन को सुनिश्चित करना संभव बनाता है। इससे परियोजना को जीवित रहने में मदद मिली। फिर सैंडबॉक्स में कुछ संसाधन थे, और आज की गणना के अंत के तुरंत बाद, एमएस एसक्यूएल में कल के लिए डेटा लोड करना शुरू हो गया। सब कुछ लगातार बदल रहा था - यह पता लगाएं कि रात में स्वचालित रूप से क्या परोसा गया था। और db4o फाइल को एक्सेस किया जा सकता है
डिबगिंग में, वांछित दिन का एक स्नैपशॉट निकालें और प्रश्न का उत्तर दें "हमने सभी डेटा सबमिट किए, लेकिन आपने कुछ भी ऑर्डर नहीं किया।"

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

युद्ध संचालन में, इतिहास फ़ाइल ~ 35 जीबी / दिन लेती है, उतराई में लगभग एक घंटा लगता है। फ़ाइल ही अच्छी तरह से (1:10) को संपीड़ित करती है, लेकिन किसी कारण से com.db4o.ObjectContainer लाइब्रेरी संपीड़न नहीं करती है। CentOS के उत्तर में, com.db4o.query.Query लाइब्रेरी विशेष रूप से एक स्ट्रीम में एक फ़ाइल लिख / पढ़ता है। गति एक अड़चन है।

डिवाइस का योजनाबद्ध आरेख

सिस्टम का सूचना मॉडल ए, बी, सी और डी वस्तुओं का पदानुक्रम है। पदानुक्रम एक पेड़ नहीं है, लिंक सी 1 -> बी 1 ऑपरेशन के लिए आवश्यक हैं।

 ROOT || | ==>A1 | || | | ==> B1 <------ | | || | | | | ======> C1 | | | | | | | ===> C1.$D | | =======> C2 | | | | ==> B2 ==> C2.$D | | ===>A2 =======> C3 | | ==> B3 ===> C3.$D | ======> C4 | ===> C4.$D 

उपयोगकर्ता यूजर इंटरफेस (GUI) के माध्यम से सर्वर के साथ बातचीत करता है, जो com.sun.net.httpserver.HttpsServer, क्लाइंट और सर्वर एक्सचेंज XML दस्तावेजों द्वारा प्रदान किया जाता है। पहले प्रदर्शन में, सर्वर उपयोगकर्ता स्तर को एक पहचानकर्ता प्रदान करता है, जो आगे नहीं बदलता है। यदि उपयोगकर्ता को कुछ स्तर के इतिहास की आवश्यकता है, तो GUI सर्वर को XML-लिपटे पहचानकर्ता भेजता है। सर्वर डेटाबेस में खोज के लिए मुख्य मूल्यों को निर्धारित करता है, आवश्यक दिन के लिए db4o फ़ाइल को स्कैन करता है और मेमोरी में अनुरोधित ऑब्जेक्ट को प्लस उन सभी ऑब्जेक्ट्स को पुनर्प्राप्त करता है, जिन्हें यह संदर्भित करता है। निकाले गए स्तर की XML प्रस्तुति बनाता है और इसे क्लाइंट को लौटाता है।

फ़ाइल को स्कैन करते समय, डिफ़ॉल्ट रूप से db40 सभी बाल वस्तुओं को एक निश्चित गहराई तक पढ़ता है, वांछित वस्तु के साथ एक साथ बड़े पदानुक्रम को निकालता है। पढ़ने का समय conf.common () के साथ अनावश्यक फू वर्ग के लिए न्यूनतम सक्रियण गहराई सेट करके कम किया जा सकता है। ObjectClass (Foo.class) .maximumActivationDepth (1)।

अनाम कक्षाओं का उपयोग करने से यह $ 0 संलग्नक वर्ग को निहित संदर्भों के निर्माण की ओर ले जाता है। Db4o प्रक्रियाएं और ऐसे लिंक को सही ढंग से (लेकिन धीरे-धीरे) पुनर्स्थापित करता है।

0. आइडिया

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

1. ललाट दृष्टिकोण

मेरा पहला विचार org.springframework.data.mongodb.core.MongoOperations और save () विधि का उपयोग करना था, क्योंकि यह com.db4o.ObjectContainer.db.Store (user1) जैसा दिखता है। MongoDB प्रलेखन का कहना है कि दस्तावेजों को संग्रह में संग्रहीत किया जाता है, आवश्यक प्रणाली वस्तुओं को संबंधित संग्रह के दस्तावेजों के रूप में प्रस्तुत करना तर्कसंगत है। वहाँ भी @ DBRef एनोटेशन हैं जो आपको 3NF की भावना में सामान्य रूप से दस्तावेजों के बीच संबंधों को लागू करने की अनुमति देते हैं। चलो चलते हैं।

1.1। उतराई। मुख्य संदर्भ प्रकार

इस प्रणाली में बहुत पहले से डिज़ाइन किए गए पीओजेओ वर्ग शामिल हैं और इन सभी नई तकनीकों को ध्यान में रखे बिना। मानचित्र के प्रकार <POJO, POJO> का उपयोग किया जाता है, उनके साथ काम करने का एक शाखित तर्क है। मैं इस फ़ील्ड को सहेजता हूं, मुझे एक त्रुटि मिलती है

 org.springframework.data.mapping.MappingException: Cannot use a complex object as a key value. 

इस अवसर पर, केवल 2011 का पत्राचार पाया गया था , जिसमें गैर-मानक मैपिंगमॉन्गकॉन्केट विकसित करने का प्रस्ताव था। अभी तक इस समस्या को ध्यान में रखते हुए @ क्षणिक, मैं चल रहा हूँ। यह नतीजे का अध्ययन करने, बचाने के लिए निकला।

संग्रह में बचत होती है, जिसका नाम सहेजे गए वर्ग के नाम के साथ मेल खाता है। मैंने अभी तक @DBRef एनोटेशन का उपयोग नहीं किया है, इसलिए केवल एक संग्रह है, JSON दस्तावेज़ काफी बड़े और ब्रांक्ड हैं। मुझे लगता है कि जब आप ऑब्जेक्ट को सहेजते हैं, तो MongoOperations सभी (विरासत में मिला) गैर-रिक्त लिंक से गुजरता है और उन्हें एक संलग्न दस्तावेज़ के रूप में लिखता है।

1.2। उतराई। नामित क्षेत्र या सरणी?

सिस्टम मॉडल ऐसा है कि क्लास सी में एक ही क्लास डी का संदर्भ कई बार हो सकता है। एक अलग DefaultMode फ़ील्ड में और ArrayList में अन्य लिंक के बीच, कुछ इस तरह

 public class C { private D defaultMode; private List<D> listOfD = new ArrayList<D>(); public class D { .. } public C(){ this.defaultMode = new D(); listOfD.add(defaultMode); } } 

उतारने के बाद, JSON दस्तावेज़ की इसकी दो प्रतियां होंगी: डिफ़ॉल्ट नाम से संलग्न दस्तावेज़ और दस्तावेज़ सरणी का एक अनाम तत्व। पहले मामले में, दस्तावेज़ को नाम से पहुँचा जा सकता है, दूसरे में - एक सूचकांक के साथ सरणी के नाम से। आप दोनों मामलों में MongoDB संग्रह खोज सकते हैं। केवल स्प्रिंग डेटा और MongoDB के साथ काम करते हुए, मैं इस निष्कर्ष पर पहुंचा हूं कि यदि आप ध्यान से, तो आप ArrayList का उपयोग कर सकते हैं; मैंने सरणियों के उपयोग पर कोई प्रतिबंध नहीं देखा। विशेषताएँ बाद में दिखाई दीं, BI के लिए MongoDB कनेक्टर के स्तर पर।

1.3। लोड हो रहा है। कंस्ट्रक्टर तर्क

मैं MongoOperations.findOne () पद्धति का उपयोग करके सहेजे गए दस्तावेज़ को पढ़ने का प्रयास कर रहा हूं। लोड हो रहा है ऑब्जेक्ट डेटाबेस से एक अपवाद फेंकता है

 "No property name found on entity class A to bind constructor parameter to!" 

यह पता चला है कि वर्ग में एक corNName फ़ील्ड है, और निर्माता के पास एक स्ट्रिंग नाम पैरामीटर है, और इस .orpName = नाम को निर्माता निकाय में असाइन किया गया है। MongoOperations के लिए आवश्यक है कि कक्षाओं में फ़ील्ड के नाम कंस्ट्रक्टर के तर्कों के नामों से मेल खाते हों। यदि कई निर्माता हैं, तो आपको @PersistenceConstructor एनोटेशन के साथ एक का चयन करना होगा। मैं पत्राचार में खेतों और मापदंडों के नाम लाता हूं।

1.4। लोड हो रहा है। $ D और इस $ 0 के साथ

इनर नेस्टेड क्लास डी, क्लास सी के डिफ़ॉल्ट व्यवहार को एनकैप्सुलेट करता है और क्लास सी से अलग मायने नहीं रखता है। D का एक उदाहरण C के प्रत्येक उदाहरण के लिए बनाया गया है और इसके विपरीत - D के प्रत्येक उदाहरण के लिए C का एक उदाहरण है जिसने इसे उत्पन्न किया है। वर्ग D के वंशज हैं जो वैकल्पिक व्यवहारों को लागू करते हैं और सूची में संग्रहीत किए जा सकते हैं। डी के वंशजों के निर्माण के लिए एक मौजूदा ऑब्जेक्ट सी की आवश्यकता होती है।

नेस्टेड आंतरिक वर्गों के अलावा, सिस्टम अनाम आंतरिक कक्षाओं का उपयोग करता है। जैसा कि आप जानते हैं , दोनों में एक संलग्न वर्ग की आवृत्ति का एक निहित संदर्भ है। अर्थात्, CD ऑब्जेक्ट के प्रत्येक उदाहरण के भाग के रूप में, कंपाइलर इस लिंक को $ 0 बनाता है, जो मूल ऑब्जेक्ट C पर इंगित करता है।

फिर से मैं संग्रह से सहेजे गए दस्तावेज़ को पढ़ने और एक अपवाद प्राप्त करने का प्रयास करता हूं

 "No property this$0 found on entity class $D to bind constructor parameter to!" 

मुझे याद है कि कक्षा डी के तरीके C.this.fieldOfClassC संदर्भों की पूरी ताकत का उपयोग करते हैं, और कक्षा डी के वंशजों को तर्क के रूप में सी को तत्काल बनाने के लिए निर्माता की आवश्यकता होती है। यही है, मुझे MongoOperations में ऑब्जेक्ट्स बनाने का एक निश्चित क्रम प्रदान करने की आवश्यकता है ताकि D कंस्ट्रक्टर में पैरेंट ऑब्जेक्ट C को निर्दिष्ट किया जा सके।

शायद अनाम कक्षाओं का उपयोग न करना और आंतरिक कक्षाओं को सामान्य बनाना? परिष्कृत करना, या पहले से लागू प्रणाली की वास्तुकला को परिष्कृत करना एक वाह कार्य है ...

2. 3NF / @ DBRef से दृष्टिकोण

मैं दूसरी तरफ जाने की कोशिश करता हूं, प्रत्येक संग्रह को अपने संग्रह में सहेजता हूं और उनके बीच 3NF की भावना से संबंध बनाता हूं।

2.1। उतराई। @DBRef खूबसूरत है

क्लास सी में डी के लिए कई संदर्भ शामिल हैं। अगर डिफॉल्टमोड और एरियर लिस्ट लिंक को @ डीबीआरएफ के रूप में चिह्नित किया जाता है, तो दस्तावेज़ का आकार घट जाएगा, विशाल संलग्न दस्तावेजों के बजाय नीट लिंक होंगे। फील्ड सी में संग्रह सी क्षेत्र का दस्तावेज़ प्रकट होता है

 "defaultMode" : DBRef("D", ObjectId("5c496eed2c9c212614bb8176")) 

MongoDB डेटाबेस में, एक संग्रह डी स्वचालित रूप से बनाया जाता है और इसमें एक फ़ील्ड के साथ एक दस्तावेज़ होता है

 "_id" : ObjectId("5c496eed2c9c212614bb8176") 

सब कुछ सरल और सुंदर है।

2.2। लोड हो रहा है। क्लास डी कंस्ट्रक्टर

लिंक के साथ काम करते समय, C ऑब्जेक्ट जानता है कि डिफ़ॉल्ट डी ऑब्जेक्ट बिल्कुल एक बार बनाया गया है। यदि आपको डिफ़ॉल्ट डी को छोड़कर सभी डी ऑब्जेक्ट्स को बायपास करने की आवश्यकता है, तो बस लिंक की तुलना करें:

 private D defaultMode; private ArrayList<D> listOfD; for (D currentD: listOfD){ if (currentD == defaultMode) continue; doSomething(currentD); } 

मैं findOne कहता हूं (), मैं अपनी कक्षा सी का अध्ययन करता हूं। यह पता चलता है कि MongoOperations एक json दस्तावेज़ पढ़ता है और प्रत्येक @DBRef एनोटेशन के लिए डी कंस्ट्रक्टर को कॉल करता है, जो हर बार एक नई वस्तु बनाता है। मुझे एक अजीब निर्माण मिलता है - डिफॉल्टमोड फील्ड में डी के दो अलग-अलग संदर्भ और लिस्टऑफडी सरणी में, जहां लिंक समान होना चाहिए।

समुदाय से सीखना: "मेरे विचार में मंगेतर के साथ काम करने से बचना चाहिए।" आधिकारिक दस्तावेज से एक ही नस में एक और विचार : असामान्य डेटा मॉडल जहां संबंधित डेटा को एक दस्तावेज़ के भीतर संग्रहीत किया जाता है, DBRefs को हल करने के लिए इष्टतम होगा, आपके आवेदन को संदर्भित दस्तावेज़ों को वापस करने के लिए अतिरिक्त क्वेरी करना होगा।

उल्लिखित प्रलेखन पृष्ठ बहुत शुरुआत में कहता है: "मोंगोबीडी में कई उपयोग के मामलों के लिए, संबंधित डेटा मॉडल जहां संबंधित डेटा को एक दस्तावेज़ में संग्रहीत किया जाता है वह इष्टतम होगा।" क्या यह मेरे लिए लिखा है?

डिज़ाइनर के साथ फ़ोकस बताता है कि आपको किसी संबंधपरक डीबीएमएस की तरह सोचने की ज़रूरत नहीं है। पसंद है:

• यदि आप @DBRef निर्दिष्ट करते हैं:
  
  • प्रत्येक एनोटेशन के लिए निर्माता को बुलाया जाएगा और कई समान वस्तुओं का निर्माण किया जाएगा;
  • MongoOperations सभी संबंधित संग्रह से सभी दस्तावेजों को ढूंढेंगे और पढ़ेंगे। वहाँ ObjectId द्वारा सूचकांक के लिए एक अनुरोध किया जाएगा और फिर एक (बड़े) डेटाबेस के कई संग्रह से पढ़ना;
• यदि आप निर्दिष्ट नहीं करते हैं, तो "असामान्य" जौन उसी डेटा की पुनरावृत्ति के साथ सहेजा जाएगा।

मैं अपने लिए ध्यान देता हूं: आप @ डीबीआरएफ पर भरोसा नहीं कर सकते हैं, लेकिन ऑब्जेक्ट ऑब्जेक्ट के एक क्षेत्र का उपयोग करें, इसे मैन्युअल रूप से भरना। इस मामले में, के बजाय

 "defaultMode" : DBRef("D", ObjectId("5c496eed2c9c212614bb8176")) 

json दस्तावेज़ शामिल होंगे

 "defaultMode" : ObjectId("5c496eed2c9c212614bb8176") 

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

2.3। तो अब क्या?

सबटोटल। MongoDB पर db4o कार्यक्षमता को जल्दी और आसानी से लागू करना संभव नहीं था:

• यह स्पष्ट नहीं है कि कुंजी - मूल्य सूची कुंजी के रूप में कस्टम POJO का उपयोग कैसे किया जाए;
• यह स्पष्ट नहीं है कि मैपिंगमोंगोऑनकर्टर में ऑब्जेक्ट किस क्रम में बनाए गए हैं;
• यह स्पष्ट नहीं है कि DBRef के बिना "गैर-सामान्यीकृत" दस्तावेज़ अपलोड करना है या नहीं और आलसी आरंभीकरण के लिए अपने स्वयं के तंत्र के साथ आना आवश्यक है या नहीं।

आप आलसी लोडिंग जोड़ सकते हैं। आप MappingMongoConverter करने का प्रयास कर सकते हैं। आप मौजूदा कंस्ट्रक्टर / फ़ील्ड / सूची को संशोधित कर सकते हैं। लेकिन व्यापार तर्क के स्तर पर कई साल हैं - एक कमजोर परिवर्तन नहीं है और कभी भी परीक्षण नहीं होने का जोखिम है।

समझौता समाधान: जीयूआई के साथ बातचीत के लिए तंत्र को बनाए रखते हुए, समस्या को हल करने के लिए डेटा की बचत के लिए एक नया तंत्र बनाने के लिए।

3. तीसरा प्रयास, पहले दो का अनुभव

पेरेटो का सुझाव है कि उपयोगकर्ताओं की गति के साथ समस्याओं को हल करना पूरे कार्य की सफलता का मतलब होगा। कार्य यह है: आपको यह जानने की आवश्यकता है कि db4o के बिना उपयोगकर्ता प्रस्तुति डेटा को कैसे जल्दी से सहेजा और पुनर्स्थापित किया जाए।

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

3.1। कस्टम प्रस्तुति डेटा

उपयोगकर्ता स्तरों की प्रस्तुतियों का निर्माण करने के लिए, सिस्टम में एक विशेष दर्शक वर्ग है। Viewer.getXML () विधि इनपुट के रूप में एक स्तर प्राप्त करती है, इसमें से आवश्यक संख्यात्मक और स्ट्रिंग मान निकालती है और XML उत्पन्न करती है।

यदि उपयोगकर्ता ने आज की गणना का स्तर दिखाने के लिए कहा है, तो स्तर रैम में मिलेगा। अतीत से एक गणना दिखाने के लिए, com.db4o.query.Query.execute () विधि फ़ाइल में स्तर ढूंढेगी। फ़ाइल का स्तर केवल बनाए गए स्तर से लगभग अलग नहीं है और व्यूअर प्रतिस्थापन को देखे बिना प्रस्तुति का निर्माण करेगा।

मेरी समस्या को हल करने के लिए, मुझे गणना स्तर और इसकी प्रस्तुति - प्रस्तुति रूपरेखा (फ़्रेम) के बीच एक मध्यस्थ की आवश्यकता है, जो डेटा को संग्रहीत करेगा और उपलब्ध XML डेटा पर निर्माण करेगा। प्रस्तुति के निर्माण के लिए क्रियाओं की श्रृंखला लंबी हो जाएगी, हर बार एक फ्रेम उत्पन्न होगा और फ़्रेम XML उत्पन्न करेगा:

  : < > -> Viewer.getXML() : < > -> Viewer.getFrame() -> Frame.getXML() 

कहानी को सहेजते समय, आपको सभी स्तरों के फ्रेम बनाने और डेटाबेस को लिखने की आवश्यकता होगी।

3.2। उतराई

कार्य अपेक्षाकृत सरल था और इसके साथ कोई समस्या नहीं थी। XML प्रस्तुति की संरचना को दोहराते हुए, फ्रेम को स्ट्रिंग, इंटेगर और डबल के साथ तत्वों के पदानुक्रम के रूप में एक पुनरावर्ती उपकरण प्राप्त हुआ। फ़्रेम अपने सभी तत्वों से गेटएक्सएमएल () का अनुरोध करता है, इसे एक एकल दस्तावेज़ में इकट्ठा करता है, और रिटर्न करता है। MongoOperations ने फ्रेम के पुनरावर्ती स्वभाव के साथ बहुत अच्छा काम किया और प्रगति के रूप में नए प्रश्न नहीं पूछे।

अंत में, सब कुछ दूर ले गया! डिफ़ॉल्ट रूप से WiredTiger इंजन MongoDB दस्तावेज़ संग्रह को संपीड़ित करता है, फ़ाइल सिस्टम पर, प्रति दिन ~ 3.5 GB लोड हो रहा है। Db4o पर एक दस गुना कमी खराब नहीं है।

सबसे पहले, अनलोडिंग को सरल रूप से व्यवस्थित किया गया था - प्रत्येक के लिए स्तर के पेड़, MongoOperations.save () का पुनरावर्ती ट्रावेल। इस तरह की उतराई में 5.5 घंटे लगे, और इस तथ्य के बावजूद कि निर्माण प्रस्तुतियों में केवल पढ़ने वाली वस्तुएं शामिल हैं। मैं मल्टीथ्रेडिंग जोड़ता हूं: स्तर के पेड़ को पुन: प्राप्त करता हूं, सभी उपलब्ध स्तरों को एक निश्चित आकार के पैकेट में विभाजित करता हूं, पैकेट की संख्या के अनुसार Callable.call () कार्यान्वयन बनाता हूं, प्रत्येक पैकेट को हमारे अपने पैकेज में स्थानांतरित करता हूं और सभी ExecutorService.invokeAll () के माध्यम से करता हूं।

MongoOperations ने फिर कोई सवाल नहीं पूछा और मल्टी-थ्रेडेड मोड के साथ शानदार काम किया। सर्वश्रेष्ठ अनलोडिंग गति प्रदान करते हुए, पैकेज के आकार को समान रूप से चुना गया। 1000 स्तरों के पैकेज के लिए यह 15 मिनट निकला।

3.3। मोंगो बीआई कनेक्टर, या लोग इसके साथ कैसे काम करते हैं

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

 db.users.find( { numbers: { $in: [ 390, 754, 454 ] } } ); 

सामान्य के बजाय

 SELECT * FROM users WHERE numbers IN (390, 754, 454) 

BI के लिए MongoDB कनेक्टर बचाव में आता है, जिसके माध्यम से आप सारणीबद्ध रूप में संग्रह दस्तावेज़ प्रस्तुत कर सकते हैं। MongoDB डेटाबेस को दस्तावेज़-आधारित डेटाबेस कहा जाता है, यह नहीं जानता कि सारणीबद्ध रूप में फ़ील्ड / दस्तावेज़ों के पदानुक्रम को कैसे प्रस्तुत किया जाए। काम करने के लिए कनेक्टर के लिए, एक अलग .drdl फ़ाइल में भविष्य की तालिका की संरचना का वर्णन करना आवश्यक है, जिसका प्रारूप यमल के समान है। फ़ाइल में, आपको आउटपुट पर संबंधपरक तालिका के क्षेत्र और इनपुट पर JSON दस्तावेज़ के क्षेत्र के बीच के पत्राचार को निर्दिष्ट करना होगा।

3.4। सरणियों का उपयोग कर सुविधाएँ

ऊपर कहा गया था कि MongoDB के लिए खुद एक सरणी और फ़ील्ड के बीच कोई विशेष अंतर नहीं है। कनेक्टर के दृष्टिकोण से, एक सरणी एक नामित क्षेत्र से बहुत अलग है; मैं भी समाप्त फ्रेम वर्ग refactor करने के लिए किया था। दस्तावेजों की एक सरणी का उपयोग केवल तभी किया जाना चाहिए जब किसी लिंक की गई तालिका में जानकारी का हिस्सा डालना आवश्यक हो।

यदि JSON दस्तावेज़ नामित फ़ील्डों का एक पदानुक्रम है, तो किसी भी फ़ील्ड को दस्तावेज़ रूट से एक अवधि के माध्यम से पथ निर्दिष्ट करके पहुँचा जा सकता है, उदाहरण के लिए xy। यदि पत्राचार xy => फ़ील्डएक्सवाई DRDD फ़ाइल में निर्दिष्ट किया गया है, तो आउटपुट तालिका में कई पंक्तियाँ होंगी जैसे कि संग्रह में दस्तावेज़ हैं। प्रवेश द्वार पर। यदि कुछ दस्तावेज़ में कोई xy फ़ील्ड नहीं है, तो NULL तालिका की संगत पंक्ति में होगा।

मान लें कि हमारे पास एक MongoDB डेटाबेस है जिसे फ्रेम्स कहा जाता है, डेटाबेस में एक संग्रह A है, और MongoOperations ने इस संग्रह में कक्षा A के दो उदाहरण लिखे हैं। ये दस्तावेज हैं: पहला

 { "_id": ObjectId("5cdd51e2394faf88a01bd456"), "x": { "y": "xy string value 1"}, "days": [{ "k": "0", "v": 0.0 }, { "k": "1", "v": 0.1 }], "_class": "A" } 

और दूसरा (ObjectId अंतिम अंक से भिन्न होता है):

 { "_id": ObjectId("5cdd51e2394faf88a01bd457"), "x": { "y": "xy string value 2"}, "days": [{ "k": "0", "v": 0.3 }, { "k": "1", "v": 0.4 }], "_class": "A" } 

बीआई कनेक्टर, सूचकांक द्वारा सरणी के तत्वों तक पहुंचने में सक्षम नहीं है, और उदाहरण के लिए, तालिका में सरणी से [1] .v क्षेत्र को निकालना असंभव है। इसके बजाय, कनेक्टर $ खोल ऑपरेटर का उपयोग करके एक अलग तालिका में एक पंक्ति के रूप में दिनों के प्रत्येक तत्व का प्रतिनिधित्व कर सकता है। यह अलग तालिका पंक्ति पहचानकर्ता के माध्यम से मूल एक से कई संबंधों से जुड़ी होगी। हमारे उदाहरण में, टेबल टेबलए को संग्रह दस्तावेजों के लिए परिभाषित किया गया है और दिन सरणी के दस्तावेजों के लिए टेबलएडे। .Drdl फ़ाइल इस तरह दिखती है:

 schema: - db: Frames tables: - table: tableA collection: A pipeline: [] columns: - Name: _id MongoType: bson.ObjectId SqlName: _id SqlType: objectid - Name: xy MongoType: string SqlName: fieldXY SqlType: varchar - table: tableA_days collection: A pipeline: - $unwind: path: $days columns: - Name: _id #   MongoType: bson.ObjectId SqlName: tableA_id SqlType: objectid - Name: days.k MongoType: string SqlName: tableA_dayNo SqlType: varchar - Name: days.v MongoType: string SqlName: tableA_dayVal SqlType: varchar 

तालिकाओं की सामग्री होगी: टेबल टेबलए

और तालिका tableA_days

कुल मिलाकर

मूल सूत्रीकरण में कार्य को कार्यान्वित करना संभव नहीं था; आप सिर्फ db4o को MongoDB के साथ नहीं ले सकते और प्रतिस्थापित नहीं कर सकते। MongoOperations db4o जैसी किसी भी वस्तु को स्वचालित रूप से पुनर्स्थापित करने में सक्षम नहीं है। आप शायद ऐसा कर सकते हैं, लेकिन श्रम लागत db4o लाइब्रेरी के स्टोर / क्वेरी विधियों को कॉल करने के लिए तुलनीय नहीं होगी।

ऑडिट ट्रेल। Db4o एक परियोजना की शुरुआत में एक बहुत ही उपयोगी उपकरण है। आप बस ऑब्जेक्ट लिख सकते हैं, फिर इसे पुनर्स्थापित कर सकते हैं और एक ही समय में कोई चिंता और टेबल नहीं। एक महत्वपूर्ण चेतावनी के साथ यह सब: यदि आपको कक्षाओं के पदानुक्रम को बदलने की आवश्यकता है (ए और बी के बीच वर्ग ई जोड़ें), तो पहले से संग्रहीत सभी जानकारी अपठनीय हो जाती है। लेकिन एक परियोजना शुरू करने के लिए यह बहुत महत्वपूर्ण नहीं है, जब तक कि पुरानी फ़ाइलों का कोई बड़ा संचित सरणी नहीं है।

जब MongoOperations के साथ पर्याप्त अनुभव था, तो अपलोड लिखने से कोई समस्या नहीं हुई। ढांचे के लिए एक नया कोड लिखना पुराने वाले को फिर से तैयार करने की तुलना में बहुत आसान है, जिसे उत्पादन पर भी रखा गया है।