1. Архитектура развёртывания и масштабирования
Центральная база данных
Изначально предполагается использование единой центральной БД, обслуживающей центральный офис, склады, торговые точки, а также всех сотрудников, работающих с ПО «СуперМаг Плюс» и «СуперМаг Мобайл». Для реализации такой схемы как в программном обеспечении, так и на уровне СУБД предусмотрены все необходимые инструменты, гарантирующие высокую скорость работы и надёжность решения.
Обработка нагрузки от мобильных рабочих мест
Основной объём подключений, по нашим оценкам, будут создавать мобильные рабочие места. Для распределения этой нагрузки в «СуперМаг Плюс» используется специальный компонент — Сервер приложений. Его задача – принимать запросы от мобильных устройств и обеспечивать обмен данными с БД, тем самым исключая прямое множественное обращение к базе со стороны каждого мобильного терминала. Это значительно сокращает число активных подключений, снижает нагрузку на процессор и дисковую подсистему сервера БД.
Горизонтальное масштабирование
Поскольку один Сервер приложений может не справиться с большим количеством мобильных клиентов, предусмотрена возможность горизонтального масштабирования. Формируется иерархическая структура (по типу «дерева»): в корне располагается центральный сервер, к которому подключаются дополнительные экземпляры Сервера приложений (ветви), а уже к каждому из них — определённый пул мобильных рабочих мест. Такая схема легко расширяется по мере роста числа пользователей.
Оптимизация для стационарных рабочих мест
В случае возникновения конкуренции за ресурсы со стороны стационарных рабочих мест, возможно провести углублённую оптимизацию самой БД с использованием штатных средств СУБД и встроенных инструментов «СуперМаг Плюс».
Переход к распределённой схеме
Если аппаратные ресурсы центрального сервера будут исчерпаны и дальнейшее наращивание мощности невозможно, в ПО предусмотрена возможность перехода от централизованной модели к распределённому использованию баз данных. В этом варианте также рекомендуется применять «кустовую» организацию вспомогательных серверов, каждый из которых будет обслуживать стационарные рабочие места, сгруппированные по городам или регионам.
Сервер отчетов
Если центральный сервер перестаёт справляться с потребностями аналитического отдела в получении оперативной отчётности, может быть организован дополнительный выделенный Сервер отчетов. Наполнение этого сервера данными производится автоматически, без участия пользователей, что позволяет разгрузить основную БД и ускорить формирование аналитических выборок.
2. Особенности учёта и расчёта товародвижения
Партионный учёт по методу FIFO
В торговой системе «СуперМаг Плюс» реализован партионный учёт по методу «естественной очереди» – FIFO (First In, First Out). Это означает, что списание товара происходит автоматически, начиная с партий с наиболее ранней датой оприходования.
Гибкость при возврате поставщику
В ряде ситуаций строгий FIFO не полностью отвечает потребностям учёта. Поэтому система позволяет пользователю при возврате товара поставщику отклонить автоматическую привязку к первой незакрытой партии и указать нужную партию вручную – проставить основание со ссылкой на конкретный документ поступления. Такой подход особенно востребован для товаров с ограниченным сроком годности (например, хлебобулочные изделия), поскольку даёт возможность вернуть именно ту партию и по тем ценам, которые ожидает поставщик.
Расчёт товародвижения
В текущей реализации период пересчёта товародвижения для крупных и очень крупных баз данных составляет до 5 часов, что укладывается в ночной простой системы. Если же время расчёта возрастает, а все возможные способы увеличения производительности оборудования и оптимизации СУБД уже исчерпаны, пользователю предлагаются альтернативные решения:
Выделенный сервер отчетов – позволяет перенести часть вычислительной нагрузки на отдельную машину.
Механизм предварительного расчёта «старых» данных – результаты обработки прошлых периодов сохраняются в специальных аналитических таблицах. В расчёт товародвижения тогда вовлекаются только свежие данные (например, за последний год), а все ранее рассчитанные показатели подставляются как готовые.
Период в один год, предлагаемый для хранения «открытым», выбран исходя из того, что в течение этого срока пользователь может вносить исправления при обнаружении критических ошибок в документах. По истечении года период считается закрытым (данные замораживаются). Однако при необходимости это ограничение можно обойти – выполнить функцию «Открытия периода», внести правки и снова закрыть его.