Ответ
Вертикальное шардирование (вертикальное партиционирование) — это метод разделения таблицы базы данных по столбцам, при котором разные группы атрибутов хранятся в отдельных таблицах, часто на разных физических носителях или серверах.
Принцип работы: Исходная широкая таблица разбивается на несколько узких таблиц, связанных по первичному ключу. Часто используемые столбцы ("горячие данные") отделяются от редко запрашиваемых ("холодные данные").
Пример на SQL:
-- Исходная таблица
CREATE TABLE users (
id INT PRIMARY KEY,
username VARCHAR(50),
password_hash VARCHAR(255),
email VARCHAR(100),
profile_text TEXT,
last_login TIMESTAMP,
metadata JSON
);
-- После вертикального шардирования:
-- Таблица для частых операций (авторизация)
CREATE TABLE users_core (
id INT PRIMARY KEY,
username VARCHAR(50),
password_hash VARCHAR(255),
email VARCHAR(100),
last_login TIMESTAMP
);
-- Таблица для редко используемых данных
CREATE TABLE users_profile (
user_id INT PRIMARY KEY REFERENCES users_core(id),
profile_text TEXT,
metadata JSON
);Преимущества:
- Увеличение производительности чтения — уменьшается объем данных, загружаемых в память при частых запросах
- Улучшение кэширования — "горячие" данные эффективнее помещаются в кэш
- Возможность разного хранения — разные типы данных можно хранить на оптимальных для них носителях (SSD для частых запросов, HDD для архивных данных)
- Безопасность — чувствительные данные можно изолировать
Недостатки:
- Усложнение JOIN-запросов — для получения полных данных требуются соединения таблиц
- Нарушение атомарности операций — обновления нескольких таблиц требуют транзакций
- Сложность поддержки целостности — необходимы внешние ключи и каскадные операции
Типичные сценарии использования:
- Разделение часто и редко запрашиваемых атрибутов (логин/пароль vs. биография)
- Изоляция BLOB/CLOB данных (изображения, документы) в отдельные таблицы
- Реализация multi-tenant архитектуры с общими и tenant-specific данными
- Оптимизация под column-oriented СУБД (ClickHouse, Vertica)
Ответ 18+ 🔞
Слушай, а вот есть такая штука — вертикальное шардирование. Ну или, если по-простому, вертикальное партиционирование. Это когда ты свою здоровенную, распиздяйскую таблицу в базе начинаешь резать не по строкам, а по столбцам. Представь: у тебя таблица users на 50 полей, и половину из них ты запрашиваешь раз в год, а другую — каждый раз, когда юзер тыкает в кнопку. Так вот, идея в том, чтобы отпилить эти редкостные колонки в отдельную таблицу и не таскать их в память каждый божий раз. Гениально и просто, как топор.
Как это, блядь, работает:
Берёшь свою жирную таблицу и делаешь из неё несколько тощих. Связываешь их по первичному ключу (обычно id). Всё, что нужно часто и быстро — «горячие данные» — летит в одну таблицу на быстрых дисках. Всё остальное — «холодные данные», вроде текста биографии или какой-нибудь ёбаной меты в JSON — отправляется в другую, и пусть там лежит.
Смотри, как это выглядит в коде:
-- Была у нас таблица — монстр, жрёт память и тормозит.
CREATE TABLE users (
id INT PRIMARY KEY,
username VARCHAR(50),
password_hash VARCHAR(255),
email VARCHAR(100),
profile_text TEXT, -- Кто это вообще читает? Раз в пятилетку.
last_login TIMESTAMP,
metadata JSON -- И эта хрень тоже.
);
-- А стала — две аккуратные таблички.
-- Вот ядро, то, что нужно для входа и работы каждый день:
CREATE TABLE users_core (
id INT PRIMARY KEY,
username VARCHAR(50),
password_hash VARCHAR(255),
email VARCHAR(100),
last_login TIMESTAMP
);
-- А это — доп. инфа, на которую всем похуй 99% времени:
CREATE TABLE users_profile (
user_id INT PRIMARY KEY REFERENCES users_core(id),
profile_text TEXT,
metadata JSON
);Что хорошего-то?
- Скорость чтения зашкаливает. Тебе не нужно грузить в память овердохуища данных, чтобы просто авторизовать пользователя. Запрос летает.
- Кэш работает как часы. Маленькая табличка
users_coreцеликом влезает в кэш, и всё мгновенно. - Можно хранить по-разному. Горячее — на SSD, холодное — на дешёвом HDD, и всем хорошо.
- Безопасность. Чувствительные данные можно вообще на отдельный сервер засунуть, подальше от глаз.
Но и подводных камней, ёпта, хватает:
- JOIN-ы. Чтобы собрать полный профиль, теперь надо делать JOIN. А это, знаешь, не всегда бесплатно.
- Атомарность хромает. Обновить данные в двух таблицах за раз — уже нужна транзакция, а это накладные расходы.
- Целостность. Надо следить за внешними ключами, чтобы не получилось так, что профиль есть, а юзера — хуй с горы.
Где это пригождается?
- Разделение частого и редкого. Логин/пароль — отдельно, трёхтомная автобиография — отдельно.
- Вынос BLOB-ов. Картинки, документы, видео — всё это пиздец как тяжелое, пусть живёт своей жизнью.
- Multi-tenant архитектура. Общие данные — в одну таблицу, а специфичные для каждого клиента — в другую.
- Column-oriented базы. Для всяких ClickHouse и Vertica это вообще родная стихия, они так и работают.
Короче, инструмент мощный, но не серебряная пуля. Если у тебя таблица — реально пиздопроебибна по ширине, и большая часть полей простаивает, то вертикальное шардирование может вытащить твою производительность из жопы. Но если начнёшь бездумно плодить JOIN-ы на каждый чих — сам от себя охуеешь от новых проблем. Думай головой, чувак.
