Merge pull request #46 from olshevskiy87/t12

le0pard · web-flow · commit b18568c6ddcf · 2017-09-17T20:35:16.000+03:00
fix typos in strategy chapter
diff --git a/postgresql_strategy.tex b/postgresql_strategy.tex
@@ -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}
diff --git a/strategy/read.tex b/strategy/read.tex
@@ -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 Низкая задержка репликации между мастером и слейвом;
diff --git a/strategy/write.tex b/strategy/write.tex
@@ -4,7 +4,7 @@ \section{Проблема записи данных}
 
 \subsection{Методы решения}
 
-Один из самых популярных методов решение проблем~--- размазать нагрузку по времени с помощью систем очередей.
+Один из самых популярных методов решения проблемы~--- размазать нагрузку по времени с помощью систем очередей.
 
 \begin{itemize}
   \item \textbf{PgQ}~--- это система очередей, разработанная на базе PostgreSQL. Разработчики~--- компания Skype. Используется в Londiste (подробнее <<\ref{sec:londiste}~\nameref{sec:londiste}>>). Особенности:
