Skip to content
This repository was archived by the owner on May 26, 2022. It is now read-only.

fix typos in strategy chapter #46

Merged
merged 1 commit into from
Sep 17, 2017
Merged

fix typos in strategy chapter #46

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions postgresql_strategy.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,20 +6,20 @@ \chapter{Стратегии масштабирования для PostgreSQL}

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

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

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

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

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

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

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

\input{strategy/read}
\input{strategy/write}
Expand Down
2 changes: 1 addition & 1 deletion strategy/read.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ \section{Проблема чтения данных}
\subsection{Методы решения}

\begin{itemize}
\item \textbf{PgPool-II v.3 + PostgreSQL v.9 с Streaming Replication}~--- отличное решение для масштабирования на чтение, более подробно можно ознакомится по \href{http://pgpool.projects.pgfoundry.org/contrib\_docs/simple\_sr\_setting/index.html}{ссылке}. Основные преимущества:
\item \textbf{PgPool-II v.3 + PostgreSQL v.9 с Streaming Replication}~--- отличное решение для масштабирования на чтение, более подробно можно ознакомиться по \href{http://pgpool.projects.pgfoundry.org/contrib\_docs/simple\_sr\_setting/index.html}{ссылке}. Основные преимущества:

\begin{itemize}
\item Низкая задержка репликации между мастером и слейвом;
Expand Down
2 changes: 1 addition & 1 deletion strategy/write.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ \section{Проблема записи данных}

\subsection{Методы решения}

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

\begin{itemize}
\item \textbf{PgQ}~--- это система очередей, разработанная на базе PostgreSQL. Разработчики~--- компания Skype. Используется в Londiste (подробнее <<\ref{sec:londiste}~\nameref{sec:londiste}>>). Особенности:
Expand Down