postgresql_clustering.tex

\chapter{Шардинг}

\begin{epigraphs}
\qitem{Если ешь слона, не пытайся запихать его в рот целиком}{Народная мудрость}
\end{epigraphs}

\section{Введение}

Шардинг~--- разделение данных на уровне ресурсов. Концепция шардинга заключается в логическом разделении данных по различным ресурсам, исходя из требований к нагрузке.

Рассмотрим пример. Пусть у нас есть приложение с регистрацией пользователей, которое позволяет писать друг другу личные сообщения. Допустим оно очень популярно, и много людей им пользуются ежедневно. Естественно, что таблица с личными сообщениями будет намного больше всех остальных таблиц в базе (скажем, будет занимать 90\% всех ресурсов). Зная это, мы можем подготовить для этой (только одной!) таблицы выделенный сервер помощнее, а остальные оставить на другом (послабее). Теперь мы можем идеально подстроить сервер для работы с одной специфической таблицей, постараться уместить ее в память, возможно, дополнительно партиционировать ее и~т.~д. Такое распределение называется вертикальным шардингом.

Что делать, если наша таблица с сообщениями стала настолько большой, что даже выделенный сервер под нее одну уже не спасает? Необходимо делать горизонтальный шардинг~--- т.~е. разделение одной таблицы по разным ресурсам. Как это выглядит на практике? На разных серверах у нас будет таблица с одинаковой структурой, но разными данными. Для нашего случая с сообщениями, мы можем хранить первые 10 миллионов сообщений на одном сервере, вторые 10 - на втором и~т.~д. Т.~е. необходимо иметь критерий шардинга~--- какой-то параметр, который позволит определить, на каком именно сервере лежат те или иные данные.

Обычно, в качестве параметра шардинга выбирают ID пользователя (\lstinline!user_id!)~--- это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой:

\begin{itemize}
  \item Определить, на каком сервере БД лежат сообщения пользователя, исходя из \lstinline!user_id!;
  \item Инициализировать соединение с этим сервером;
  \item Выбрать сообщения;
\end{itemize}

Задачу определения конкретного сервера можно решать двумя путями:

\begin{itemize}
  \item Хранить в одном месте хеш-таблицу с соответствиями <<пользователь=сервер>>. Тогда, при определении сервера, нужно будет выбрать сервер из этой таблицы. В этом случае узкое место~--- это большая таблица соответствия, которую нужно хранить в одном месте. Для таких целей очень хорошо подходят базы данных <<ключ=значение>>;
  \item Определять имя сервера с помощью числового (буквенного) преобразования. Например, можно вычислять номер сервера, как остаток от деления на определенное число (количество серверов, между которыми Вы делите таблицу). В этом случае узкое место~--- это проблема добавления новых серверов~--- придется делать перераспределение данных между новым количеством серверов;
\end{itemize}

Естественно, делая горизонтальный шардинг, Вы ограничиваете себя в возможности выборок, которые требуют пересмотра всей таблицы (например, последние посты в блогах людей будет достать невозможно, если таблица постов шардится). Такие задачи придется решать другими подходами. Например, для описанного примера, можно при появлении нового поста, заносить его ID в общий стек, размером в 100 элементом.

Горизонтальный шардинг имеет одно явное преимущество~--- он бесконечно масштабируем. Для создания шардинга PostgreSQL существует несколько решений:

\begin{itemize}
  \item \href{http://postgres-xc.sourceforge.net/}{Postgres-XC}
  \item \href{http://www.greenplum.com/products/greenplum-database}{Greenplum Database}
  \item \href{https://github.com/citusdata/citus}{Citus}
  \item \href{http://plproxy.projects.postgresql.org/doc/tutorial.html}{PL/Proxy}
  \item \href{https://launchpad.net/stado}{Stado (sequel to GridSQL)}
\end{itemize}


\input{clustering/plproxy}
\input{clustering/postgres_x2}
\input{clustering/postgres_xl}
\input{clustering/citus}
\input{clustering/greenplum}


\section{Заключение}

В данной главе рассмотрены лишь базовые настройки кластеров БД. Про кластеры PostgreSQL потребуется написать отдельную книгу, чтобы рассмотреть все шаги с установкой, настройкой и работой кластеров. Надеюсь, что несмотря на это, информация будет полезна многим читателям.