Мы прошли реляционную модель от отношений до плана запроса. Всё это время база жила на одном сервере. Этот урок о том, что происходит, когда одного сервера мало, и почему из-за этого в 2000-х появились десятки СУБД, которые от части реляционных гарантий отказались. В центре урока теорема CAP: самое известное и самое часто неверно понимаемое утверждение о распределённых базах.
Где реляционной модели тяжело
Реляционная модель отлично решает задачу, ради которой её придумали: хранить связанные факты без повторов и задавать к ним любые вопросы. Тяжело ей в трёх местах.
Один сервер упирается в потолок. Миллион пользователей пишут одновременно, и самый мощный сервер, который можно купить, перестаёт справляться. Купить сервер ещё мощнее называют вертикальным масштабированием, и у него есть предел. Поставить десять обычных серверов рядом называют горизонтальным масштабированием. Реляционной базе это трудно: соединения таблиц, внешние ключи и транзакции рассчитаны на то, что все данные под рукой.
Схема меняется каждую неделю. У товаров в магазине одежды размер и цвет, у ноутбуков процессор и диагональ, у книг автор и число страниц. Хранить это одной таблицей с сотней колонок, где большая часть NULL, тяжело читать и больно мигрировать.
Вопросы про связи длиной в шесть шагов. «Друзья друзей друзей, которые живут в моём городе» это шесть соединений таблицы с самой собой. Каждый шаг это ещё один JOIN, и запрос растёт вместе с длиной цепочки.
Для второй и третьей проблемы есть свои модели данных, о них следующий урок. Первая проблема глубже и касается любой базы, которая живёт на нескольких машинах.
Две копии и десять частей
Аналогия: сеть библиотек в разных районах города.
Репликация это когда в каждой библиотеке стоит полный экземпляр одного и того же каталога. Одна библиотека закрылась на ремонт, остальные работают. Читателей можно разводить по разным зданиям. Но когда в каталог добавляют новую книгу, запись нужно разнести по всем библиотекам, и пока она разносится, каталоги отличаются.
Шардирование это когда каталог делят на части: книги на буквы А-К хранятся в одной библиотеке, Л-Я в другой. Каждая библиотека держит меньше, и вместе они вмещают больше. Но вопрос «все книги 1965 года» теперь требует обойти все здания, а перенос книги из одной части в другую становится операцией между двумя библиотеками.
Обычно используют оба приёма сразу: данные делят на части, и каждую часть хранят в нескольких копиях. Как это делает PostgreSQL, подробно разобрано в уроке о распределённом Postgres.
дальше после входа
Урок целиком открыт всем, кто вошёл. Войди по своему email, чтобы читать дальше.
Вход пока по приглашению. Если хочешь учиться, напиши Vassiliy.