Ответ
Вертикальное партиционирование — это метод оптимизации базы данных, при котором таблица разделяется на несколько физических таблиц по столбцам, а не по строкам. Каждая новая таблица содержит подмножество столбцов исходной таблицы, связанных общим первичным ключом.
Цель: Разделить часто и редко запрашиваемые данные, а также чувствительные данные, для повышения производительности и безопасности.
Пример:
Исходная таблица employee:
CREATE TABLE employee (
id INT PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(100),
salary DECIMAL(10,2), -- Чувствительные данные
resume_text TEXT, -- Большие, редко используемые данные
hire_date DATE
);После вертикального партиционирования:
-- Таблица с часто используемыми и "легкими" данными
CREATE TABLE employee_core (
id INT PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(100),
hire_date DATE
);
-- Таблица с чувствительными/редкими данными
CREATE TABLE employee_sensitive (
id INT PRIMARY KEY REFERENCES employee_core(id),
salary DECIMAL(10,2),
resume_text TEXT
);Преимущества:
- Производительность: Уменьшение размера строк в основной таблице (
employee_core) позволяет поместить больше строк в кэш БД, ускоряяSELECT *и сканирования. - Безопасность: Можно ограничить доступ к
employee_sensitiveна уровне БД. - Управление хранилищем: Большие поля (BLOB, TEXT) можно вынести на отдельное, возможно, более медленное хранилище.
Недостатки:
- Сложность запросов: Для получения полного набора данных требуются
JOIN. - Согласованность: Необходимо обеспечивать целостность данных между партициями (часто через внешние ключи и транзакции).
Ответ 18+ 🔞
А, ну это ж классика, блядь! Вертикальное партиционирование, ёпта! Это когда ты смотришь на свою здоровенную, раздутую таблицу и думаешь: «Ну и зачем мне тут этот пиздопроёбищный resume_text на полмегабайта, который запрашивают раз в пятилетку, таскается в каждой выборке?»
Суть проще пареной репы, хоть и звучит умно. Берёшь таблицу — и вдоль, сука, по столбцам режешь, как колбасу! Не путай с горизонтальным, там по строкам делят, это другая история. Ты создаёшь несколько новых таблиц, и в каждой — свой кусок столбцов от оригинала. Но связывает их один и тот же первичный ключ, чтобы потом, если что, склеить обратно.
Зачем это надо, спросишь? Да чтобы не грузить в оперативку всякую хуйню, которая не нужна! Частые запросы летают по маленькой, лёгкой табличке, а всякие salary или гигабайтные резюме лежат отдельно, под замком. Производительность подскакивает, потому что в кэш помещается овердохуища строк, да и безопасность: доступ к зарплатам можно на уровне базы отрубить.
Смотри, как это выглядит на практике.
Была у тебя жирная таблица employee:
CREATE TABLE employee (
id INT PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(100),
salary DECIMAL(10,2), -- Чувствительные данные, блядь!
resume_text TEXT, -- Вот эта манда, которую никто не читает
hire_date DATE
);А стала — две аккуратненькие:
-- Ядро, основа, то, что постоянно нужно
CREATE TABLE employee_core (
id INT PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(100),
hire_date DATE
);
-- А это уже сейф, чулан, куда сложили всё ценное и громоздкое
CREATE TABLE employee_sensitive (
id INT PRIMARY KEY REFERENCES employee_core(id),
salary DECIMAL(10,2),
resume_text TEXT
);Что хорошего? Да всё, блядь! Основные запросы за именами и почтами — просто ракета. Безопасность на уровне: дай доступ к core, а sensitive — только бухгалтерии. Большие поля не тормозят всю систему.
А что плохого? Да обычная бюрократия, ёпта! Хочешь полное досье на сотрудника — готовься делать JOIN. И следи, чтобы данные между таблицами не разъехались, а то будет конфуз. Целостность — твоя головная боль теперь.
Короче, инструмент мощный, но не серебряная пуля. Как скальпель: в умелых руках — операция, в кривых — себе же хуже сделаешь. Используй с умом, когда реально есть жирные, редко используемые или секретные столбцы.