ईआरपी के डिजाइन में कार्यात्मक प्रोग्रामिंग के सिद्धांतों का अनुप्रयोग

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

इस लेख में हम कार्यात्मक प्रोग्रामिंग के परिप्रेक्ष्य से लेखा प्रणालियों (ईआरपी, सीआरएम, डब्ल्यूएमएस, एमईएस, बी 2 बी ...) की वास्तुकला को देखने की कोशिश करेंगे। मौजूदा सिस्टम जटिल हैं। वे एक संबंधपरक डेटा स्कीमा पर आधारित हैं, और सैकड़ों संबंधित तालिकाओं के रूप में एक विशाल उत्परिवर्तनीय स्थिति है। इसके अलावा, इस तरह की प्रणालियों में एकमात्र "सत्य का स्रोत" प्राथमिक दस्तावेजों (वास्तविक दुनिया की घटनाओं के प्रिंट) का एक कालानुक्रमिक रूप से आदेशित पत्रिका है, जिसे जाहिर है, अपरिवर्तनीय होना चाहिए (और यह नियम ऑडिट किए गए सिस्टम में मनाया जाता है जहां बैकडैम सुधार निषिद्ध हैं)। दस्तावेज़ पत्रिका बल द्वारा डेटाबेस वॉल्यूम का 20% बनाता है, और बाकी सब कुछ मध्यवर्ती सार और समुच्चय हैं, जो एसक्यूएल के साथ काम करने के लिए सुविधाजनक हैं, लेकिन जिन्हें दस्तावेजों के साथ और एक दूसरे के साथ लगातार सिंक्रनाइज़ेशन की आवश्यकता होती है।

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

यह प्रासंगिक क्यों है

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

2) सोर्सिंग और इंटरमीडिएट डेटा के भंडारण के लिए एक कठोर संबंधपरक योजना बिग डेटा, विषम प्रणालियों और तेजी से बदलाव की स्थितियों में महंगी है - जो कि, वास्तव में हर जगह है। हम उनके मूल रूप में दस्तावेजों को संग्रहीत करने का सुझाव देते हैं, समय के अनुसार क्रमबद्ध, "नए से पुराने" कनेक्शन की अनुमति देते हैं और इसके विपरीत कभी नहीं। यह आपको दस्तावेजों से सीधे एकल-पास एल्गोरिदम के साथ अधिकांश इकाइयों की गणना करने की अनुमति देगा, और अन्य सभी तालिकाओं की आवश्यकता नहीं है ।

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

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

पृष्ठभूमि

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

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

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

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

हम नई वास्तुकला की मूल बातें स्थापित करते हैं

1) भंडारण। डेटाबेस का आधार एक कालानुक्रमिक रूप से ऑर्डर किए गए दस्तावेजों की पत्रिका है जो वास्तविक दुनिया के दोष सिद्धि को दर्शाती है। निर्देशिकाएँ भी दस्तावेज़ हैं, बस लंबे समय से अभिनय। दस्तावेज़ और निर्देशिका प्रविष्टि के प्रत्येक संस्करण अपरिवर्तनीय हैं। लेनदेन / रजिस्टरों / शेष के रूप में कोई अन्य डेटा सिस्टम में संग्रहीत नहीं किया जाता है (एक मजबूत उत्तेजक बयान, यह जीवन में अलग तरह से होता है, लेकिन आपको पूर्णता के लिए प्रयास करने की आवश्यकता है )। दस्तावेज़ में कई सिस्टम विशेषताएँ हैं:

{
    "sys": {
        "code": "partner.1",  // - ,  
        "ts": 1578263624612,  //   
        "id": "partner.1^1578263624612",  //    ID
        "cache": 1  //    
    },
    ...
}

code ts , , — . cache, -, -, id, code.

, . () — , ts. , - , ( , , ).

2) . id. «sql foreign key» — , , , , id . . , , ( — , ).

3) . , (.. ) , , 2 — . , , . — , . . — , 1, . , - — , .

4) . — , , , — . - — filter(), reduce(), get(), gettop(), . JOIN, , , , . , , , id / code, , ( ).

5) , . :

• cache, reduce() -, -;
• id / code, ;
• reduce() , , .

, - «» , , , . , , , filter() , reduce() — . .

6) 3- . — . , reduce() , — . — , (.. ). -, . fullscan . — , - , .

7) . -. — - , ( ), — .

, - . TypeScript , Deno — TypeScript WASM, Rust API, ( ).
2- , JSON, "\x01", . API 3- :

type Document = any
type Result = any

public async get(id: string): Promise<Document | undefined>

public async gettop(code: string): Promise<Document | undefined>

public async reduce(
    filter: (result: Result, doc: Document) => Promise<boolean>, 
    reducer: (result: Result, doc: Document) => Promise<void>,
    result: Result
): Promise<Result>

id, code, , , . filter().reduce(), , — , — . reduce() , .

, filter reducer, - . , , get() reduce(). ( ) (. ).

. , . , — , .

{
    "sys": {
        "code": "partner.1",
        "ts": 1578263624612,
        "id": "partner.1^1578263624612",
        "cache": 1     
    },
    "type": "partner.retail",
    "name": "   "
}
{
    "sys": {
        "code": "invent.1",
        "ts": 1578263624612,
        "id": "invent.1^1578263624612",
        "cache": 1     
    },
    "type": "invent.material",
    "name": "  20"
}

type — , , . code — .

{
    "sys": {
        "code": "purch.1",
        "ts": 1578263624613,
        "id": "purch.1^1578263624613"  
    },
    "type": "purch",
    "date": "2020-01-07",
    "partner": "partner.3^1578263624612",
    "lines": [
        {
            "invent": "invent.0^1578263624612",
            "qty": 2,
            "price": 232.62838134273366
        },
        {
            "invent": "invent.1^1578263624917",
            "qty": 24,
            "price": 174.0459600393788
        }
    ]
}

(purch | sale), c ( ).

, , .

import { FuncDB } from './FuncDB.ts'
const db = FuncDB.open('./sample_database/')

let res = await db.reduce(
    async (_, doc) => doc.type == 'sale',  //   
    async (result, doc) => {
        result.doccou++
        doc.lines.forEach(line => {  //    
            result.linecou++
            result.amount += line.price * line.qty
        })
    },
    {amount: 0, doccou: 0, linecou: 0}  //  
)

console.log(`
    amount total = ${res.amount}
    amount per document = ${res.amount / res.doccou}
    lines per document = ${res.linecou / res.doccou}`
)

, Map.

class ResultRow { //   
    invent_name = ''
    partner_name = ''
    debit_qty = 0
    debit_amount = 0
    credit_qty = 0
    credit_amount = 0
}

let res = await db.reduce(
    async (_, doc) => doc.type == 'purch' || doc.type == 'sale',
    async (result, doc) => {
        //      await -   
        const promises = doc.lines.map(async (line) => {
            const key = line.invent + doc.partner
            let row = result.get(key)
            if (row === undefined) {
                row = new ResultRow()
                //      ( )
                row.invent_name = (await db.get(line.invent))?.name ?? ' not found'
                row.partner_name = (await db.get(doc.partner))?.name ?? ' not found'
                result.set(key, row)
            }
            if (doc.type == 'purch') {
                row.debit_qty += line.qty
                row.debit_amount += line.qty * line.price
            } else if (doc.type == 'sale') {
                row.credit_qty += line.qty
                row.credit_amount += line.qty * line.price
            }
        })
        await Promise.all(promises)
    },
    new Map<string, ResultRow>() //   ()
)

, . , , . , — — fullscan, .

:
  : 100 + 100 + 100 .
  : 10 + 10 + 10 .
Intel Celeron CPU N2830 @ 2.16 GHz

— , , . , 10 .


, . , :
 8.8s — JSON, "\x01"
 1.9s — JSON
 0.4s — +
Deno, , unicode, V8 - . , WASM/Rust , , JSON , — . .

- , . 3 , , , , , fullscan. , :


- , 2 , — 2.6s. , , , .

, , , — . , (-, EDI, - ), .



UPD
1) , VolCh .
2) CouchDB, apapacy .

PS