То-то и оно, что пагинируют как? Навскидку условие "пользователь проявлял активность недавно" как раз весьма селективно относительно множества всех пользователей.
Обрати внимание: к множеству активных пользователей есть ещё фильтры. В частности (неверно написанный) inner join к shipping. И по этому условию возможно будет обрезано неопределённое число пользователей. Как это пагинировать?
Ситуацию, впрочем, чуть улучшает явная сортировка по независимому критерию. Так что вторую страницу можно сделать нормально передав последний id с прошлой страницы. Но всё равно: мы не можем затребовать topN записей и приклеить к ним недостающие данные со второй базы. Потому что там есть свои фильтры и вместо N рискуем получить вплоть до 0 в результате.
Кстати, проблему никак не облегчает и то, когда это разные таблицы в одной базе. Всё тот же напрасный перебор в join filter. Накопали пользователей на страницу быстро - повезло. А можно и миллионы строк перебрать в поисках тех 10 нужных. Пересечение больших множеств так просто не считается.
LIME пишет:
Вакуум не устанет?
Найдёшь его в mysql? Хинт: нет его.
LIME пишет:
Я вот думаю как себя будет таблица юзеров чувствовать если на каждый запрос новая версия mvcc?
Ну а касательно postgresql - на каждый запрос всегда прокручиваются колёса mvcc машинерии. Даже index only scan - лишь возможность пропустить проверку видимости, если visibility map сказал что можно. А в пределе это может быть неотличимо от index scan. Проверяем, видна ли эа эта версия строки текущей транзакции. А перебираем строки те же самые, из прошлого, будущего (относительно этой транзакции), редкие из настоящего. Потому и вопрос - какова сущность данных в activity? append only лог и постоянный update неких счётчиков будут вести себя весьма различно.
Для innodb логика mvcc тоже прокручивается, но со своими тараканами. В листьях primary key всегда самая последняя версия строки, даже если не закоммичена ещё. Читатели в поисках видимой им версии лезут в журнал записи и достают оттуда предыдущие версии строки если им надо.
LIME пишет:
я только одно могу придумать
сортировать таблицу юзеров по последней активности
Не сортировать, а фильтровать. Нормальная бизнесхотелка вывести каких-то пользователей, исключая неактивных.
Реалтайм для этого не нужен, да. Но это вопрос именно разработки подойти и спросить у бизнеса: "какая задержка будет не важной для попадания пользователя в этот список? 15 минут ок?"
Или ещё как поизвращаться. Но чтобы извращаться - надо знать свои данные.
А для бизнеса задача как раз вполне осмысленно выглядит.
Вот как дба у меня и нет желания думать в этой теме.
Ок, activity выкинули куда-то. Дальше что? where U.id in (100 тысяч чисел на несколько мегабайт размером запрос)? Хрень это будет, а не оптимизация. Изобретать inner join на приложении и сделать 100 тысяч походов в редис чтобы отсечь некоторое количество из них? Опять хрень получилась.
А какое реальное распределение данных? Что такое activity? append-only лог или постоянный update одних и тех же счётчиков?
Ну и в принципе для 404 не предполагается Location.
Для 301/302 в rfc написано: см. заголовок Location
Для 404 это один из множества заголовков ответа. Ничего с ним делать не предписано, зато предписано что клиент не должен реагировать на дополнительные заголовки, которые клиент не считает неободимыми.
The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless the 201 or a 3xx status code has already been set.
code присутствует т.к. он присутствует в классе Exception выше в иерархии наследования, а конструктор предполагается единственным способом задания этого параметра.
Можете использовать как пожелаете или игнорировать его.
severity добавлен непосредственно в ErrorException и предполагается что будет использован для передачи E_* констант. Его некорректно называть кодом ошибки, это уровень предупреждения. Поэтому это две разные штуки. severity уровень пойманного ErrorException можете получить методом getSeverity
Вы очевидно никак не готовы для этой работы.
Если в качестве тестового задания дают написание скрипта PHP, хоть и такого элементарного - значит от вас ожидают хотя бы такие базовые навыки по этому языку.
Даниил7389 пишет:
просто мои знания в PHP 4 дня
Для меня это звучит не оправданием, а отягчающим обстоятельством. Зачем сунулись на такую работу с нулевыми знаниями?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11815
