Merge pull request #39 from olshevskiy87/t6_clustering_2

fix typos in clustering chapter, postgres_xl

Author: le0pard

clustering/postgres_xl.tex

@@ -8,24 +8,24 @@ \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 запроса:
 
 \begin{lstlisting}[language=SQL,label=lst:postgres-xl1,caption=Запрос на распределенные таблицы]
 # SELECT * FROM T1 INNER JOIN T2 ON T1.a1 = T2.b2
 \end{lstlisting}
 
-Данный запрос делает \lstinline!JOIN! по распределенной колонке \lstinline!a1! в таблице \lstinline!T1! и по НЕ распределенной колонке \lstinline!b2! в таблице \lstinline!T2!. В кластере, который состоит из 4 обработчиков данных, колонка в таблице \lstinline!T1! на первом из них потенциально требуется объеденить с колонками таблицы \lstinline!T2! на всех обработчиках данных в кластере.
+Данный запрос делает \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 имеет также другие улучшения производительности (более оптимально обрабатываются последовательности, прочее).
 
 
 \subsection{Заключение}
 
-Postgres-XL еще одно перспективное решение для создание кластера на основе Postgres-X2. Разработчики данного решения больше нацелены на улучшение производительности и стабильности кластера, вместо добавления нового функционала.
+Postgres-XL - еще одно перспективное решение для создания кластера на основе Postgres-X2. Разработчики данного решения больше нацелены на улучшение производительности и стабильности кластера, вместо добавления нового функционала.