शेरिंग के लिए सामान्य एसओएलआर रिकॉर्ड: _version_ मुद्दे

Question

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

डीएसपीएएस सिस्टम पुराने उपयोग आंकड़ों के रिकॉर्ड को निम्नलिखित कोड का उपयोग करके एक अलग सौर शार्ड में शेड करने के लिए एक तंत्र प्रदान करता है।

Dspace ठीकरा तर्क:

 for (File tempCsv : filesToUpload) { 
      //Upload the data in the csv files to our new solr core 
      ContentStreamUpdateRequest contentStreamUpdateRequest = new ContentStreamUpdateRequest("/update/csv"); 
      contentStreamUpdateRequest.setParam("stream.contentType", "text/plain;charset=utf-8"); 
      contentStreamUpdateRequest.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true); 
      contentStreamUpdateRequest.addFile(tempCsv, "text/plain;charset=utf-8"); 

      statisticsYearServer.request(contentStreamUpdateRequest); 
     } 
     statisticsYearServer.commit(true, true); 

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

मैंने प्रत्येक रिकॉर्ड पर एक अद्वितीय आईडी फ़ील्ड के निर्माण को मजबूर करने के लिए इन 5 मिलियन रिकॉर्ड को प्रतिस्थापित करने का प्रयास किया है। यहां वह कोड है जिसे मैं उस अद्यतन को ट्रिगर करने के लिए चला रहा हूं। क्वेरी MyQuery कई हज़ार रिकॉर्ड के बैचों पर पुनरावृत्त करता है।

मेरी रिकॉर्ड की मरम्मत की प्रक्रिया:

ArrayList<SolrInputDocument> idocs = new ArrayList<SolrInputDocument>(); 
    SolrQuery sq = new SolrQuery(); 
    sq.setQuery(myQuery); 
    sq.setRows(MAX); 
    sq.setSort("time", ORDER.asc); 

    QueryResponse resp = server.query(sq); 
    SolrDocumentList list = resp.getResults(); 

    if (list.size() > 0) { 
     for(int i=0; i<list.size(); i++) { 
      SolrDocument doc = list.get(i); 
      SolrInputDocument idoc = ClientUtils.toSolrInputDocument(doc); 
      idocs.add(idoc); 
     }   
    } 

    server.add(idocs); 
    server.commit(true, true); 
    server.deleteByQuery(myQuery); 
    server.commit(true, true); 

इस प्रक्रिया को चलाने के बाद, भंडार में रिकॉर्ड के सभी में एक विशिष्ट आईडी सौंपा है। मेरे द्वारा छुपाए गए रिकॉर्ड में _version_ फ़ील्ड मौजूद है।

जब मैं ऊपर शामिल शेरिंग प्रक्रिया को फिर से चलाने का प्रयास करता हूं, तो मुझे _version_ फ़ील्ड मान से संबंधित एक त्रुटि प्राप्त होती है और प्रक्रिया समाप्त हो जाती है। यदि मैं संस्करण फ़ील्ड को स्पष्ट रूप से सेट करने का प्रयास करता हूं, तो मुझे वही त्रुटि मिलती है।

Exception: version conflict for e8b7ba64-8c1e-4963-8bcb-f36b33216d69 expected=1484794833191043072 actual=-1 
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: version conflict for e8b7ba64-8c1e-4963-8bcb-f36b33216d69 expected=1484794833191043072 actual=-1 
    at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424) 
    at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) 

मेरा लक्ष्य इतना है कि मैं Dspace द्वारा प्रदान की ठीकरा प्रक्रिया चला सकते हैं मेरे रिकॉर्ड की मरम्मत के लिए है: जब मैं ठीकरा प्रक्रिया आह्वान

यहाँ है कि मैं का सामना कर रहा हूँ त्रुटि संदेश है। क्या आप इन रिकॉर्ड्स की मरम्मत के लिए मुझे जो अतिरिक्त कार्रवाई करना चाहिए, उसकी सिफारिश कर सकते हैं?

Answer 1

sharding कोड SolrLogger प्रतियां रिकॉर्ड में। समस्या यह है कि डीएसपीएएस 3 के बारे में डीएसपीएएस उपयोग आंकड़े दस्तावेजों में _version_ फ़ील्ड होता है, और यह फ़ील्ड शेर्डिंग के दौरान प्रतिलिपि में शामिल है।

जब _version_ फ़ील्ड वाले दस्तावेज़ों को एक सोलर इंडेक्स में जोड़ा जाता है, तो यह सोलर की आशावादी समवर्ती कार्यक्षमता को ट्रिगर करता है, जो मौजूदा दस्तावेज़ के लिए इंडेक्स में एक ही अद्वितीय आईडी के साथ जांच करता है। तर्क (http://yonik.com/solr/optimistic-concurrency/ देखें) इस तरह मोटे तौर पर चला जाता है:

• _version_> 1: दस्तावेज़ संस्करण बिल्कुल
• _version_ से मेल खाना चाहिए = 1: दस्तावेज़ मौजूद होना चाहिए
• _version_ < 0: दस्तावेज़
मौजूद नहीं चाहिए
• _version_ = 0: (सामान्य अधिलेखित यदि मौजूद है) परवाह नहीं करते

उपयोग आंकड़े दस्तावेज़ जिनमें _version_ वैल्यू> 1 है, इस प्रकार नए बनाए गए वर्ष शार्ड में एक ही अद्वितीय आईडी के साथ मौजूदा दस्तावेज़ के लिए सौर देखो; हालांकि, स्पष्ट रूप से उस बिंदु पर ऐसा कोई दस्तावेज़ नहीं है, इसलिए संस्करण संघर्ष।

शेरिंग के दौरान कॉपी प्रक्रिया अस्थायी सीएसवी फाइलें बनाती है जिन्हें तब नए कोर में आयात किया जाता है। https://wiki.apache.org/solr/UpdateCSV#skip

छोड़ देता है _version_ क्षेत्र, जो बारी में अक्षम कर देता है तो

//Upload the data in the csv files to our new solr core 
ContentStreamUpdateRequest contentStreamUpdateRequest = new ContentStreamUpdateRequest("/update/csv"); 
contentStreamUpdateRequest.setParam("stream.contentType", "text/plain;charset=utf-8"); 
+ contentStreamUpdateRequest.setParam("skip", "_version_"); 
contentStreamUpdateRequest.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true); 
contentStreamUpdateRequest.addFile(tempCsv, "text/plain;charset=utf-8"); 

तरह sharding कोड बदलने: सौभाग्य से, Solr का CSV अद्यतन हैंडलर छोड़ पैरामीटर का उपयोग कर, आयात से विशिष्ट क्षेत्रों को बाहर करने के लिए कहा था किया जा सकता है आशावादी समेकन जांच।

पर पुल अनुरोध के साथ https://jira.duraspace.org/browse/DS-2212 में चर्चा की गई है; उम्मीद है कि इसे डीएसपीएएस 5.2 में शामिल किया जाएगा।

Answer 2

उत्पन्न सीएसवी को संशोधित करना आसान होना चाहिए।

आईडी को सीएसवी में सीधे जोड़ने के लिए एफआईआर विधि से पहले ऐसा करने के लिए एक विधि जोड़ने का प्रयास करें।

FileUtils.copyInputStreamToFile (csvInputstream, csvfile); एक समारोह है कि csv फ़ाइल को फिर से खोलने और प्रत्येक पंक्ति

filesToUpload.add (csvFile) को अनिवार्य आईडी जोड़ने के लिए

// < -एक विधि कॉल; // 10000 & फिर से शुरू करें yearQueryParams.put (CommonParams.START, String.valueOf ((i + 10000)); }

(फ़ाइल tempCsv: filesToUpload) के लिए

{

(...)

Answer 3

मैं 4 के लिए 1.8.3 उन्नत करने के लिए कोशिश कर रहा था।2 मिलियन रिकॉर्ड के साथ, सभी गायब यूआईडी और संस्करण। मैंने सोलर (10,000 के बैचों में) पढ़ने के लिए एक स्क्रिप्ट लिखी, प्रतियां वापस लिखें, और अंततः मूल को हटा दें। परिणाम तब तक अच्छे लगते थे जब तक कि मैंने शेडिंग की कोशिश नहीं की, जब मैंने यहां एक ही समस्या देखी।

सीएसवी फाइलों में सही संस्करण संख्याएं थीं। अपवाद रिपोर्ट

Exception: version conflict for 38dbd4db-240e-4c9b-a927-271fee5db750 expected=1490271991641407488 actual=-1 org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: version conflict for 38dbd4db-240e-4c9b-a927-271fee5db750 expected=1490271991641407488 actual=-1

अस्थायी/temp.2012.0.csv में पहले रिकॉर्ड किया गया था, एक नया, रिक्त कोर में शुरू होता है

38dbd4db-240e-4c9b-a927-271fee5db750,1490271991641407488, ...