Увы в данный момент реальных данных у меня нету так что я не могу сказать по поводу рапределения колличества ключей. Да конечно оптимайз хороший но для начала интересно реально ли решить в общем случае.
Получается струткра размером ~ 10 млн на 250к. А это слишком много даже для одного прохода.
+Ловим проблему с тем что после получения результатов (700к сайтов) с ними нужно строить таблицы.
В прочем я думаю это можно решить записав результат во временную mysql таблицу-кеш. И делать сортировки уже по ней. Потом её удалять.
Но это проход по 2.5 миллиардов элементов + выгрузка 700к в базу. Мне кажется что даже деля на 10 серверов мы не успеем это обработать за минуту.
(когдя я писал олимпиады на паскале цикл из 1-5млн элементов обрабатывался за секунду. Не думаю что с тех пор производительность систем изменилась на несколько порядков)
Максимально до 500к (хотелось бы чтобы максимальный вариант хорошо отрабатывал а не средний.)
Пересечений там много. И сайтов самих тоже много.
>Либо попробовать сделать обратный индекс с сортировпнными сайтами, за один проход вычислять пересечение по сайту, все сайты раскидать по нодам, результат скидывать в БД для сортировки.
Поясните этот вариант.
Я думал о том чтобы вычислить один раз процент конкурентности для каждой пары сайтов. Но это таблица 60м х 60м записей
Сергей Протько: Текущий код написан как обычный сервис принимающий параметры в метод.
Его можно переписать на вышеописанную фабрику когда параметры пойдут в конструктор нового объекта (Именно этот вариант описан в конце исходного вопроса.).
Вопрос в том стоит ли это делать в этом конкретном случае а также когда это имеет смысл в общем случае.
Сергей Протько: Перефразирую мой основной вопрос:
Когда имеет смысл использовать конструктор объектов напямую или через фабруику вместо использования DI?
т. е создавать каждый раз новый объект с новыми параметрами вместо использования одного экземпляра сервиса и передачи ему этих параметров через метод.
Сергей Протько: 1. Сразу после insert мне нужно провести некую работу надо этими транзакциями. Хотя возможно я смогу обойтись обьектами в памяти не делая по ним выборки в бд. Но в общем случае я бы хотел сохранять элементы после каждого вызова метода.
2. Да идея хорошая если вынести insert из merge.Так как не хочу инжектить в коллекцию репозиторий.
3. Возможно. но это добавить ещё одну зависимость в SourceObject (//$sourceParams = $this->container->get('wt.extractor_params')->extract($sourceParams);)
4. Ок. будет репозиторием.
loadTransactions не связан с бд. Он получает данные из внешнего api.
>Это нарушает принципы инверсии зависимостей
Да, я понимаю. Выразился не корректно.
В моей терминологии сервисы от обычных классов отличаются тем что все параметры сервиса жёстко прописаны в конфиге и не меняются во время исполнения. В то время как "обычный класс" можно создать с динамическими параметрами в конструкторе. (например из бд)
Сам задумался об этом направлении только после того как написал.
Если ничего более специализированного не найду остановлюсь на нём.
За procmail спасибо.
Как можно подтвердить что проблема именно на физическом уровне а не в настройках ос чтобы можно было составить запрос в саппорт?