Merge branch 'master' into dev

Author: le0pard

postgresql_replication.tex

@@ -24,7 +24,7 @@ \section{Введение}
 \begin{itemize}
   \item \href{http://www.slony.info/}{Slony-I}~--- асинхронная Master-Slave репликация, поддерживает каскады(cascading) и отказоустойчивость(failover). Slony-I использует триггеры PostgreSQL для привязки к событиям INSERT/DELETE/UPDATE и хранимые процедуры для выполнения действий;
 
-  \item \href{http://pgpool.projects.postgresql.org/}{Pgpool-I/II}~--- это замечательный инструмент для PostgreSQL (лучше сразу работать с II версией). Позволяет делать:
+  \item \href{http://pgpool.net/}{Pgpool-I/II}~--- это замечательный инструмент для PostgreSQL (лучше сразу работать с II версией). Позволяет делать:
   \begin{itemize}
     \item репликацию (в том числе, с автоматическим переключением на резервный stand-by сервер);
     \item online-бэкап;

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}

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 Низкая задержка репликации между мастером и слейвом;

strategy/write.tex

@@ -4,7 +4,7 @@ \section{Проблема записи данных}
 
 \subsection{Методы решения}
 
-Один из самых популярных методов решение проблем~--- размазать нагрузку по времени с помощью систем очередей.
+Один из самых популярных методов решения проблемы~--- размазать нагрузку по времени с помощью систем очередей.
 
 \begin{itemize}
   \item \textbf{PgQ}~--- это система очередей, разработанная на базе PostgreSQL. Разработчики~--- компания Skype. Используется в Londiste (подробнее <<\ref{sec:londiste}~\nameref{sec:londiste}>>). Особенности: