एक कार्यात्मक DBMS और NoSQL ERP के रास्ते पर: शेष राशि और लागत का भंडारण

नमस्कार, हेब्र!

हम ईआरपी के डिजाइन में कार्यात्मक प्रोग्रामिंग के सिद्धांतों की प्रयोज्यता का पता लगाना जारी रखते हैं। पिछले लेख में, हमने इस बारे में बात की कि यह क्यों आवश्यक है, वास्तुकला की नींव रखी, और एक रिवर्स स्टेटमेंट के उदाहरण का उपयोग करके सरल संकल्पों के निर्माण का प्रदर्शन किया। वास्तव में, ईवेंट सोर्सिंग अप्रोच प्रस्तावित है, लेकिन डेटाबेस को अपरिवर्तनीय और परिवर्तनशील भागों में अलग-अलग करने के कारण, हमें एक सिस्टम में एक मैप के फायदों का संयोजन / स्टोरेज कम करने और एक इन-मेमोरी डीबीएमएस मिलता है, जो प्रदर्शन समस्या और स्केलेबिलिटी समस्या दोनों को हल करता है। इस लेख में मैं बताऊंगा (और टाइपस्क्रिप्ट और डेनो रनटाइम पर एक प्रोटोटाइप दिखाऊंगा) ऐसी प्रणाली में तत्काल शेष के रजिस्टर को कैसे स्टोर किया जाए और लागत की गणना करें। उन लोगों के लिए जिन्होंने 1 लेख नहीं पढ़ा है - एक संक्षिप्त सारांश:

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


2. प्रतिरक्षा और परस्परता । दस्तावेजों की पत्रिका 2 असमान भागों में विभाजित है:

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

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

4. दस्तावेज़ संस्करण और कैशिंग । प्रत्येक दस्तावेज़ में एक अद्वितीय कुंजी और एक अद्वितीय आईडी (कुंजी + समय टिकट) होता है। एक ही कुंजी वाले दस्तावेज़ों को एक समूह में व्यवस्थित किया जाता है, जिनमें से अंतिम रिकॉर्ड वर्तमान (वर्तमान) है, और बाकी ऐतिहासिक हैं।

एक कैश वह सब कुछ है, जिसे डिलीट किया जा सकता है और डेटाबेस शुरू होने पर दोबारा डॉक्यूमेंट जर्नल से रिस्टोर किया जाता है। हमारे सिस्टम में 3 कैश हैं:

• आईडी एक्सेस के साथ दस्तावेज़ कैश । आमतौर पर, ये निर्देशिका और अर्ध-स्थायी दस्तावेज़ होते हैं, जैसे व्यय दर पत्रिकाएँ। कैशिंग विशेषता (हाँ / नहीं) दस्तावेज़ के प्रकार से बंधा हुआ है, कैश को डेटाबेस की पहली शुरुआत में प्रारंभ किया जाता है और फिर कर्नेल द्वारा समर्थित किया जाता है।
• कुंजी पहुंच के साथ दस्तावेजों का शीर्ष कैश । निर्देशिका प्रविष्टियों और तत्काल रजिस्टरों के नवीनतम संस्करणों (जैसे शेष और शेष) को संग्रहीत करता है। शीर्ष कैशिंग की आवश्यकता का संकेत दस्तावेज़ के प्रकार से जुड़ा हुआ है, शीर्ष कैश को इस दस्तावेज़ को बनाते / संशोधित करते समय कर्नेल द्वारा अद्यतन किया जाता है।
• डेटाबेस के अपरिवर्तनीय भाग से गणना की गई संकल्‍पना संचय कुंजी / मान युग्मों का एक संग्रह है। कनवल्शन कुंजी एल्गोरिथ्म कोड + संचयकर्ता के प्रारंभिक मूल्य (जिसमें इनपुट गणना मापदंडों को प्रेषित किया जाता है) का एक स्ट्रिंग प्रतिनिधित्व है, और दृढ़ संकल्प का परिणाम संचायक का क्रमबद्ध अंतिम मूल्य है (यह एक जटिल वस्तु या संग्रह हो सकता है)।

शेष राशि का भंडारण

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

"बैलेंस" के साथ एक दस्तावेज़ खरीद / बिक्री / आंदोलन, आदि के दस्तावेजों की पंक्तियों को पोस्ट करने के क्षण में ट्रिगर द्वारा उत्पन्न होता है। बैलेंस कुंजी विश्लेषकों का एक संयोजन है, एक ही कुंजी के साथ संतुलन एक ऐतिहासिक समूह है, जिसका अंतिम तत्व शीर्ष कैश में संग्रहीत है और तुरंत उपलब्ध है। शेष पोस्टिंग नहीं हैं, और इसलिए सारांशित नहीं हैं - अंतिम रिकॉर्ड प्रासंगिक है, और सबसे पुराना रिकॉर्ड एक इतिहास रखता है।

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

उपभोग्य सामग्रियों को पोस्ट करें

प्रारंभ में, शेष राशि "खरीद" प्रकार के रसीद दस्तावेजों द्वारा बनाई जाती है और किसी भी व्यय दस्तावेजों द्वारा समायोजित की जाती है। उदाहरण के लिए, विक्रय दस्तावेज़ के लिए ट्रिगर निम्नलिखित करता है:

• शीर्ष कैश से वर्तमान शेष निकालता है
• मात्रा की उपलब्धता की जाँच करता है
• दस्तावेज़ की लाइन में वर्तमान संतुलन और तत्काल लागत के लिए एक लिंक बचाता है
• एक कम राशि और राशि के साथ एक नई बैलेंस शीट उत्पन्न करता है

बेचते समय संतुलन में बदलाव का एक उदाहरण

 //    { "type": "bal", "key": "bal|nomen.0|stock.0", "id": "bal|nomen.0|stock.0^1580006158787", "qty": 11209, //  "val": 1392411.5073958784 //  } //  "" { "type": "sale", "key": "sale.XXX", "id": "sale.XXX^1580006184280", "date": "2020-01-21", "person": "person.0^1580006048190", "stock": "stock.0^1580006048190", "lines": [ { "nomen": "nomen.0^1580006048190", "qty": 20, "price": 295.5228788368553, //   "cost": 124.22263425781769, //  "from": "bal|nomen.0|stock.0^1580006158787" // - } ] } //    { "type": "bal", "key": "bal|nomen.0|stock.0", "id": "bal|nomen.0|stock.0^1580006184281", "qty": 11189, "val": 1389927.054710722 } 

टाइपस्क्रिप्ट दस्तावेज़ हैंडलर क्लास कोड

 import { Document, DocClass, IDBCore } from '../core/DBMeta.ts' export default class Sale extends DocClass { static before_add(doc: Document, db: IDBCore): [boolean, string?] { let err = '' doc.lines.forEach(line => { const key = 'bal' + '|' + db.key_from_id(line.nomen) + '|' + db.key_from_id(doc.stock) const bal = db.get_top(key, true) // true -  ,    - const bal_qty = bal?.qty ?? 0 //   const bal_val = bal?.val ?? 0 //   if (bal_qty < line.qty) { err += '\n"' + key + '": requested ' + line.qty + ' but balance is only ' + bal_qty } else { line.cost = bal_val / bal_qty //     line.from = bal.id } }) return err !== '' ? [false, err] : [true,] } static after_add(doc: Document, db: IDBCore): void { doc.lines.forEach(line => { const key = 'bal' + '|' + db.key_from_id(line.nomen) + '|' + db.key_from_id(doc.stock) const bal = db.get_top(key, true) const bal_qty = bal?.qty ?? 0 const bal_val = bal?.val ?? 0 db.add_mut( { type: 'bal', key: key, qty: bal_qty - line.qty, val: bal_val - line.cost * line.qty // cost   before_add() } ) }) } } 

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

टिप्पणीकारों ने जो मुख्य समस्या बताई है, वह प्रणाली का प्रदर्शन है, और हमारे पास अपेक्षाकृत प्रासंगिक डेटा पर इसे मापने के लिए सब कुछ है।

स्रोत डेटा पीढ़ी

हमारी प्रणाली में 5,000 प्रतिपक्ष (आपूर्तिकर्ता और ग्राहक), 3,000 वस्तुएं, 50 गोदाम और प्रत्येक प्रकार के 100k दस्तावेज शामिल होंगे - खरीद, स्थानांतरण, बिक्री। दस्तावेज़ अनियमित रूप से उत्पन्न होते हैं, प्रति दस्तावेज़ औसतन 8.5 लाइनें। खरीद और बिक्री लाइनें एक लेन-देन (और एक शेष), और आंदोलन की दो लाइनें उत्पन्न करती हैं, जिसके परिणामस्वरूप 300k प्राथमिक दस्तावेज लगभग 3.4 मिलियन लेनदेन उत्पन्न करते हैं, जो प्रांतीय ईआरपी की मासिक मात्रा के अनुरूप है। हम उसी तरह से उत्परिवर्तित भाग उत्पन्न करते हैं, केवल 10 गुना कम की मात्रा के साथ।

हम एक स्क्रिप्ट के साथ दस्तावेज़ उत्पन्न करते हैं। चलो खरीद के साथ शुरू करते हैं, बाकी दस्तावेजों के दौरान, ट्रिगर वस्तु और गोदाम के चौराहे पर संतुलन की जांच करेगा, और यदि कम से कम एक पंक्ति पास नहीं होती है, तो स्क्रिप्ट एक नया दस्तावेज़ बनाने की कोशिश करेगी। ट्रिगर्स द्वारा स्वचालित रूप से बैलेंस बनाए जाते हैं, विश्लेषकों के संयोजन की अधिकतम संख्या नामांकितों की संख्या के बराबर है * गोदामों की संख्या, अर्थात्। 150k।

DB और कैश आकार

स्क्रिप्ट खत्म होने के बाद, हम निम्नलिखित डेटाबेस मैट्रिक्स देखेंगे:

• अपरिवर्तनीय हिस्सा: 3.7k दस्तावेज़ (300k प्राथमिक, शेष शेष) - फ़ाइल 770 एमबी
• परिवर्तनशील हिस्सा: 370k दस्तावेज़ (30k प्राथमिक, शेष शेष) - फ़ाइल 76 एमबी
• दस्तावेजों का शीर्ष कैश: 158k दस्तावेज़ (संदर्भ + शेष राशि का वर्तमान टुकड़ा) - फ़ाइल 20 एमबी
• दस्तावेज़ कैश: 8.8k दस्तावेज़ (केवल निर्देशिका) - फ़ाइल <1 एमबी

बेंच मार्किंग

आधार का आरम्भ। कैश फ़ाइलों की अनुपस्थिति में, पहली बार में डेटाबेस एक पूर्ण स्कैन लागू करता है:

• अपरिवर्तनीय डेटा फ़ाइल (दस्तावेज़ों के कैश्ड प्रकार के लिए कैश भरना) - 55 सेकंड
• परिवर्तनशील डेटा फ़ाइल (मेमोरी में संपूर्ण डेटा लोड करना और शीर्ष कैश को अपडेट करना) - 6 सेकंड

जब कैश मौजूद होता है, तो आधार को ऊपर उठाना तेज होता है:

• परिवर्तनशील डेटा फ़ाइल - 6 सेकंड
• शीर्ष कैश फ़ाइल - 1.8 सेकंड
• अन्य कैश - 1 सेकंड से कम

पहली कॉल पर कोई भी उपयोगकर्ता कनवल्शन (उदाहरण के लिए, टर्नओवर शीट के निर्माण के लिए स्क्रिप्ट ) को अपरिवर्तनीय फ़ाइल का एक स्कैन लॉन्च करता है, और उत्परिवर्तित डेटा रैम में पहले से ही स्कैन किया जाता है:

• अपरिवर्तनीय डेटा फ़ाइल - 55 सेकंड
• स्मृति में उत्परिवर्ती सरणी - 0.2 सेकंड

बाद की कॉल में, जब इनपुट पैरामीटर मेल खाते हैं, तो कम करें () 0.2 सेकंड में परिणाम लौटाएंगे, जबकि हर बार निम्न कार्य करते हैं:

• कुंजी द्वारा कम कैश से परिणाम निकालना (मापदंडों को ध्यान में रखते हुए)
• मेमोरी में परस्पर सारणी स्कैन करना ( 370k दस्तावेज़)
• फ़िल्टर किए गए दस्तावेज़ ( 20k ) के लिए कनवल्शन एल्गोरिथ्म लागू करके "काउंटिंग" परिणाम

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

तकनीकी अनुकूलन

कोड के प्रदर्शन की जांच करने के बाद, मैंने पाया कि फाइल को पढ़ने और यूनिकोड नाम रखने में लगभग 80% से अधिक समय व्यतीत होता है, जिसका नाम है File.read () और TextDecoder ()। Decode () । इसके अलावा, डेनो में उच्च-स्तरीय फ़ाइल इंटरफ़ेस केवल अतुल्यकालिक है, और जैसा कि मैंने हाल ही में पाया है , मेरे कार्य के लिए async / प्रतीक्षा की कीमत बहुत अधिक है। इसलिए, मुझे अपने खुद के सिंक्रोनस रीडर को लिखना पड़ा, और वास्तव में अनुकूलन के साथ परेशान किए बिना, शुद्ध पढ़ने की गति को 3 गुना बढ़ाने के लिए, या, यदि आप JSON पार्सिंग के साथ गिनती करते हैं - 2 बार से, उसी समय वैश्विक रूप से अतुल्यकालिकता से छुटकारा पा लिया। शायद इस टुकड़े को निम्न-स्तर (या शायद पूरी परियोजना) को फिर से लिखना होगा। डिस्क पर डेटा लिखना भी अस्वीकार्य रूप से धीमा है, हालांकि यह प्रोटोटाइप के लिए कम महत्वपूर्ण है।

आगे के कदम

1. कार्यात्मक शैली में निम्नलिखित ईआरपी एल्गोरिदम के कार्यान्वयन का प्रदर्शन करें:

• आरक्षित प्रबंधन और खुली ज़रूरतें
• आपूर्ति श्रृंखला योजना
• ओवरहेड लागतों को ध्यान में रखते हुए उत्पादन लागतों की गणना

2. बाइनरी स्टोरेज प्रारूप पर स्विच करें, शायद यह फ़ाइल के पढ़ने में तेजी लाएगा। या मानगो में भी सब कुछ डाल दिया।

3. मल्टी-यूजर मोड में फनबैंक ट्रांसफर करें। CQRS सिद्धांत के अनुसार, रीडिंग सीधे सर्वर नोड्स द्वारा की जाती है, जिस पर अपरिवर्तनीय डेटाबेस फ़ाइलों की प्रतिलिपि बनाई जाती है (या नेटवर्क पर अफवाह होती है), और रिकॉर्डिंग एकल REST बिंदु के माध्यम से की जाती है जो उत्परिवर्तित डेटा, कैश और लेनदेन का प्रबंधन करती है।

4. अनुक्रमिक फ़ाइलों के अनुक्रमण के कारण आईडी द्वारा किसी भी अनकैप्ड दस्तावेज़ को प्राप्त करने का त्वरण (जो बेशक एकल-पास एल्गोरिदम की हमारी अवधारणा का उल्लंघन करता है, लेकिन किसी भी संभावना की उपस्थिति हमेशा इसकी अनुपस्थिति से बेहतर है)।

सारांश

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

पूर्ण परियोजना कोड

अगर कोई अपने दम पर खेलना चाहता है:

• डीएनओ स्थापित करें
• भंडार का क्लोन
• अवशेष नियंत्रण के साथ डेटाबेस जनरेशन स्क्रिप्ट चलाएँ (जनरेट
• रूट फ़ोल्डर में झूठ उदाहरण 1..4 की स्क्रिप्ट चलाने
• अपने स्वयं के उदाहरण के साथ आओ, सांकेतिक शब्दों में बदलना, परीक्षण, और मुझे प्रतिक्रिया दें

पुनश्च
कंसोल आउटपुट लिनक्स के लिए डिज़ाइन किया गया है, शायद विंडोज एस्क-सीक्वेंस के तहत सही ढंग से काम नहीं करेगा, लेकिन मेरे पास इसकी जांच करने के लिए कुछ भी नहीं है :)

आपका ध्यान के लिए धन्यवाद।