Comments 18
Хм.
Было:
шине данных приходилось последовательно пробегаться по базам данных всех магазинов, агрегировать их и консолидировано выдавать их внешним потребителям этих данных. Магазинов много, и на их последовательно-параллельную обработку уходило порядка 3х часов.
Стало:
Postgres каждые 5 минут забирает из баз данных учетных систем полные данные по остаткам и ценам, кеширует их у себя.
Т.е., процесс, который раньше занимал порядка трех часов, теперь занимает меньше пяти минут?
Как я понял, 3 часа было, когда собирали все подряд.
Когда стали собирать более целево, стало быстрее, но возникли шторма.
Теперь выделенная БД сама забирает регулярно только самое необходимое, т.е. нагрузка осталась, но стала прогнозируемой и однообразной; и ее наверное проще распараллелить; а сложные запросы теперь можно обрабатывать не на стороне учетных систем торговых точек и не на шине, а в отдельном хранилище. Наверное, это на какое-то время решит проблему.
Но основная проблема - это проблема дальнейшего роста. Плохо кончится…
То есть все сводится к тому, что шина данных не имела никакого своего накапливающего хранилища?
Шина данных не должна иметь своей базы ДАННЫХ (не настроек, а именно данных). Или эти данные должны лежать в отдельном физическом хранилище, отделенные от метаданных шины.
В нашей шине данных, к сожалению так исторически сложилось, этот шаблон нарушен. Из-за чего мы имеем огромное количество проблем с ее стабильностью и производительностью.
Главный плюс - это предсказуемость нагрузке. Это регулярный процесс, который запускается в понятное время и дает понятную нагрузку. Дальше можно проект скейлить при необходимости в Greenplum. У нас на нем работает DWH. А для микросервиса использовать Greenplum - это пушкой по воробьям.
Да, статья в стиле как нарисовать сову. Никаких технических подробностей. Как новый сервис забирает данные из нескольких баз 1С? Почему это стало быстрее? Ни-че-го.
Корпоративный блох во всей красе
Программная реализация совершенно не интересная. Поэтому я не стал ее вписывать в статью. Несколько VIEW на стороне источников и джоб на Postgres, который вычитывает их и подменяет партиции в Postgres.
Суть статьи - про вывоз микросервисов из 1С. Это не шаблонная история.
Ну и зря не стали. То, что очевидно для вас (нас) для многих совершенно не очевидно и очень даже интересно. У нас похожая история в нескольких разнородных базах 1С. Тоже некоторый функционал вынесет наружу (за пределы 1С), чтобы его потом агрегировано использовать дальше.
Несколько VIEW на стороне источников и джоб на Postgres, который вычитывает их и подменяет партиции в Postgres.
...и вы при этом говорите, что у вас микросервис? Любопытно.
Раньше все работало на шине данных. Мы не могли ее нагружать постоянным сбором большого объема данных. Поэтому запускали несколько потоков, каждый из которых последовательно обходил полсотни магазинов. Затягивалось все надолго. Больше потоков запустить нельзя - шина данных ляжет от такого объема данных.
В новой архитектуре Postgres сам ходит в источники и берет все нужное.
Всё в кучу. И маркеплейсы и все магазины от Калининграда до Владивостока. Во первых, группа магазинов должна работать с одним региональным складом. На этом уже в десятки раз падает нагрузка на базы. Во вторых товарные остатки магазина и маркеплейсов должны быть разделены как физически по разным складам, так и программно. Далее, не базы магазинов надо опрашивать, а магазины должны отправлять данные. Кроме того, не совсем понятно для чего нужны оперативные данные в моменте всех остатков по всей стране. Неужели, если в Москве закажут товар, то его повезут из Владивостока?
Статья обозначила проблему, жаль решение не расписали. Но чую, что у компании большие проблемы с проектированием программных решений и подходом в управлении товарными запасами.
Кроме того, не совсем понятно для чего нужны оперативные данные в моменте всех остатков по всей стране.
Если открыть любой нормальный интернет магазин с распределенной сетью магазинов/складов по стране, то там отображается количество доступного товара + есть ли в "твоём" городе товар.
Т. ч цель понятна. Цель благая и полезная.
Ну и "магазины должны отправлять" - почему и кому должны? Это лишь одна из многих реализаций архитектурных. Она ни лучше и не хуже иных. А кривость работы, это лишь кривость реализации, но не архитектурного подхода.
Вы правы, что это удобно. Более того, это должно быть. Я упомянул, что для этого не совсем обязательно иметь именно оперативный учёт. Ничего страшного, если покупатель увидит, что на остатке меньше, чем есть или товар отсутствует совсем. Условно, через час информация обновится по магазину в глобальной базе и уже пусть не этот, но другие клиенты смогут узнать информацию о наличии.
Что касается кругового опроса магазинов, то схема когда магазины сами отправляют данные более предпочтительна по причине, что такие данные будут отправлены как только будут готовы. В случае кругового опроса, инициатору надо ждать ответа. А ведь может не дождаться, и хорошо если в таком случае есть многопоточность.
Не понимаю, зачем вы сделали те же яйца только в профиль... Пулить остатки (характеристики, цены) надо с переферийных баз по мере появления изменений, а не забирать централизованно, тогда у вас всегда будут актуальные остатки в одной БД без задержек и без лишних нагрузок. Про регионы и региональные склады сказали выше, чет у вас ребята явно проблема с проектированием.... И видимо в компании с бизнес процессами...
Если данные пушить из магазинов, то это надо обслуживать все джобы во всех магазинов - следить чтобы ничего не подвисло, своевременность выполнения и тп.
Пушить по мере "появления изменений" - это утопия. В каждом магазине до 8 касс, в каждой из которых в пике каждые 2 секунды продается 1 единица товара. Это огромный поток данных. Тогда нам нужна была бы БД, оптимизированная для записи малыми пакетами. Нам же при проектировании требовалась БД, оптимизированная для RPS чтения. Поэтому мы выполняем регулярный забор именно остатков, а не транзакций. И навешивание на это все нужных индексов.
Откуда же эту информацию мы можем выдать? Достоверная оперативная информация о товарных остатках в Рив Гош распределена по разным OLTP системам: часть магазинов в современной централизованной 1С ERP управление холдингом, остальные магазины – в специализированных базах Oracle, распределительные центры – в 1С УПП. Единого оперативного хранилища нет.
Что-то не очень понятно. Если погуглить, то выдает, что у Рив Гош сейчас всего 257 магазинов всего. У нас на lsFusion ERP есть FMCG-сети с большим количеством магазинов. И и все магазины и распределительные центры работают в одной базе на одном сервере PostgreSQL без какой-либо кластеризации. И тоже есть доставка, и тоже есть запросы на остатки и комплектации. И то, там нагрузка больше 50% не поднимается. Зачем столько баз ?
Что вы там с OLTP базой делаете ? Сколько у Вас пользователей одновременно работает на 257 магазинов то ?
Текущие итоги остатков на складах в 1С берутся из одной таблицы SQL (таблица итогов регистра накопления). Почему этот запрос из 1С в вашем случае дольше, чем почти такой же запрос из базы PostgreSQL?
Так же сейчас уже мало кто использует большое количество распределенных баз 1С с консолидацией данных в центральную управленческую базу (ведь при большом количестве баз консолидация будет идти часами). Делают одну центральную базу и к ней подключаются онлайн со всех регионов. Если магазинов очень много, то можно сделать несколько региональных баз и центральную. Все магазины региона работают в своей региональной базе, например в 1С:Розница, а после закрытия смен данные сливаются в центральную ERP.
Вынос товарных остатков из 1С в микросервис