Penerapan prinsip-prinsip pemrograman fungsional dalam desain ERP

Halo, Habr!

Pada artikel ini kita akan mencoba melihat arsitektur sistem akuntansi (ERP, CRM, WMS, MES, B2B, ...) dari perspektif pemrograman fungsional. Sistem yang ada sangat kompleks. Mereka didasarkan pada skema data relasional, dan memiliki keadaan sangat besar yang bisa berubah dalam bentuk ratusan tabel terkait. Selain itu, satu-satunya "sumber kebenaran" dalam sistem semacam itu adalah jurnal dokumen primer yang dipesan secara kronologis (cetakan peristiwa dunia nyata), yang, jelas, tidak dapat diubah (dan aturan ini diamati dalam sistem yang diaudit di mana koreksi backdating dilarang). Jurnal dokumen membentuk 20% dari volume basis data secara paksa, dan yang lainnya adalah abstraksi menengah dan agregat, yang nyaman untuk bekerja dengan dalam bahasa SQL, tetapi yang membutuhkan sinkronisasi konstan dengan dokumen dan satu sama lain.

Jika kita kembali ke sumber (menghilangkan redundansi data dan menolak untuk menyimpan agregat), dan mengimplementasikan semua algoritma bisnis dalam bentuk fungsi yang diterapkan langsung ke aliran dokumen utama, kita akan mendapatkan DBMS fungsional dan ERP fungsional yang dibangun di atasnya. Masalah kinerja diselesaikan berkat memoisasi , dan jumlah kode fungsional akan cukup sepadan dengan jumlah SQL deklaratif, dan tidak lebih sulit untuk dipahami. Pada artikel ini, kami akan menunjukkan pendekatan dengan mengembangkan file DBMS paling sederhana dalam TypeScript dan Deno runtime (analog Node.js), serta menguji kinerja konvolusi menggunakan tugas-tugas bisnis yang khas sebagai contoh.

Mengapa ini relevan?

1) Keadaan + redundansi data yang dapat berubah buruk, terutama bila perlu untuk memastikan sinkronisasi yang konstan dengan aliran dokumen. Ini adalah sumber perbedaan potensial kredensial (keseimbangan tidak menyatu) dan sulit untuk mendeteksi efek samping.

2) Skema relasional yang kaku untuk menyimpan sumber dan data antara mahal di Big Data, sistem heterogen, dan dalam kondisi perubahan yang cepat - yaitu, bahkan di mana-mana. Kami menyarankan untuk menyimpan dokumen dalam bentuk aslinya, disortir berdasarkan waktu, memungkinkan koneksi "dari yang baru ke yang lama" dan tidak pernah sebaliknya. Ini akan memungkinkan sebagian besar agregat dihitung dengan algoritma single-pass langsung dari dokumen, dan semua tabel lainnya tidak diperlukan .

3) SQL sudah usang, karena mengasumsikan ketersediaan data setiap saat, dan dalam sistem terdistribusi ini jelas tidak terjadi - ketika mengembangkan algoritma Big Data, Anda harus siap untuk beberapa data yang diperlukan untuk muncul kemudian, dan beberapa sudah muncul sebelumnya. Ini membutuhkan sedikit pemikiran ulang dari bahasa query, dan perhatian yang sadar untuk caching.

4) PL modern memungkinkan Anda untuk membuat sistem responsif yang beroperasi dengan jutaan catatan secara lokal di laptop, di mana RDBMS tidak diinstal. Dan jika kita berbicara tentang server - skema yang diusulkan memiliki lebih banyak kemungkinan untuk paralelisme, termasuk pada kluster SPARK.

Latar belakang

Setelah bekerja cukup lama dengan berbagai perangkat lunak bisnis (akunting, perencanaan, WMS), saya menghadapi dua masalah hampir di mana-mana: kesulitan membuat perubahan pada skema data, dan seringnya penurunan produktivitas ketika perubahan ini dilakukan. Secara umum, sistem ini memiliki struktur yang kompleks, karena persyaratan yang saling bertentangan dikenakan pada mereka:

1) Auditabilitas. Penting untuk menyimpan semua dokumen utama tidak berubah. Pembagian menjadi direktori dan operasi sangat kondisional, dalam sistem dewasa, direktori terbatas pada versi, di mana setiap perubahan dilakukan oleh dokumen khusus. Dengan demikian, dokumen sumber adalah bagian yang tidak dapat diubah dari sistem, dan itu adalah satu-satunya "sumber kebenaran", dan semua data lainnya dapat dipulihkan darinya.

2) Kinerja permintaan. Misalnya, ketika membuat jalur pesanan penjualan, sistem harus menghitung harga produk, dengan mempertimbangkan diskon akun, untuk itu perlu mengekstraksi status klien, saldo saat ini, riwayat pembelian, saham saat ini di wilayah tersebut, dll. Secara alami, semua informasi yang diperlukan tidak dapat dihitung "on the fly", tetapi harus tersedia dalam bentuk setengah jadi. Oleh karena itu, sistem yang ada menyimpan abstraksi yang nyaman di atas baris dokumen (posting), serta agregat yang telah dihitung sebelumnya (register akumulasi, irisan waktu, saldo saat ini, posting ringkasan, dll.). Volume mereka hingga 80% dari ukuran basis data, struktur tabel kaku diperbaiki, dengan perubahan apa pun pada algoritme - pemrogram harus menangani pembaruan agregat yang benar. Bahkan, agregat ini adalah keadaan yang bisa berubah dari sistem.

3) Kinerja transaksional. Saat memegang dokumen apa pun, Anda harus menghitung ulang semua agregat, dan ini biasanya operasi pemblokiran. Oleh karena itu, algoritma pembaruan agregat adalah titik paling menyakitkan dalam sistem, dan ketika sejumlah besar perubahan dilakukan, ada risiko signifikan terhadap sesuatu yang melanggar, dan kemudian data akan "terkorosi", yaitu, agregat tidak akan lagi sesuai dengan dokumen. Situasi ini menjadi momok bagi semua proyek implementasi dan dukungan selanjutnya.

Kami menetapkan dasar-dasar arsitektur baru

1) Penyimpanan. Basisdata adalah jurnal dokumen yang disusun secara kronologis yang mencerminkan fait accompli dari dunia nyata. Direktori juga dokumen, hanya kerja jangka panjang. Baik dokumen dan setiap versi dari entri direktori tidak dapat diubah. Tidak ada data lain dalam bentuk postingan / register / saldo yang disimpan dalam sistem (pernyataan provokatif yang kuat, itu terjadi secara berbeda dalam kehidupan, tetapi Anda perlu berusaha untuk kesempurnaan ). Dokumen memiliki sejumlah atribut sistem:

{
    "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