Merge branch 'master' into dev

Author: le0pard

cache/pgmemcache.tex

@@ -81,7 +81,7 @@ \subsection{Проверка}
 newval = memcache\_decr(key::TEXT)
 &
 Если ключ существует и является целым числом, происходит уменьшение
-его значения на указаное число (по умолчанию на единицу).
+его значения на указанное число (по умолчанию на единицу).
 Возвращает целое число после уменьшения.\\
 
 \hline
@@ -126,7 +126,7 @@ \subsection{Проверка}
 
 &
 Если ключ существует и является целым числом, происходит увеличение
-его значения на указаное число (по умолчанию на единицу).
+его значения на указанное число (по умолчанию на единицу).
 Возвращает целое число после увеличения.\\
 
 \hline
@@ -149,7 +149,7 @@ \subsection{Проверка}
 memcache\_set(key::TEXT, value::TEXT)
 
 &
-Создает ключ со значением. Если такой ключ существует~--- заменяет в нем значение на указаное.\\
+Создает ключ со значением. Если такой ключ существует~--- заменяет в нем значение на указанное.\\
 
 \hline
 
@@ -262,7 +262,7 @@ \subsection{Проверка}
 
 Для работы с pgmemcache лучше создать функции и, если требуется, активировать эти функции через триггеры.
 
-Например, приложение кэширует зашифрованые пароли пользователей в memcached (для более быстрого доступа), и нам требуется обновлять информацию в кэше, если она изменяется в СУБД. Создаем функцию:
+Например, приложение кэширует зашифрованные пароли пользователей в memcached (для более быстрого доступа), и нам требуется обновлять информацию в кэше, если она изменяется в СУБД. Создаем функцию:
 
 \begin{lstlisting}[language=SQL,label=lst:pgcache11,caption=Функция для обновления данных в кэше]
 CREATE OR REPLACE FUNCTION auth_passwd_upd() RETURNS TRIGGER AS $$
@@ -281,7 +281,7 @@ \subsection{Проверка}
 CREATE TRIGGER auth_passwd_upd_trg AFTER UPDATE ON passwd FOR EACH ROW EXECUTE PROCEDURE auth_passwd_upd();
 \end{lstlisting}
 
-Но данный пример транзакционно не безопасен~--- при отмене транзации кэш не вернется на старое значение. Поэтому лучше очищать старые данные:
+Но данный пример транзакционно небезопасен~--- при отмене транзакции кэш не вернется на старое значение. Поэтому лучше очищать старые данные:
 
 \begin{lstlisting}[language=SQL,label=lst:pgcache13,caption=Очистка ключа в кэше]
 CREATE OR REPLACE FUNCTION auth_passwd_upd() RETURNS TRIGGER AS $$

clustering/plproxy.tex

@@ -12,7 +12,7 @@ \section{PL/Proxy}
 \begin{itemize}
   \item все запросы и вызовы функций вызываются в autocommit-режиме на удаленных серверах;
   \item в теле функции разрешен только один \lstinline!SELECT!. При необходимости нужно писать отдельную процедуру;
-  \item при каждом вызове прокси-сервер стартует новое соединение к бакенд-серверу. В высоконагруженных системах целесообразно использовать менеджер для кеширования соединений к бакенд-серверам (для этой цели идеально подходит PgBouncer);
+  \item при каждом вызове прокси-сервер стартует новое соединение к бэкенд-серверу. В высоконагруженных системах целесообразно использовать менеджер для кеширования соединений к бэкенд-серверам (для этой цели идеально подходит PgBouncer);
   \item изменение конфигурации кластера (например количества партиций) требует перезапуска прокси-сервера;
 \end{itemize}
 

clustering/postgres_x2.tex

@@ -351,4 +351,4 @@ \subsection{Ограничения}
 
 \subsection{Заключение}
 
-Postgres-X2 очень перспективное решение для создание кластера на основе PostgreSQL. И хоть это решение имеет ряд недостатков, нестабильно (очень часты случаи падения координаторов при тяжелых запросах) и еще очень молодое, со временем это решение может стать стандартом для масштабирования систем на PostgreSQL.
+Postgres-X2 очень перспективное решение для создания кластера на основе PostgreSQL. И хоть это решение имеет ряд недостатков, нестабильно (очень часты случаи падения координаторов при тяжелых запросах) и еще очень молодое, со временем это решение может стать стандартом для масштабирования систем на PostgreSQL.

extensions/postgis.tex

@@ -1,6 +1,6 @@
 \section{PostGIS}
 
-\href{http://www.postgis.org/}{PostGIS} добавляет поддержку для географических объектов в PostgreSQL. По сути PostGIS позволяет использовать PostgreSQL в качестве бэкэнда пространственной базы данных для геоинформационных систем (ГИС), так же, как ESRI SDE или пространственного расширения Oracle. PostGIS соответствует OpenGIS <<Простые особенности. Спецификация для SQL>> и был сертифицирован.
+\href{http://www.postgis.org/}{PostGIS} добавляет поддержку для географических объектов в PostgreSQL. По сути PostGIS позволяет использовать PostgreSQL в качестве бэкенда пространственной базы данных для геоинформационных систем (ГИС), так же, как ESRI SDE или пространственного расширения Oracle. PostGIS соответствует OpenGIS <<Простые особенности. Спецификация для SQL>> и был сертифицирован.
 
 \subsection{Установка и использование}
 
@@ -50,7 +50,7 @@ \subsection{Установка и использование}
 (3 rows)
 \end{lstlisting}
 
-Большинство таких функций начинаются с ST (пространственный тип) и описаны в документации PostGIS. Теперь ответим на практический вопрос: на каком расстоянии в метрах друг от другах находятся три города с названием Лондон, учитывая сферичность земли?
+Большинство таких функций начинаются с ST (пространственный тип) и описаны в документации PostGIS. Теперь ответим на практический вопрос: на каком расстоянии в метрах друг от друга находятся три города с названием Лондон, учитывая сферичность земли?
 
 \begin{lstlisting}[language=SQL,label=lst:postgisselectcities3,caption=Расстояние до Лондона]
 # SELECT p1.name,p2.name,ST_Distance_Sphere(p1.the_geom,p2.the_geom) FROM cities AS p1, cities AS p2 WHERE p1.id > p2.id;

partitioning/pg_partman.tex

@@ -2,7 +2,7 @@ \section{Pg\_partman}
 
 Поскольку реализация партиционирования реализована неполноценно в PostgreSQL (для управления партициями и данными в них приходится писать функции, тригеры и правила), то существует расширение, которое автоматизирует полностью данный процесс. \href{https://github.com/keithf4/pg\_partman}{PG Partition Manager}, он же pg\_partman, это расширение для создания и управления партициями и партициями партиций (sub-partitoning) в PostgreSQL. Поддерживает партицирование по времени (time-based) или по последованности (serial-based). Для партицирования по диапазону значений (range) существует отдельное расширение \href{https://github.com/moat/range\_partitioning}{Range Partitioning (range\_partitioning)}.
 
-Текущая реализация поддерживает только INSERT операции, которые перенаправляют данные в нужную партицию. UPDATE операции, которые будут перемещать данные из одной партиции в другую, не поддерживаются. При попытке вставить данные, на которые нет партиции, pg\_partman перемещает их в <<мастер>> (родительскую) таблицу. Данный вариант предпочтительнее, чем создавать автоматически новые партиции, поскольку это может привести к созданию десятков или сотен ненужных дочерных таблиц из-за ошибки в самих данных. Функция \lstinline!check_parent! позволят проверить попадение подобных данных в родительскую таблицу и решить, что с ними требуется делать (удалить или использовать \lstinline!partition_data_time/partition_data_id! для создания и переноса этих данных в партиции).
+Текущая реализация поддерживает только INSERT операции, которые перенаправляют данные в нужную партицию. UPDATE операции, которые будут перемещать данные из одной партиции в другую, не поддерживаются. При попытке вставить данные, на которые нет партиции, pg\_partman перемещает их в <<мастер>> (родительскую) таблицу. Данный вариант предпочтительнее, чем создавать автоматически новые партиции, поскольку это может привести к созданию десятков или сотен ненужных дочерных таблиц из-за ошибки в самих данных. Функция \lstinline!check_parent! позволяет проверить попадение подобных данных в родительскую таблицу и решить, что с ними требуется делать (удалить или использовать \lstinline!partition_data_time/partition_data_id! для создания и переноса этих данных в партиции).
 
 Данное расширение использует большинство атрибутов родительской таблицы для создания партиций: индексы, внешние ключи (опционально), tablespace, constraints, privileges и ownership. Под такое условие попадают OID и UNLOGGED таблицы.
 

postgresql_clustering.tex

@@ -10,7 +10,7 @@ \section{Введение}
 
 Рассмотрим пример. Пусть у нас есть приложение с регистрацией пользователей, которое позволяет писать друг другу личные сообщения. Допустим оно очень популярно, и много людей им пользуются ежедневно. Естественно, что таблица с личными сообщениями будет намного больше всех остальных таблиц в базе (скажем, будет занимать 90\% всех ресурсов). Зная это, мы можем подготовить для этой (только одной!) таблицы выделенный сервер помощнее, а остальные оставить на другом (послабее). Теперь мы можем идеально подстроить сервер для работы с одной специфической таблицей, постараться уместить ее в память, возможно, дополнительно партиционировать ее и т.д. Такое распределение называется вертикальным шардингом.
 
-Что делать, если наша таблица с сообщениями стала настолько большой, что даже выделенный сервер под нее одну уже не спасает? Необходимо делать горизонтальный шардинг~--- т.е. разделение одной таблицы по разным ресурсам. Как это выглядит на практике? На разных серверах у нас будет таблица с одинаковой структурой, но разными данными. Для нашего случая с сообщениями, мы можем хранить первые 10 миллионов сообщений на одном сервере, вторые 10 - на втором и т.д. Т.е. необходимо иметь критерий шардинга~--- какой-то параметр, который позволит определять, на каком именно сервере лежат те или иные данные.
+Что делать, если наша таблица с сообщениями стала настолько большой, что даже выделенный сервер под нее одну уже не спасает? Необходимо делать горизонтальный шардинг~--- т.е. разделение одной таблицы по разным ресурсам. Как это выглядит на практике? На разных серверах у нас будет таблица с одинаковой структурой, но разными данными. Для нашего случая с сообщениями, мы можем хранить первые 10 миллионов сообщений на одном сервере, вторые 10 - на втором и т.д. Т.е. необходимо иметь критерий шардинга~--- какой-то параметр, который позволит определить, на каком именно сервере лежат те или иные данные.
 
 Обычно, в качестве параметра шардинга выбирают ID пользователя (\lstinline!user_id!)~--- это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой:
 

postgresql_connection_pooling.tex

@@ -17,8 +17,8 @@ \section{PgBouncer}
 
 \begin{itemize}
   \item Session Pooling~--- наиболее <<вежливый>> режим. При начале сессии клиенту выделяется соединение с сервером; оно приписано ему в течение всей сессии и возвращается в пул только после отсоединения клиента;
-  \item Transaction Pooling~--- клиент владеет соединением с бакендом только в течение транзакции. Когда PgBouncer замечает, что транзакция завершилась, он возвращает соединение назад в пул;
-  \item Statement Pooling~--- наиболее агрессивный режим. Соединение с бакендом возвращается назад в пул сразу после завершения запроса. Транзакции с несколькими запросами в этом режиме не разрешены, так как они гарантировано будут отменены. Также не работают подготовленные выражения (prepared statements) в этом режиме;
+  \item Transaction Pooling~--- клиент владеет соединением с бэкендом только в течение транзакции. Когда PgBouncer замечает, что транзакция завершилась, он возвращает соединение назад в пул;
+  \item Statement Pooling~--- наиболее агрессивный режим. Соединение с бэкендом возвращается назад в пул сразу после завершения запроса. Транзакции с несколькими запросами в этом режиме не разрешены, так как они гарантировано будут отменены. Также не работают подготовленные выражения (prepared statements) в этом режиме;
 \end{itemize}
 
 К достоинствам PgBouncer относится: