Спасибо за предыдущие рекомендации, немного кокретики.
Консьюмер получает сообщение в котором находится 100 пар артикул+бренд, уникальных. Эти артикулы летят в КХ и извлекают ценовые предложения по данным парам артикул, бренд, кол-во, цена и данных много так как одна деталь каждый день может быть с разной ценой или кол-вом.
Консьюмер логирует в файл то что делает вот лог
[11/03/2024 15:23:48] [DEBUG] generate part report start, hash 000125dadae7fa7b2d1273bd3a1751bf [Context [] Extra []]
[11/03/2024 15:24:25] [DEBUG] execute success, 1 time: 37.32 [Context [] Extra []]
[11/03/2024 15:24:26] [DEBUG] calculatePart finish, hash 000125dadae7fa7b2d1273bd3a1751bf mem: 19.00 MB [Context [] Extra []]
[11/03/2024 15:24:26] [DEBUG] save results finish, hash 000125dadae7fa7b2d1273bd3a1751bf mem: 19.35 MB [Context [] Extra []]
[11/03/2024 15:24:26] [DEBUG] generate part report finish, time: 0.01 hash 000125dadae7fa7b2d1273bd3a1751bf mem: 19.33 MB [Context [] Extra []]
Запросы такого плана
SELECT * FROM partscanner_sheet_raw_log WHERE event_date >= '2023-12-01' AND event_date <= '2024-02-24' AND sheet_id IN (15,17,18,19,20,21,22,23,24,25,26,.........,255,256,257,258,259,260,261,262,263) AND type = 'info' AND upperUTF8(key) IN ('MAZ_54321310400601','..........'MAZ_54322704125','MAZ_54322801080') ORDER BY event_time ASC LIMIT 0,10000000
Кстати сейчас заглянул в лог, вижу ошибки такого плана
In StreamIO.php line 268:
fwrite(): Send of 21 bytes failed with errno=104 Connection reset by peer
Может действительно раббит барахлит, StreamIO.php - класс раббита php
1. Date datetime data object_id
2. Data - string с json данными это лог который хранится
3. 365 дней
4. Да
5. Сложно сказать
6. В данном случае это и есть архив
1. смотрите если забить туда 5 млн статей и вывести в публичной части, например последние 10 статей, то проблем не будет
2. если работать с ним в админке то могут быть проблемы
3. много зависит от сервера если настроен соответсвующе то потянет и джумлу с 5млн
Я бы пересмотрел арх.решение для задачи потому что не совсем верно менять дто под разные репозитории, вот почему:
1. Репозиторий это реализация работы с хранилищем для доменной модели, в идеале вы должны откинуть всю инфраструктуру и реализовать поставленную задачу. Например активация пользователя: действие активировать, объект пользователь. Реализуете поведение используя ArrayRepository для теста например.
2. Далее подключаете инфраструктуру и реализуете уже работу репозитория с внешним хранилищем , поведение при этом не должно меняться.
3. Возможно вам нужно использовать TariffActivationDtoInterface вместо UserActivationDto
тогда public function tariffActivation(TariffActivationDtoInterface $dto): TariffActivationResponse2Dto
то есть поведение будет соблюдено + $dto может иметь свой функционал
Михаил, если вы имеете ввиду транзакционность как возможность отката цепочки процессов, то соглашусь с этим, но это отличается от транзакций на уровне субд.
Транзакционность как правило это задача сервисного слоя.
может промокод существовать отдельно от заказа?, могут ли в заказе быть позиции заказа, могут позиции существовать отдельно от заказа наверно если не могут то 100% агрегат
товары - скорее всего товар может существовать отдельно от заказа, может ли товар быть без раздела наверно нет, может ли раздел бы без каталога, тоже наверно нет. эти вопросы нужно задавать при проектировании в первую очередь.
в приведенном примере можно выделить два контекста: Заказ и Каталог
в контексте заказа существует Агрегаты: Заказ, наверно могут быть также Покупатель, Доставка, Оплата как отдельные агрегаты так как доставка может быть без заказа
в агрегатах связи с другими агрегатами могут быть по uuid
например в заказе есть связь с покупателем order->shopperId = 1; а может быть объект order->shopper->getName()
у покупателя связь с заказами может быть Shopper->orders = [123,123]
позиция заказа может иметь связь с товаром OrderPosition->productId = 123;
из последних интегрировал с битрикс24 и с мойсклад
все очень просто, не думаю что сложно реализовать на любом другом движке, делал кстати для аналогичного сайта клиенты,поставщики,продажи,опт
тут вопрос как сделать и не сломать последующие обновления CMS
Консьюмер получает сообщение в котором находится 100 пар артикул+бренд, уникальных. Эти артикулы летят в КХ и извлекают ценовые предложения по данным парам артикул, бренд, кол-во, цена и данных много так как одна деталь каждый день может быть с разной ценой или кол-вом.
Консьюмер логирует в файл то что делает вот лог
[11/03/2024 15:23:48] [DEBUG] generate part report start, hash 000125dadae7fa7b2d1273bd3a1751bf [Context [] Extra []]
[11/03/2024 15:24:25] [DEBUG] execute success, 1 time: 37.32 [Context [] Extra []]
[11/03/2024 15:24:26] [DEBUG] calculatePart finish, hash 000125dadae7fa7b2d1273bd3a1751bf mem: 19.00 MB [Context [] Extra []]
[11/03/2024 15:24:26] [DEBUG] save results finish, hash 000125dadae7fa7b2d1273bd3a1751bf mem: 19.35 MB [Context [] Extra []]
[11/03/2024 15:24:26] [DEBUG] generate part report finish, time: 0.01 hash 000125dadae7fa7b2d1273bd3a1751bf mem: 19.33 MB [Context [] Extra []]
Запросы такого плана
SELECT * FROM partscanner_sheet_raw_log WHERE event_date >= '2023-12-01' AND event_date <= '2024-02-24' AND sheet_id IN (15,17,18,19,20,21,22,23,24,25,26,.........,255,256,257,258,259,260,261,262,263) AND type = 'info' AND upperUTF8(key) IN ('MAZ_54321310400601','..........'MAZ_54322704125','MAZ_54322801080') ORDER BY event_time ASC LIMIT 0,10000000
Кстати сейчас заглянул в лог, вижу ошибки такого плана
In StreamIO.php line 268:
fwrite(): Send of 21 bytes failed with errno=104 Connection reset by peer
Может действительно раббит барахлит, StreamIO.php - класс раббита php