PostgreSQL

Скорее всего вам придется использовать PostgreSQL в вашем собеседовании по проектированию систем. Ведь этот инструмент стабильно занимает первое место среди популярных баз данных согласно опросу разработчиков Stack Overflow и используется компаниями от Reddit до Uber и даже сайтом, который вы читаете прямо сейчас.

Тем не менее, важно понимать, что хотя PostgreSQL обладает множеством функций и возможностей, ваш интервьюер ищет не администратора базы данных. Его интересует способность принимать обоснованные архитектурные решения. Когда стоит выбрать PostgreSQL? Когда лучше рассмотреть альтернативы? Какие ключевые компромиссы следует учитывать?

Часто кандидаты допускают ошибки именно здесь. Они либо погружаются слишком глубоко в подробности внутренней структуры PostgreSQL (например, рассказывают о модели MVCC и журнале упреждающей записи WAL, когда интервьюеру достаточно понимания того, сможет ли база обрабатывать ваши данные), либо делают чрезмерно обобщенные утверждения вроде "NoSQL масштабируется лучше, чем PostgreSQL", не понимая нюансов.

В этом подробном обзоре мы сосредоточимся исключительно на том, что вам действительно нужно знать о PostgreSQL для собеседований по проектированию систем. Мы начнем с наглядного примера, рассмотрим ключевые возможности и ограничения, влияющие на выбор архитектуры, и перейдем к распространенным сценариям собеседования.

Мы предполагаем, что у вас есть базовые знания SQL. Если нет, мы добавили приложение Основы SQL в конце статьи для ознакомления.

Давайте приступим.

Практический пример

Начнем знакомство с PostgreSQL на конкретном примере. Представьте, что мы разрабатываем социальную платформу – не такую огромную, как VK, но растущую и нуждающуюся в прочной основе.

Наша платформа должна поддерживать некоторые функции:

• Пользователи могут создавать посты
• Пользователи могут комментировать посты
• Пользователи могут подписываться друг на друга
• Пользователи могут ставить лайки постам и комментариям
• Пользователи могут отправлять личные сообщения другим пользователям

Что интересно с точки зрения базы данных? Различные операции имеют разные требования:

• Многошаговые операции, такие как создание личных чатов, должны выполняться атомарно (создание чата, добавление участников и сохранение первого сообщения должно происходить одновременно)
• Отношения комментариев и подписки требуют целостности ссылок (нельзя иметь комментарий к несуществующему посту или подписаться на несуществующего пользователя)
• Подсчет лайков может иметь согласованность в конечном счете (не критично, если обновление займет несколько секунд)
• Когда запрашиваются профили пользователей, нам необходимо эффективно извлекать их недавние посты, количество подписчиков и другие метаданные
• Пользователи могут искать посты и других пользователей
• По мере роста нашей платформы потребуется обрабатывать больше данных и более сложные запросы

Эта комбинация требований – сложные связи данных, смешанные требования о согласованности, возможности поиска и пространство для масштабирования – делает данный пример идеальным для изучения сильных сторон и ограничений PostgreSQL. На протяжении всего обзора мы будем возвращаться к этому примеру, чтобы подкреплять наше обсуждение практической информацией.

Основные возможности и ограничения

Теперь давайте углубимся в то, что PostgreSQL хорошо умеет и чего не умеет. Большинство обсуждений проектирования систем вокруг PostgreSQL будут вращаться вокруг производительности чтения, возможностей записи, гарантий согласованности и гибкости схемы. Понимание этих ключевых характеристик поможет вам в принятии решений о том, когда использовать PostgreSQL в вашей архитектуре.

Производительность чтения

Производительность чтения имеет первостепенное значение, поскольку в большинстве приложений чтение значительно превосходит запись. В нашем примере социальной сети пользователи проводят гораздо больше времени, просматривая посты и профили, чем создавая контент.

При просмотре профиля пользователя нам необходимо быстро получать все посты этого пользователя. Без надлежащего индексирования PostgreSQL пришлось бы сканировать каждую строку таблицы постов, чтобы найти соответствующие посты – процесс, который становится все дороже по мере увеличения объема наших данных. Именно здесь нам нужны индексы. Создав индекс по столбцу user_id нашей таблицы постов, мы можем быстро найти все посты конкретного пользователя, не проверяя всю таблицу.

Базовая индексация

Самый простой способ ускорить чтение в PostgreSQL – использование индексов. По умолчанию PostgreSQL применяет индексы типа B-Tree, которые отлично подходят для:

• Точных совпадений (WHERE email = 'user@example.com')
• Диапазонных запросов (WHERE created_at > '2026-01-01')
• Сортировки (ORDER BY username, если столбец сортировки соответствует порядку столбцов индекса)

По умолчанию PostgreSQL создает индекс B-Tree на колонку первичного ключа, но вы можете создать индексы и на другие колонки.

-- Это ваш основной индекс
CREATE INDEX idx_users_email ON users(email);
 
-- Индекс на несколько колонок для распространенных шаблонов запросов
CREATE INDEX idx_posts_user_date ON posts(user_id, created_at);