Привет, Хабр!

Данная статья представляет собой попытку взглянуть на архитектуру старых современных систем учета и планирования на предприятии (назовем их для краткости ERP) с высоты нового опыта. Поводом к написанию послужил маленький тест производительности WEB-приложения, которому удалось агрегировать 10 миллионов фактов за полторы минуты простым перебором. Конечно, для современных СУБД это смешной объем, но я вспомнил, что примерно столько транзакций в месяц генерировала ERP-система торгово-промышленного холдинга, в котором я когда-то работал. Несколько заводов, непрерывное производство, оптовая дистрибуция, сравнительно простая финансовая модель — совершенно типичная компания, типичная учетная система, но отчетность за месяц строилась более 20 минут — на кластере приложений, который работал с кластером SQL, с индексами, статистикой, и хинтами. Годовую же отчетность приходилось ждать до 6 часов, а необходимость пересчитать ее в режиме «what-if» оборачивалась бессонными ночами для бухгалтеров и экономистов. Системы такого класса достаточно сложны и дороги, и проработав более 15 лет в этой отрасли, я продолжаю настаивать — они неоправдано сложны и дороги.

Чтобы пояснить свою мысль, мне придется кратко описать архитектуру типовой западной ERP (что будет сделано разделом ниже), а сейчас представим, что мы взялись проектировать такую систему «с нуля», с учетом требований наших дней, а не 30-летней давности, когда все эти системы создавались. Первое, что необходимо сделать — это описать все входы и выходы нашего «черного ящика», после чего понять, какие внутренние абстракции действительно необходимы, а какие избыточны.
Читать дальше ->

https://habr.com/ru/post/445718/?utm_source=habrahabr&utm_medium=rss&utm_campaign=445718