Применение принципов функционального программирования при проектировании ERP

Инвойсы и кредит ноты легко могут прийти и через пол года после продажи партии. :))) Так что это нормально.

Давайте определимся с терминами. Инвойс это денежный приход? Он может не совпадать с количественным по времени? А как в этот промежуток сырье списывать, по какой себестоимости? Кредит-нота сторнирует только сумму, или и количество тоже? Что делаем если товар купили и продали, а в след. месяце пришел инвойс на растаможку и фрахт?

Выполняется ограничение — количество товара в ячейке не должно уходить в минус на конец любого дня

То есть ERP позволят в середине дня отгузить еще не полученное? Не верю. Тогда нужно разделять мухи (движение количества) и котлеты (движение денег) в разные контуры.

Применение принципов функционального программирования при проектировании ERP

Миллион транзакций (строк документов) в месяц для оптовой торговли это уже много, для производства нормально, и только для ритейла ниочем. Граф сопоставлений — это связь многие-ко-многим, то есть сопоставлений вполне может получиться и 10 миллионов. Нужно обнаруживать и отсекать циклы (возвратные отходы в производстве). На последнем моем проекте такой объем Аксапта несколько часов закрывала, хотя с виду смешная задача. Потому что считала по каждой номенклатуре отдельно — граф + прогон коррекций. Как правильно тут говорили — ОРМ + циклы это уже давно моветон, но кто-то еще использует.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Спасибо! Про векторизацию у меня есть только пример на Rust, но там ее нужно ручками заводить, и пока не до этого. Почти уговорили меня перейти на .net )

Применение принципов функционального программирования при проектировании ERP

OK. Как чего-нибудь простое напишу сообщу.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Да, спасибо, собственно создания промисов и хотелось бы избежать. В Deno тоже есть стримы.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Это всего лишь открытие дескриптора

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Stream API NodeJs.

Я на Deno пишу, выглядит так:

const db = new BufReader(Deno.openSync('file.json'))
while(true) {
    const chunk = await db.readString('\x01')
    if (chunk == Deno.EOF) break
    try {
        const doc = JSON.parse(chunk.slice(0,-1))
        try {
           // бизнес-логика

Здесь буферизованный асинхронный стрим. И я недовлен производительностью. А как такое на чистой ноде буде выглядеть, я протестирую для сравнения?

Применение принципов функционального программирования при проектировании ERP

А не кинете ссылку на какой-нибудь мануал с алгоритмом 1С УПП, с ней работать не приходилось, интересно.

Применение принципов функционального программирования при проектировании ERP

Какая метрика, и на какой методике расчета вас интересует? Например, фифо по лотам на миллионе документов — сколько времени оно должно считаться? Функциональщина сама по себе будет считать не медленней, но вопрос в методике — везде где я видел, было принято создавать приходы и дооценки задним числом, в результате при закрытии периода приходилось все массово рассопоставлять и заново сопоставлять. То есть мы можем придумать алгоритм как считать ее быстро и в онлайн, но практика заднего числа может все убить — получим просто толстую блокирующую операцию. Я сейчас простенький пример расчета пишу, чтобы не впустую — давайте согласуем методику.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Спасибо, а что у вас внутри 4-х функций, простое деление, можете дословно код привести? Мне тут указали, что нельзя такое простое бенчить, ибо оно может инлайниться или векторизоваться, и реально деградация еще меньше. Компилятор Rust вообще беспардонен — dead code просто выбрасывает, линейные циклы векторизует и т.д. Тут надо заморочиться чтобы что-то релевантное набенчить, но в целом .NET порадовал, особенно в сравнении с Java, которая уже на синхронном вызове в 2 раза хуже была — похоже, она в SIMD не умеет совсем.

Применение принципов функционального программирования при проектировании ERP

Про графовые — пока не понимаю каким боком их к моей задаче приспособить. Идея все-таки создать иммутабельное хранилище. Сейчас я думаю над написанием 3-х примеров:
1) Правка документа задним числом. Поскольку в данной схеме правка иммутабельных документов — это достаточно редкое (но необходимое) исключение — хранилище должно ее поддерживать. Понятно, что придется перезаписать кусок журнала, обеспечивая вставку, удаление, изменение. Понятно, что это приведет к перемещению горизонта иммуабельности, а значит — пересчету всех агрегатов, то есть операция по сути блокирующая. И надо уменьшить ее цену, например партиционированием хранилища (агрегаты должны вычисляться по каждой партиции, и потом сводиться, но не для всех алгоритмов это возможно в принципе).
2) Расчет себестоимости. Это первый алгоритм, реализацию которого нужно показать. Принципиальных проблем я пока тут не вижу, но они могут появиться в процессе.
3) Распараллеливание. Не очень представляю, как это сделать с учетом сквозных связей. То есть без определения кэшированных объектов ДО расчета параллелизм невозможен, а это уже когнитивная нагрузка на прикладного разработчика, не уверен что в итоге получится легко понимаемый код.
PS
Появится материал — буду выкладывать.

Микросервисы: как соблюсти контракт

-

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Спасибо! С учетом того, что в моем дурацком примере функция заинлайнена, получаем просто затраты на вызов, надо дальше потестить.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Мысль интересная про динамическую типизацию, но не понял что значит родные промисы. В JS промис — это просто объект с двумя колбэками, самая простая реализация из всех возможных. А стек вызовов сохраняется в замыкании — этот механизм был и до промисов, когда мы внутреннюю функцию передаем вовне как колбэк, внешняя функция завершается, а все ее переменные оказываются захваченными. Единственное что приходит на ум — из-за динамической природы JS — рантайм не знает, какие именно внешние переменные нужно захватывать, а какие нет. А в том же расте где память выделяется статически, компилятор захватывает в замыкание только то, что реально используется внутри замыкания, поэтому и оверхед меньше на порядок. Но это только гипотеза, я не погружался в реализацию промисов / тасков.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Тоже вариант.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Сделаю, но чуть позже, сейчас текучка навалилась.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Документы в файле неизменяемые, любой потоковый ридер читает весь файл от начала и до конца с фиксированным буфером, поэтому неважно где хранить. Так работает, насколько я понимаю, спарк со своим map/reduce. Сдвиг нужен если мы хотим распараллелить обработку, режем файл на куски, отдаем в разные треды, и особо обрабатываем места стыка. В пред. статье алгоритм описан и даже работающий код приведен.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Файл один, внутри миллион Json. Синхронный ридер на той же Java в 5 раз быстрее асинхронного в JS, причину не понимаю, исходники не ковырял, возможно мосты EPOLL => сишный (растовый) рантайм => V8 съедают все время.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Можно. Я правда с Deno работаю, но это очень похоже. Есть не только буферизованные стримы, но и seek(). По поводу отображения файла в память — похоже нет такого.

Какую цену мы платим за использование async/await в языках JS / C# / Rust

Да надо бы. Гошка отпугивает отсутствием дженериков и исключений, все время возвращать кортежи это так себе.