le0pard · le0pard · Feb 27, 2018 · Feb 27, 2018 · Feb 27, 2018 · Feb 27, 2018
diff --git a/clustering/greenplum.tex b/clustering/greenplum.tex
@@ -127,7 +127,7 @@ \subsection{Хранение данных}
 
 \subsection{Взаимодействие с клиентами}
 
-В общем случае всё взаимодействие клиентов с кластером ведётся только через мастер~--- именно он отвечает клиентам, выдаёт им результат запроса и т.д. Обычные клиенты не имеют сетевого доступа к серверам-сегментам.
+В общем случае всё взаимодействие клиентов с кластером ведётся только через мастер~--- именно он отвечает клиентам, выдаёт им результат запроса и~т.~д. Обычные клиенты не имеют сетевого доступа к серверам-сегментам.
 
 Для ускорения загрузки данных в кластер используется bulk load~--- параллельная загрузка данных с/на клиент одновременно с нескольких сегментов. Bulk load возможен только с клиентов, имеющих доступ в интерконнекты. Обычно в роли таких клиентов выступают ETL-сервера и другие системы, которым необходима загрузка большого объёма данных (на рис~\ref{fig:greenplum_arch1} они обозначены как ETL/Pro client).
 

diff --git a/clustering/postgres_x2.tex b/clustering/postgres_x2.tex
@@ -3,7 +3,7 @@ \section{Postgres-X2}
 
 Postgres-X2~-- система для создания мульти-мастер кластеров, работающих в синхронном режиме~-- все узлы всегда содержат актуальные данные. Postgres-X2 поддерживает опции для увеличения масштабирования кластера как при преобладании операций записи, так и при основной нагрузке на чтение данных: поддерживается выполнение транзакций с распараллеливанием на несколько узлов, за целостностью транзакций в пределах всего кластера отвечает специальный узел GTM (Global Transaction Manager).
 
-Измерение производительности показало, что КПД кластера Postgres-X2 составляет примерно 64\%, т.е. кластер из 10 серверов позволяет добиться увеличения производительности системы в целом в 6.4 раза, относительно производительности одного сервера (цифры приблизительные).
+Измерение производительности показало, что КПД кластера Postgres-X2 составляет примерно 64\%, т.~е. кластер из 10 серверов позволяет добиться увеличения производительности системы в целом в 6.4 раза, относительно производительности одного сервера (цифры приблизительные).
 
 Система не использует в своей работе триггеры и представляет собой набор дополнений и патчей к PostgreSQL, дающих возможность в прозрачном режиме обеспечить работу в кластере стандартных приложений, без их дополнительной модификации и адаптации (полная совместимость с PostgreSQL API). Кластер состоит из одного управляющего узла (GTM), предоставляющего информацию о состоянии транзакций, и произвольного набора рабочих узлов, каждый из которых в свою очередь состоит из координатора и обработчика данных (обычно эти элементы реализуются на одном сервере, но могут быть и разделены).
 

diff --git a/extensions/cstore_fdw.tex b/extensions/cstore_fdw.tex
@@ -126,4 +126,4 @@ \subsection{Установка и использование}
 
 \subsection{Заключение}
 
-Более подробно о использовании расширения можно ознакомиться через \href{https://citusdata.github.io/cstore_fdw/}{официальную документацию}.
+Более подробно об использовании расширения можно ознакомиться через \href{https://citusdata.github.io/cstore_fdw/}{официальную документацию}.
diff --git a/extensions/hll.tex b/extensions/hll.tex
@@ -11,11 +11,11 @@ \section{Postgresql-hll}
   \item вероятность того, что совместно произойдут два независимых случайных события $A$ и $B$, вычисляется по формуле $P(A)*P(B)$. Таким образом, если вероятность равенства единице одного любого бита случайного числа составляет 50\%, тогда вероятность равенства единице двух любых битов составляет 25\%, трех~--- 12,5\% и т.д;
 \end{itemize}
 
-Вспомним еще одно базовое положение теории вероятностей, согласно которому ожидаемое количество испытаний, необходимое для наступления события, вычисляется по формуле $1/P(event)$. Следовательно, если $P(one\ specific\ bit\ set) = 50\%$, то ожидаемое количество испытаний равно 2. Для двух битов~--- 4, для трех битов~--- 8 и т.д.
+Вспомним еще одно базовое положение теории вероятностей, согласно которому ожидаемое количество испытаний, необходимое для наступления события, вычисляется по формуле $1/P(event)$. Следовательно, если $P(one\ specific\ bit\ set) = 50\%$, то ожидаемое количество испытаний равно 2. Для двух битов~--- 4, для трех битов~--- 8 и~т.~д.
 
-В общем случае входные значения не являются равномерно распределенными случайными числами, поэтому необходим способ преобразования входных значений к равномерному распределению, т.е. необходима хеш-функция. Обратите внимание, в некоторых случаях распределение, получаемое на выходе хеш-функции, не оказывает существенное влияние на точность системы. Однако HyperLogLog очень чувствителен в этом отношении. Если выход хеш-функции не соответствует равномерному распределению, алгоритм теряет точность, поскольку не выполняются базовые допущения, лежащие в его основе.
+В общем случае входные значения не являются равномерно распределенными случайными числами, поэтому необходим способ преобразования входных значений к равномерному распределению, т.~е. необходима хеш-функция. Обратите внимание, в некоторых случаях распределение, получаемое на выходе хеш-функции, не оказывает существенное влияние на точность системы. Однако HyperLogLog очень чувствителен в этом отношении. Если выход хеш-функции не соответствует равномерному распределению, алгоритм теряет точность, поскольку не выполняются базовые допущения, лежащие в его основе.
 
-Рассмотрим алгоритм подробно. Вначале необходимо хешировать все элементы исследуемого набора. Затем нужно подсчитать количество последовательных начальных битов, равных единице, в двоичном представлении каждого хеша и определить максимальное значение этого количества среди всех хешей. Если максимальное количество единиц обозначить $n$, тогда количество уникальных элементов в наборе можно оценить, как $2^n$. То есть, если максимум один начальный бит равен единице, тогда количество уникальных элементов, в среднем, равно 2; если максимум три начальных бита равны единице, в среднем, мы можем ожидать 8 уникальных элементов и т.д.
+Рассмотрим алгоритм подробно. Вначале необходимо хешировать все элементы исследуемого набора. Затем нужно подсчитать количество последовательных начальных битов, равных единице, в двоичном представлении каждого хеша и определить максимальное значение этого количества среди всех хешей. Если максимальное количество единиц обозначить $n$, тогда количество уникальных элементов в наборе можно оценить, как $2^n$. То есть, если максимум один начальный бит равен единице, тогда количество уникальных элементов, в среднем, равно 2; если максимум три начальных бита равны единице, в среднем, мы можем ожидать 8 уникальных элементов и~т.~д.
 
 Подход, направленный на повышение точности оценки и являющийся одной из ключевых идей HyperLogLog, заключается в следующем: разделяем хеши на подгруппы на основании их конечных битов, определяем максимальное количество начальных единиц в каждой подгруппе, а затем находим среднее. Этот подход позволяет получить намного более точную оценку общего количества уникальных элементов. Если мы имеем $m$ подгрупп и $n$ уникальных элементов, тогда, в среднем, в каждой подгруппе будет $n/m$ уникальных элементов. Таким образом, нахождение среднего по всем подгруппам дает достаточно точную оценку величины $log_2{(n/m)}$, а отсюда легко можно получить необходимое нам значение. Более того, HyperLogLog позволяет обрабатывать по отдельности различные варианты группировок, а затем на основе этих данных находить итоговую оценку. Следует отметить, что для нахождения среднего HyperLogLog использует среднее гармоническое, которое обеспечивает лучшие результаты по сравнению со средним арифметическим (более подробную информацию можно найти в оригинальных публикациях, посвященных \href{http://www.ic.unicamp.br/~celio/peer2peer/math/bitmap-algorithms/durand03loglog.pdf}{LogLog} и \href{http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf}{HyperLogLog}).
 
@@ -98,4 +98,4 @@ \subsection{Установка и использование}
 
 \subsection{Заключение}
 
-Более подробно о использовании расширения можно ознакомиться через \href{https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown}{официальную документацию}.
+Более подробно об использовании расширения можно ознакомиться через \href{https://github.com/aggregateknowledge/postgresql-hll/blob/master/README.markdown}{официальную документацию}.
diff --git a/extensions/hstore.tex b/extensions/hstore.tex
@@ -1,7 +1,7 @@
 \section{HStore}
 \label{sec:hstore-extension}
 
-\href{https://www.postgresql.org/docs/current/static/hstore.html}{HStore}~-- расширение, которое реализует тип данных для хранения ключ/значение в пределах одного значения в PostgreSQL (например, в одном текстовом поле). Это может быть полезно в различных ситуациях, таких как строки с многими атрибутами, которые редко выбираются, или полу-структурированные данные. Ключи и значения являются простыми текстовыми строками.
+\href{https://www.postgresql.org/docs/current/static/hstore.html}{HStore}~-- расширение, которое реализует тип данных для хранения ключ/значение в пределах одного значения в PostgreSQL (например, в одном текстовом поле). Это может быть полезно в различных ситуациях, таких как строки со многими атрибутами, которые редко выбираются, или полу-структурированные данные. Ключи и значения являются простыми текстовыми строками.
 
 Начиная с версии 9.4 PostgreSQL был добавлен JSONB тип (бинарный JSON). Данный тип является объединением JSON структуры с возможностью использовать индексы, как у Hstore. JSONB лучше Hstore тем, что есть возможность сохранять вложеную структуру данных (nested) и хранить не только текстовые строки в значениях. Поэтому лучше использовать JSONB, если есть такая возможность.
 
@@ -90,4 +90,4 @@ \subsection{Установка и использование}
 
 \subsection{Заключение}
 
-HStore~--- расширение для удобного и индексируемого хранения слабоструктурированых данных в PostgreSQL, если нет возможности использовать версию базы 9.4 или выше, где для данной задачи есть встроеный \href{https://www.postgresql.org/docs/current/static/datatype-json.html}{JSONB} тип данных.
+HStore~--- расширение для удобного и индексируемого хранения слабоструктурированых данных в PostgreSQL, если нет возможности использовать версию базы 9.4 или выше, где для данной задачи есть встроенный \href{https://www.postgresql.org/docs/current/static/datatype-json.html}{JSONB} тип данных.
diff --git a/extensions/ltree.tex b/extensions/ltree.tex
@@ -5,7 +5,7 @@ \section{Ltree}
 \subsection{Почему Ltree?}
 
 \begin{itemize}
-  \item Реализация алгоритма Materialized Path (достаточно быстрый как на запись, так и на чтение);
+  \item Реализация алгоритма Materialized Path (довольно быстра, как на запись, так и на чтение);
   \item Как правило данное решение будет быстрее, чем использование CTE (Common Table Expressions) или рекурсивной функции (постоянно будут пересчитываться ветвления);
   \item Встроены механизмы поиска по дереву;
   \item Индексы;

diff --git a/extensions/multicorn.tex b/extensions/multicorn.tex
@@ -1,6 +1,6 @@
 \section{Multicorn}
 
-\href{http://multicorn.org/}{Multicorn}~--- расширение для PostgreSQL версии 9.1 или выше, которое позволяет создавать собственные FDW (Foreign Data Wrapper), используя язык программирования \href{https://www.python.org/}{Python}. Foreign Data Wrapper позволяют подключиться к другим источникам данных (другая база, файловая система, REST API, прочее) в PostgreSQL и были представленны с версии 9.1.
+\href{http://multicorn.org/}{Multicorn}~--- расширение для PostgreSQL версии 9.1 или выше, которое позволяет создавать собственные FDW (Foreign Data Wrapper), используя язык программирования \href{https://www.python.org/}{Python}. Foreign Data Wrapper позволяют подключиться к другим источникам данных (другая база, файловая система, REST API, прочее) в PostgreSQL и были представлены с версии 9.1.
 
 
 \subsection{Пример}
@@ -275,7 +275,7 @@ \subsubsection{Собственный FDW}
 
 \subsection{PostgreSQL 9.3+}
 
-В PostgreSQL 9.1 и 9.2 была представлена реализация FDW только на чтение. Начиная с версии 9.3, FDW может писать в внешние источники данных. Сейчас Multicorn поддерживает запись данных в другие источники, начиная с версии 1.0.0.
+В PostgreSQL 9.1 и 9.2 была представлена реализация FDW только на чтение. Начиная с версии 9.3, FDW может писать во внешние источники данных. Сейчас Multicorn поддерживает запись данных в другие источники, начиная с версии 1.0.0.
 
 \subsection{Заключение}
Original file line number	Diff line number	Diff line change
Expand Up		@@ -126,4 +126,4 @@ \subsection{Установка и использование}

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

		Более подробно о использовании расширения можно ознакомиться через \href{https://citusdata.github.io/cstore_fdw/}{официальную документацию}.
		Более подробно об использовании расширения можно ознакомиться через \href{https://citusdata.github.io/cstore_fdw/}{официальную документацию}.