d-stream: Эта баржа первоначально в пустую таблицу только записывается секунд 15 (если идти по пути truncate затем insert).
Потом ее нужно получить обратно вместе с оригинальным списком.
Да, мы выигрываем по памяти, но конкретно проигрываем по времени выполнения.
Я уже так пробовал.
Еще раз повторюсь, данная задача выполняется через воркер с сотней подобных таблиц.
То есть это не единоразовый цикл. Берет одну таблицу с удаленного, сравнивает, записывает разницу. Берет следующую и так далее.
Сейчас время выполнения максимально-оптимальное и все таблицы (не все они 5 миллионов, какие то поменьше, где то 800к, где то 1М) успевает пройти в среднем за 20-30 минут, как раз до необходимого дедлайна по актуальной выдаче, но память...текёт...текёт...
d-stream: Truncate чего? Текущей таблицы?! Чтобы ее еще раз записать заново?)
Такое было в «бета» решении, тогда мускул загибает намертво. Пишется только разница.
Старые DELETE, новые INSERT.
Александр Аксентьев: Два поля в таблице id -> autoincrement и data -> integer.
И от удаленного тоже самое, только id в них постоянно меняется местами. Все.
Я даже не знаю что тут можно показать.
Про разбить я уже ответил, не вижу возможности (по крайне мере я) взять часть из БД и часть из удаленного, тк я не знаю, под каким ключом будет в следующий раз id из взятого куска БД.
«В базе скажем под id1 => 12345, а этот же 12345 в пришедшем может быть с ключом id5940»
Я понял про разделение, но как раз таки не знаю, как это провернуть из за того, что приходящие данные уже находятся в готовом массиве. Их все равно нужно декодить за один проход.
Александр Аксентьев: Ну с запросами проблем нет, потому что селект происходит только один, когда забирается из базы в массив все 5 лимонов)
Обратно запись также. Собирается массив diff и записывается через prepare mysqli единоразово. А вот с памятью беда.
Сергей: Именно так. Отсюда и вопрос, есть ли какая то фича, чтобы определять объект в конструкторе а не где то в сторонней функции, обойдя бесконечный луп. Именно как в примере. Без синглетона и тд. Что то типа проверки существования экземепляра класса аля method_exists.
Юрий: Ну я на боевом серваке тестил один проход 0.1 секунды. Если быстрее пишет "Too much responses per second" или как то так. В итоге в три запроса, получение 20к пользователей занимает в среднем 6 секунд.
Потом ее нужно получить обратно вместе с оригинальным списком.
Да, мы выигрываем по памяти, но конкретно проигрываем по времени выполнения.
Я уже так пробовал.
Еще раз повторюсь, данная задача выполняется через воркер с сотней подобных таблиц.
То есть это не единоразовый цикл. Берет одну таблицу с удаленного, сравнивает, записывает разницу. Берет следующую и так далее.
Сейчас время выполнения максимально-оптимальное и все таблицы (не все они 5 миллионов, какие то поменьше, где то 800к, где то 1М) успевает пройти в среднем за 20-30 минут, как раз до необходимого дедлайна по актуальной выдаче, но память...текёт...текёт...