postgresql_strategy.tex

\chapter{Стратегии масштабирования для PostgreSQL}

\begin{epigraphs}
\qitem{В конце концов, все решают люди, не стратегии}{Ларри Боссиди}
\end{epigraphs}

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

Многие разработчики крупных проектов сталкиваются с проблемой, когда один-единственный сервер базы данных никак не может справиться с нагрузками. Очень часто такие проблемы происходят из-за неверного проектирования приложения (плохая структура БД для приложения, отсутствие кеширования). Но в данном случае пусть у нас есть <<идеальное>> приложение, для которого оптимизированы все SQL запросы, используется кеширование, PostgreSQL настроен, но все равно не справляется с нагрузкой. Такая проблема может возникнуть как на этапе проектирования, так и на этапе роста приложения. И тут возникает вопрос: какую стратегию выбрать при возникновении подобной ситуации?

Если Ваш заказчик готов купить супер сервер за несколько тысяч долларов (а по мере роста~--- десятков тысяч и~т.~д.), чтобы сэкономить время разработчиков, но сделать все быстро, можете дальше эту главу не читать. Но такой заказчик~--- мифическое существо и, в основном, такая проблема ложится на плечи разработчиков.

\subsection{Суть проблемы}

Для того, чтобы сделать какой-то выбор, необходимо знать суть проблемы. Существуют два предела, в которые могут уткнуться сервера баз данных:

\begin{itemize}
  \item Ограничение пропускной способности чтения данных;
  \item Ограничение пропускной способности записи данных;
\end{itemize}

Практически никогда не возникает одновременно две проблемы, по крайне мере, это маловероятно (если вы, конечно, не Twitter или Facebook пишете). Если вдруг такое происходит~--- возможно, система неверно спроектирована, и её реализацию следует пересмотреть.

\input{strategy/read}
\input{strategy/write}

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

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