Как не танцевать на граблях с бубном делая CRM?

Question

[Хостинг Ярославль]

Хотелось бы уменьшить нагрузку на систему в многопользовательской облачной CRM.

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

Каждый раз приходится суммировать весь приход и расход.

Возникла идея сделать "закрытие месяца", как в 1С, чтобы считать остатки в накопительную таблицу и далее брать из нее и далее делать расчет только за текущий месяц.

В случае проведения документов за старый период налёту пересчитывать остатки только по тем номенклатурам, что в документе, возможно просто добавляя, вычитая количество из текущего документа с накопительной суммой.

1. Даст ли это прирост в скорости, есть ли смысл писать этот программный код или выхлоп будет ничтожным.

2. Не будет ли выборка по таблице со всеми месяцами и номенклатура и более тяжёлой? Или хранить только прошлый месяц, и.к. большинство запросов на текущую дату, а остальные запросы оставлять без "кеширования"?

Comments

[Vitaliy K]

Так вы что, делаете это онлайн на PHP?

Answer 1

[Леонид]

за этот прирост вы заплатите гемором по вычислению остатков и оборотов на произвольную дату. например отчет с чередины прошлого месяца
Полный пересчет никаких проблем не представляет. гораздо дешевле докупть памяти и процесорного времени чем неоправдано усложнять систему. Одноце как раз и тормозит безбожно изза своей архитектуры.
В моей учетной системе например все пересчитывается и остатки по складам и по денежным счетам и никаких проблем нет.

Answer 2

[ThunderCat]

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

1) Это ваше предположение или вы делали замеры производительности запросов и кода?
2) Если производительность действительно проседает, то каким образом у вас происходит вычисление? SQL с агрегацией и каунтом?
3) Сколько строк в таблицах выборки?
4) Что показывает explain?
5) Индексы?

Если оптимизировать по выборкам не получается и все упирается в запрос, то можно конечно выводить суммы помесячно, а затем делать агрегацию по суммам + довыборку из неполных месяцев, но тут есть свои нюансы, помимо очевидного усложнения кода и денормализации, как минимум не всегда все обороты намертво приколочены к концу месяца и могут меняться задним числом, что тоже надо будет учитывать и пересчитывать итоги при внесении таких правок.

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

Comments

[Хостинг Ярославль]

1. 2. Остатки считаются партионно циклом по каждой номенклатуре. Способ проще пока не удалось найти. Т.е. если в магазине 100 видов товаров, то будет 100 запров к таблице продаж и 100 к таблице закупок.

Ну и если остальные страницы генерятся делая 10 запросов, не сложно предположить, что 200 запросов - узкое место. Замеров пока не делал, т.к. что тут что-то не так с кодом очевидно, но упростить его пока не получилось.

3. Пока работает в тестовом режиме, поэтому не могу предсказать реальные нагрузки после начала продаж. Поэтому и хочу на этом этапе архитектуру сделать нормальную.
5. Индексы есть.

Пересчет планировался делать не сложением остатков по каждому месяцу, а просто взять остаток на последний рассчитанный месяц (накопительный с начала времён) и добавить за текущий не полный. Большинство запросов на текущую дату. Ну а если попадется запрос на старую дату, то пустить по текущему коду.

[ThunderCat]

1. 2. Остатки считаются партионно циклом по каждой номенклатуре. Способ проще пока не удалось найти. Т.е. если в магазине 100 видов товаров, то будет 100 запров к таблице продаж и 100 к таблице закупок.

В принципе, на этом можно закрывать вопрос.

Способ проще: Читать доки мускуля и SQL в целом, научиться делать join, group by, count, ну или заплатить нормальному специалисту за 1-2 запроса, чтобы сделали нормально, если сами не сможете.

На будущее - если у вас запросы в цикле - 99% что вы делаете плохой код. Единственный вариант когда это приемлемо - внесение больших массивов данных, но никак не чтение!

Answer 3

[d-stream]

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

Во-первых зачем это в crm? Во-вторых - зачем это каждый раз на заданную дату, а не на текущий момент?

Comments

[Хостинг Ярославль]

Это есть, это нужно, этим пользуются и сформировалась сначала потребность а затем код.

Большинство пользуется на текущий момент или на момент последней отгрузки.

[d-stream]

Это есть, это нужно, этим пользуются и сформировалась сначала потребность а затем код.

Это не ответ. Точнее ответ в стиле "вместите мне на визитке фио, должности и регалии в одну строку 24 кеглем")

"на текущий момент" совершенно спокойно строится на хэлперах в виде партия-остаток

[Хостинг Ярославль]

d-stream,
Было ТЗ о необходимости видеть остатки в разрезе по номенклатуре от многих пользователей.
И функции складского учёта добавились в текущую CRM

[d-stream]

Было ТЗ

Если это техническое задание, а не точка зрения - то там должно было быть описано где, когда и как это надо видеть. Полагаю что речь об отчете. Который имеет полное право формироваться не миллисекунды, а например единицы-десятки секунд... а потом рендер 100500 страничного отчета будет ползти по медненным каналам минуты, печататься - десятки минут, изучаться - примерно никогда) А вот для выбора к примеру для корзины/заказа - актуально то что прямо здесь и сейчас еще есть в наличии и сколько его еще осталось.