le0pard · le0pard · Jan 9, 2019 · Jan 9, 2019
diff --git a/backups/wal_e.tex b/backups/wal_e.tex
@@ -21,7 +21,7 @@ \subsubsection{Установка}
 
 \subsubsection{Настройка и работа}
 
-Как уже писалось, WAL-E сливает все данные в AWS S3, поэтому нам потребуются <<Access Key ID>>, <<Secret Access Key>> и <<AWS Region>> (эти данные можно найти в акаунте Amazon AWS). Команда для загрузки бэкапа всей базы данных в S3:
+Как уже писалось, WAL-E сливает все данные в AWS S3, поэтому нам потребуются <<Access Key ID>>, <<Secret Access Key>> и <<AWS Region>> (эти данные можно найти в аккаунте Amazon AWS). Команда для загрузки бэкапа всей базы данных в S3:
 
 \begin{lstlisting}[language=Bash,label=lst:wal-e3,caption=Загрузка бэкапа всей базы данных в S3]
 AWS_REGION=... AWS_SECRET_ACCESS_KEY=... wal-e                     \

diff --git a/clustering/citus.tex b/clustering/citus.tex
@@ -1,12 +1,12 @@
 \section{Citus}
 \label{sec:citus}
 
-\href{https://www.citusdata.com/}{Citus}~--- горизонтально масштабируемый PostgreSQL кластер. Citus использует механизм расширений PostgreSQL вместо того, что бы использовать модифицированную версию базы (как это делает <<\ref{sec:postgres-x2}~\nameref{sec:postgres-x2}>> или <<\ref{sec:postgres-xl}~\nameref{sec:postgres-xl}>>), что позволяет использовать новые версии PostgreSQL с новыми возможностями, сохраняя при этом совместимость с существующими PostgreSQL инструментами. Кластер предоставляет пользователям результаты запросов в режиме <<реального времени>> для большого и растущего обьема данных (благодаря параллелизации запросов между нодами). Примеры использования:
+\href{https://www.citusdata.com/}{Citus}~--- горизонтально масштабируемый PostgreSQL кластер. Citus использует механизм расширений PostgreSQL вместо того, что бы использовать модифицированную версию базы (как это делает <<\ref{sec:postgres-x2}~\nameref{sec:postgres-x2}>> или <<\ref{sec:postgres-xl}~\nameref{sec:postgres-xl}>>), что позволяет использовать новые версии PostgreSQL с новыми возможностями, сохраняя при этом совместимость с существующими PostgreSQL инструментами. Кластер предоставляет пользователям результаты запросов в режиме <<реального времени>> для большого и растущего объема данных (благодаря параллелизации запросов между нодами). Примеры использования:
 
 \begin{itemize}
   \item аналитика и вывод данных в реальном времени на графики;
   \item хранение большого набора данных для архива и создание отчетов по ним;
-  \item анализ и сегментация большого обьема данных;
+  \item анализ и сегментация большого объема данных;
 \end{itemize}
 
 Нагрузки, которые требуют большой поток данных между узлами кластера, как правило, не будет хорошо работать с Citus кластером. Например:
@@ -60,7 +60,7 @@ \subsection{Распределенные таблицы}
 
 Следующим шагом после выбора столбца на распределения будет определение правильного метода распределения данных в таблицу. В целом, существует два шаблона таблиц: распределенные по времени (время создания заказа, запись логов, прочее) и распределение по идентификатору (ID пользователя, ID приложения, прочее). Citus поддерживает оба метода распределения: append и hash соответственно.
 
-Append метод подходит для таблиц, в которые записываются данные по времени (упорядочены по времени). Такой тип таблиц отлично справляется с запросами, которые использут фильтры с диапазонами значений по распределенному столбцу (\lstinline!BETWEEN x AND y!). Это обьясняется тем, что мастер хранит диапазоны значений, которые хранятся на шардах, и планировщик может эффективно выбирать шарды, которые содержат данные для SQL запроса.
+Append метод подходит для таблиц, в которые записываются данные по времени (упорядочены по времени). Такой тип таблиц отлично справляется с запросами, которые используют фильтры с диапазонами значений по распределенному столбцу (\lstinline!BETWEEN x AND y!). Это объясняется тем, что мастер хранит диапазоны значений, которые хранятся на шардах, и планировщик может эффективно выбирать шарды, которые содержат данные для SQL запроса.
 
 Hash метод распределения подходит для неупорядоченного столбца (user UUID) или по данным, которые могут записываться в любом порядке. В таком случае Citus кластер будет хранить минимальные и максимальные значения для хеш функций на всех шардах. Эта модель лучше подходит для SQL запросов, включающих фильтры на основе равенства по колонке распределения (\lstinline!user_uuid='a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11'!).
 

diff --git a/clustering/greenplum.tex b/clustering/greenplum.tex
@@ -137,7 +137,7 @@ \subsection{Взаимодействие с клиентами}
 # На ETL-сервере:
 bash# for i in {1..1000}; do echo "$i,$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 8 | head -n 1)"; done > /tmp/work/gpfdist_home/test_table.csv
 
-# Теперь создаим внешнюю таблицу и прочитаем данные из файла
+# Теперь создадим внешнюю таблицу и прочитаем данные из файла
 # В Greenplum DB:
 db=# create external table ext_test_table
 db-# (id integer, rand varchar(8))

diff --git a/clustering/postgres_xl.tex b/clustering/postgres_xl.tex
@@ -1,14 +1,14 @@
 \section{Postgres-XL}
 \label{sec:postgres-xl}
 
-Postgres-XL~-- система для создания мульти-мастер кластеров, работающих в синхронном режиме~-- все узлы всегда содержат актуальные данные. Проект построен на основе кодовой базы Postgres-X2, поэтому артитектурный подход полностью идентичен (глобальный менеджер транзакций (GTM), координаторы (coordinators) и обработчики данных (datanodes)). Более подробно про архитектуру можно почитать в <<\ref{sec:postgres-x2-architecture}~\nameref{sec:postgres-x2-architecture}>> разделе. Поэтому рассмотрим только отличие Postgres-X2 и Postgres-XL.
+Postgres-XL~-- система для создания мульти-мастер кластеров, работающих в синхронном режиме~-- все узлы всегда содержат актуальные данные. Проект построен на основе кодовой базы Postgres-X2, поэтому архитектурный подход полностью идентичен (глобальный менеджер транзакций (GTM), координаторы (coordinators) и обработчики данных (datanodes)). Более подробно про архитектуру можно почитать в <<\ref{sec:postgres-x2-architecture}~\nameref{sec:postgres-x2-architecture}>> разделе. Поэтому рассмотрим только отличие Postgres-X2 и Postgres-XL.
 
 
 \subsection{Postgres-X2 и Postgres-XL}
 
 Одно из главных отличий Postgres-XL от Postgres-X2 является улучшенный механизм массово-параллельной архитектуры (massive parallel processing, MPP). Чтобы понять разницу, давайте рассмотрим как Postgres-X2 и Postgres-XL будет обрабатывать разные SQL запросы. Оба этих кластера будут содержать три таблицы \lstinline!T1!, \lstinline!T2! и \lstinline!R1!. \lstinline!T1! имеет колонки \lstinline!a1! и \lstinline!a2!, \lstinline!T2!~--- \lstinline!b1! и \lstinline!b2!. \lstinline!T1! распределена в кластере по \lstinline!a1! полю и \lstinline!T2! распределена по \lstinline!b1! полю. \lstinline!R1! таблица имеет колонки \lstinline!c1! и \lstinline!c2! и реплицируется в кластере (\lstinline!DISTRIBUTE by REPLICATION!).
 
-Для начала, простой запрос вида \lstinline!SELECT * FROM T1! будет паралельно выполняться на нодах как у Postgres-X2, так и у Postgres-XL. Другой пример запроса \lstinline!SELECT * FROM T1 INNER JOIN R1 ON T1.a1 = R1.c1! будет также выполняться паралельно обоими кластерами, потому что будет передан (<<pushed down>>) на обработчики данных (datanodes) для выполнения и координатор (coordinators) будет только агрегировать (собирать) результаты запросов. Это будет работать благодаря тому, что \lstinline!R1! таблица дублицируется на каждом обработчике данных. Этот тип запросов будет работать хорошо, когда \lstinline!T1! является \href{https://en.wikipedia.org/wiki/Fact\_table}{таблицей фактов} (основной таблицей хранилища данных), в то время как \lstinline!R1!~--- \href{https://en.wikipedia.org/wiki/Dimension\_(data\_warehouse)#Dimension\_table}{таблицей измерений} (содержит атрибуты событий, сохраненных в таблице фактов).
+Для начала, простой запрос вида \lstinline!SELECT * FROM T1! будет параллельно выполняться на нодах как у Postgres-X2, так и у Postgres-XL. Другой пример запроса \lstinline!SELECT * FROM T1 INNER JOIN R1 ON T1.a1 = R1.c1! будет также выполняться параллельно обоими кластерами, потому что будет передан (<<pushed down>>) на обработчики данных (datanodes) для выполнения и координатор (coordinators) будет только агрегировать (собирать) результаты запросов. Это будет работать благодаря тому, что \lstinline!R1! таблица дублицируется на каждом обработчике данных. Этот тип запросов будет работать хорошо, когда \lstinline!T1! является \href{https://en.wikipedia.org/wiki/Fact\_table}{таблицей фактов} (основной таблицей хранилища данных), в то время как \lstinline!R1!~--- \href{https://en.wikipedia.org/wiki/Dimension\_(data\_warehouse)#Dimension\_table}{таблицей измерений} (содержит атрибуты событий, сохраненных в таблице фактов).
 
 Теперь рассмотрим другой вариант SQL запроса:
 
@@ -18,9 +18,9 @@ \subsection{Postgres-X2 и Postgres-XL}
 
 Данный запрос делает \lstinline!JOIN! по распределенной колонке \lstinline!a1! в таблице \lstinline!T1! и по НЕ распределенной колонке \lstinline!b2! в таблице \lstinline!T2!. В кластере, который состоит из 4 обработчиков данных, колонка в таблице \lstinline!T1! на первом из них потенциально требуется объединить с колонками таблицы \lstinline!T2! на всех обработчиках данных в кластере.
 
-У Postgres-X2 в данном случае обработчики данных отправляют все данные по заданому условию в запросе к координатору, который и занимается объединением данных с таблиц. В данном примере отсутствует условие \lstinline!WHERE!, что значит, что все обработчики данных отправят все содержимое таблиц \lstinline!T1! и \lstinline!T2! на координатор, который и будет делать \lstinline!JOIN! данных. В данной операции будет отсутствовать паралельное выполнение \lstinline!JOIN! запроса и будут дополнительные накладные расходы на доставку всех данных к координатору. Поэтому в данном случае Postgres-X2 фактически будет медленее, чем выполнение подобного запроса на обычном PostgreSQL сервере (особенно, если таблицы очень большие).
+У Postgres-X2 в данном случае обработчики данных отправляют все данные по заданному условию в запросе к координатору, который и занимается объединением данных с таблиц. В данном примере отсутствует условие \lstinline!WHERE!, что значит, что все обработчики данных отправят все содержимое таблиц \lstinline!T1! и \lstinline!T2! на координатор, который и будет делать \lstinline!JOIN! данных. В данной операции будет отсутствовать параллельное выполнение \lstinline!JOIN! запроса и будут дополнительные накладные расходы на доставку всех данных к координатору. Поэтому в данном случае Postgres-X2 фактически будет медленнее, чем выполнение подобного запроса на обычном PostgreSQL сервере (особенно, если таблицы очень большие).
 
-Postgres-XL будет обрабатывать подобный запрос по-другому. Условие \lstinline!T1.a1 = T2.b2! говорит о том, что мы объединяем колонку \lstinline!b2! с колонкой \lstinline!a1!, которая является ключом распределения для таблицы \lstinline!T1!. Поэтому, выбрав значения поля \lstinline!b2!, кластер будет точно знать для каких обработчиков данных требуется полученый результат для объединения с таблицей \lstinline!T1! (поскольку возможно применить хеш функцию распределения на полученые значения). Поэтому каждый обработчик данных считает с другого обработчика данных требуемые данные по таблице \lstinline!T2! для объединения со своей таблицей \lstinline!T1! без участия координатора. Данная возможность прямой коммуникации обработчиков данных с другими обработчиками данных позволяет распараллеливать более сложные запросы в Postgres-XL.
+Postgres-XL будет обрабатывать подобный запрос по-другому. Условие \lstinline!T1.a1 = T2.b2! говорит о том, что мы объединяем колонку \lstinline!b2! с колонкой \lstinline!a1!, которая является ключом распределения для таблицы \lstinline!T1!. Поэтому, выбрав значения поля \lstinline!b2!, кластер будет точно знать для каких обработчиков данных требуется полученный результат для объединения с таблицей \lstinline!T1! (поскольку возможно применить хеш функцию распределения на полученные значения). Поэтому каждый обработчик данных считает с другого обработчика данных требуемые данные по таблице \lstinline!T2! для объединения со своей таблицей \lstinline!T1! без участия координатора. Данная возможность прямой коммуникации обработчиков данных с другими обработчиками данных позволяет распараллеливать более сложные запросы в Postgres-XL.
 
 Postgres-XL имеет также другие улучшения производительности (более оптимально обрабатываются последовательности, прочее).