API
Pagination: тест с выбором ответа
Суть Синтез по всему юниту в формате выбора: стоимость offset против keyset, дрейф страниц при записи, стабильный ordering, opaque cursor и скрытый налог на COUNT.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов на весь юнит. Ни один не про определение — каждый это решение, которое вы принимаете, проектируя реальный list-эндпоинт, обязанный пережить таблицу на 50 миллионов строк и постоянные записи.
Цель
Убедитесь, что вы связываете стоимость offset, дрейф страниц, стабильность ordering, контракт opaque cursor и налог на подсчёт — это синтез, к которому вёл урок, а не отдельные факты.
Викторина
Completed
Эндпоинт выполняет LIMIT 20 OFFSET 200000 по таблице на 50M строк. Возвращает 20 строк, но занимает ~8 секунд. Почему стоимость растёт с offset, а не с размером страницы?
Heads-up Ответ всегда 20 строк, его размер постоянен. Стоимость это 200000 строк, которые движок читает и выбрасывает по пути к ним — в размере ответа их не видно.
Heads-up Индекс по-прежнему упорядочивает строки; движку просто приходится пройти мимо каждой offset-строки, чтобы их отсчитать. Это работа scan-and-discard, а не отсутствие индекса.
Heads-up OFFSET это обычное чтение и такой блокировки не берёт. Задержка это линейная работа read-and-discard, пропорциональная значению offset.
Викторина
Completed
В быстрой ленте пользователи видят один и тот же пост дважды, а другие клянутся, что посты 'исчезли'. Фронтенд корректен, таблица маленькая. В чём причина?
Heads-up Никакого кэша нет, и симптом появляется в момент, когда два запроса оказываются по разные стороны одной записи. Дрейф внутренне присущ позиционной пагинации, а не кэшу.
Heads-up Размер страницы не вызывает дрейф; при любом размере те же позиционные границы. Дубликаты и пропуски даёт смещение границы при вставках/удалениях.
Heads-up Дубликаты и пропуски это реальный баг корректности позиционной пагинации. Keyset с привязкой к значению их устраняет.
Викторина
Completed
Keyset-лента сортирует только по created_at DESC и несёт последний created_at как cursor. Иногда пост на стыке страниц пропускается или показывается дважды. Почему и что это исправляет?
Heads-up Метки времени сравниваются корректно как значения. Дефект в неуникальности: совпадения на стыке ломают seek, если не добавить уникальный tiebreaker вроде первичного ключа.
Heads-up Сортировка только по id отменяет порядок newest-first, нужный продукту. Оставьте created_at и добавьте id как уникальный tiebreaker, чтобы держались и ordering, и стабильность.
Heads-up Большая страница не делает ключ уникальным; совпадения всё равно могут попасть на любую границу. Исправление это уникальный составной ключ сортировки, а не больший размер страницы.
Викторина
Completed
Продукту нужны и админская таблица с 'перейти на страницу 4000 из 80000', и публичная лента с бесконечным скроллом по тем же данным. Какое решение верное?
Heads-up Keyset не умеет прыгать на произвольную страницу N; он только идёт next/prev. Требование 'перейти на страницу 4000' это ровно единственное реальное преимущество offset.
Heads-up Offset на публичной ленте возвращает медленные глубокие страницы и дрейф при записи — те самые отказы, о которых юнит. Подбирайте стратегию под паттерн доступа поверхности.
Heads-up Подсчёт cursor для подделки номеров страниц всё равно требует знать общую позицию — это и есть тот offset-скан, которого вы избегали. Произвольные переходы это домен offset по своей природе.
Викторина
Completed
Коллега предлагает вернуть сырой кортеж (created_at, id) как cursor, 'раз клиент всё равно просто шлёт его обратно'. Почему лучше непрозрачный (opaque) cursor?
Heads-up Стоимость декодирования ничтожна в обоих случаях. Причина в эволюции контракта и защите от рукотворных cursor — не в скорости декодирования.
Heads-up Кортеж нормально сериализуется в JSON. Суть в том, что раскрытие внутренних ключей привязывает контракт к вашей схеме и позволяет клиентам собирать произвольные seek.
Heads-up Непрозрачность не связана с произвольными переходами; keyset всё равно идёт только next/prev. Непрозрачность защищает контракт и ограничивает рукотворные cursor.
Викторина
Completed
Эндпоинт теперь быстр через keyset, но p99 всё ещё высок из-за подвала 'Показано 1–20 из 4 812 339'. Почему точный подсчёт дорог в Postgres и какой senior-ход?
Heads-up COUNT(*) не блокирует; это чтение. Стоимость это обход строк под MVCC для определения видимости, скан, растущий с таблицей.
Heads-up Postgres не может прочитать точный видимый счёт из метаданных именно потому, что MVCC даёт каждой транзакции свой видимый набор. reltuples это оценка, а не точные метаданные.
Heads-up Индекс не даёт точный видимый счёт под MVCC; движок всё равно обходит строки ради видимости. Исправление это оценить или взять LIMIT n+1, а не индексировать сильнее.
Итог
Сквозная линия юнита это одно решение: адресуете страницы по позиции (offset) — платите дважды: глубокие страницы линейно делают scan-and-discard, а позиционные границы дрейфуют при записи в дубликаты и пропуски. Адресуете по значению (keyset) по уникальному, стабильному, индексированному ключу — задержка остаётся плоской без дрейфа, ценой потери произвольных переходов по страницам, поэтому offset всё ещё уместен на ограниченных админских таблицах. Отдавайте клиентам opaque cursor, чтобы контракт мог эволюционировать, и относитесь к точному итогу как к отдельному скану: оценивайте или зондируйте через LIMIT n+1 вместо подсчёта, который никому не нужен.