Пакетная загрузка данных производительнее построчной и это справедливо для многих СУБД, Teradata не исключение, ибо именно на обработку больших массивов данных и ориентирована.
Приветствуя использование пакетной загрузки для большого объема данных, тем не менее хотел бы отметить некоторые моменты, которые могут повысить производительность атомарных DML операций. Как автор справедливо отметил в начале статьи, Teradata — массивно параллельная система и этот параллелизм должен учитываться, в том числе в физическом дизайне. Например, разумный выбор первичного индекса таблицы позволяет эффективно распараллеливать операции вставки данных. К сожалению, в статье нет описания структур объектов базы данных и результатов тестирования.
Еще один способ оптимизации атомарных DML операций — использование макросов. Этот подход применяется утилитой TPUMP. Повышение производительности обусловлено кешированием планов запросов макросов и, в случае с TPUMP, — обязательным использованием DML операцией первичного индекса таблицы.
Спасибо за интересную статью.
У меня возникла пара вопросов:
1. Как Vertica оптимизирует загрузку данных из HDFS с учетом, например, различий в размерах кластеров Vertica и Hadoop, чем определяется количество сессий загрузки?
2. Почему не возможен быстрый доступ по ключу без JDBC Key-Value API?
Платформа Teradata масштабируется узлами, что ведет к увеличению числа AMPов в системе.
При наращивании системы, часть данных со «старых» AMPов мигрирует на «новые», миграции данных между «старыми» AMPами нет.
Процесс масштабирования системы автоматизирован.
При создании NoPI таблицы каждая строка тоже получает уникальный идентификатор размером 64 бита, состоящий из hash bucket (16 или 20 бит) и uniqueness value (остальные биты), размерность которого увеличена, так как большое количество строк на одном AMPе будет иметь одинаковое значение hash bucket.
Если я правильно понял смысл второго вопроса, то он следующий: «будет ли создан PI для таблицы, DDL команда создания которой не содержит явного указания на создание первичного индекса –… PRIMARY INDEX …».
Ответ такой:
Если в команде создания таблицы указан PRIMARY KEY, то по его колонкам создается UPI (Unique Primary Index)
иначе
если указаны колоночные ограничения UNIQUE, то по колонке ПЕРВОГО ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
если указаны табличные ограничения UNIQUE, то по колонкам ПЕРВОГО табличного ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
по первой колонке таблицы создается неуникальный первичный индекс (NUPI)*.
* зависит от настроек системы. При значении параметра «Primary Index Default» равном “N”, отсутствии явного определения PI и уникальных ограничений уровня колонки или таблицы в команде создания таблицы, Teradata создаст NoPI таблицу.
Разве приведенная вами цитата противоречит тому, что я написал? AMP — виртуальный процессор, а не узел.
Та статья, ссылку на которую я привел, и цитату из которой вы использовали, как раз и является вводной и описывает отличительные особенности СУБД Teradata.
В ней также есть следующие предложения: «Мы планируем подготовить небольшую серию статей о самых интересных, на наш взгляд, технических особенностях СУБД и работы с ней. Если у вас есть опыт работы с Teradata или в вашей компании используется наша платформа и у вас есть вопросы – подкидывайте их, и мы либо ответим на них в комментариях, либо подготовим соответствующую полноценную статью.».
Поправлять и дополнять я не стал сознательно, дабы не переписывать уже написанное и не обсуждать обсужденное в блоге Teradata.
Также мы по мере возможностей стараемся оправдывать ожидания наших подписчиков и на днях опубликуем статью об основных принципах физического дизайна для СУБД Teradata.
Однако хочу заметить, что:
— мысль, высказанная в предисловии, конфликтует с указанием в статье ссылок на русскоязычные ресурсы, включая блог компании Teradata.
— в статье присутствуют неточности. Для примера: «Основное понятие в архитектуре Teradata Database — это AMP (Access Module Processor), отдельная нода/узел, содержащая и самостоятельно обрабатывающая свои данные». В действительности AMP — виртуальный процессор, управляющий ассоциированным с ним объемом дискового пространства. Для ознакомления с основами Teradata могу порекомендовать статью habrahabr.ru/company/teradata/blog/160821/ в блоге компании (там же можно задать интересующие вопросы).
— в блоге компании Teradata (http://habrahabr.ru/company/teradata/blog/) есть ряд технических статей, написанных специалистами компании, обладающими бОльшими знаниями платформы и СУБД Teradata и готовыми ответить на возникающие вопросы.
«2 копейки» в дополнение: в случае обнаружения устаревшей статистики, эвристика будет использоваться для неиндексированных колонок, для индексированных — статистика, полученная семплированием
Локально на AMP-ах обнаружение взаимных блокировок запускается через фиксированные 30-ти секундные интервалы.
Глобальное обнаружение взаимных блокировок запускается на PE через периоды, определенные в настройках (по умолчанию 4 минуты).
При обнаружении взаимной блокировки производится откат “младшей” транзакции.
Каждый AMP отвечает за блокировки «своих» строчек данных. Если AMP получил запрос на блокировку одних и тех же данных от двух PE (или даже от двух сессий на одном и том же PE), то эти блокировки ставятся в очередь — на каждом AMPе, независимо друг от друга.
Теперь о координации между AMPами:
PE осуществляет диспетчеризацию плана запроса.
Фиксация транзакций происходит отдельным шагом в конце плана выполнения запроса. Это очень похоже на двух-фазный commit в том смысле, что к этому моменту все AMPы уже готовы сделать commit, и поступает отдельное сообщение от PE к AMPам для фиксации транзакции.
Откат транзакций — также через PE. Если какой-то AMP столкнулся с ошибкой данных, требующей отката транзакции, то он сообщает об этом PE. Далее PE отправляет AMPам сообщение, что нужно откатить транзакцию. Каждый AMP откатывает свои изменения, и снимает блокировки.
Насчет «shared nothing»: выполнение запросов осуществляется параллельно, но выполнение фиксации/отката транзакции требует синхронизации.
2 сессии, вне зависимости от того, с каким узлом они установлены, не могут одновременно модифицировать одни и те же строки. Это обеспечивается механизмом блокировок.
Безусловно, как блокировки, так и транзакции координируются в MPP системе.
На узле может быть запущено несколько PE. Приведенная в статье схема — схема узла.
Что касается транзакций, то каждый AMP ведет транзакционный журнал и сохранят в нем before images «своих» строк таблиц.
Приветствуя использование пакетной загрузки для большого объема данных, тем не менее хотел бы отметить некоторые моменты, которые могут повысить производительность атомарных DML операций. Как автор справедливо отметил в начале статьи, Teradata — массивно параллельная система и этот параллелизм должен учитываться, в том числе в физическом дизайне. Например, разумный выбор первичного индекса таблицы позволяет эффективно распараллеливать операции вставки данных. К сожалению, в статье нет описания структур объектов базы данных и результатов тестирования.
Еще один способ оптимизации атомарных DML операций — использование макросов. Этот подход применяется утилитой TPUMP. Повышение производительности обусловлено кешированием планов запросов макросов и, в случае с TPUMP, — обязательным использованием DML операцией первичного индекса таблицы.
У меня возникла пара вопросов:
1. Как Vertica оптимизирует загрузку данных из HDFS с учетом, например, различий в размерах кластеров Vertica и Hadoop, чем определяется количество сессий загрузки?
2. Почему не возможен быстрый доступ по ключу без JDBC Key-Value API?
При наращивании системы, часть данных со «старых» AMPов мигрирует на «новые», миграции данных между «старыми» AMPами нет.
Процесс масштабирования системы автоматизирован.
Если я правильно понял смысл второго вопроса, то он следующий: «будет ли создан PI для таблицы, DDL команда создания которой не содержит явного указания на создание первичного индекса –… PRIMARY INDEX …».
Ответ такой:
Если в команде создания таблицы указан PRIMARY KEY, то по его колонкам создается UPI (Unique Primary Index)
иначе
если указаны колоночные ограничения UNIQUE, то по колонке ПЕРВОГО ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
если указаны табличные ограничения UNIQUE, то по колонкам ПЕРВОГО табличного ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
по первой колонке таблицы создается неуникальный первичный индекс (NUPI)*.
* зависит от настроек системы. При значении параметра «Primary Index Default» равном “N”, отсутствии явного определения PI и уникальных ограничений уровня колонки или таблицы в команде создания таблицы, Teradata создаст NoPI таблицу.
Та статья, ссылку на которую я привел, и цитату из которой вы использовали, как раз и является вводной и описывает отличительные особенности СУБД Teradata.
В ней также есть следующие предложения: «Мы планируем подготовить небольшую серию статей о самых интересных, на наш взгляд, технических особенностях СУБД и работы с ней. Если у вас есть опыт работы с Teradata или в вашей компании используется наша платформа и у вас есть вопросы – подкидывайте их, и мы либо ответим на них в комментариях, либо подготовим соответствующую полноценную статью.».
Также мы по мере возможностей стараемся оправдывать ожидания наших подписчиков и на днях опубликуем статью об основных принципах физического дизайна для СУБД Teradata.
Однако хочу заметить, что:
— мысль, высказанная в предисловии, конфликтует с указанием в статье ссылок на русскоязычные ресурсы, включая блог компании Teradata.
— в статье присутствуют неточности. Для примера: «Основное понятие в архитектуре Teradata Database — это AMP (Access Module Processor), отдельная нода/узел, содержащая и самостоятельно обрабатывающая свои данные». В действительности AMP — виртуальный процессор, управляющий ассоциированным с ним объемом дискового пространства. Для ознакомления с основами Teradata могу порекомендовать статью habrahabr.ru/company/teradata/blog/160821/ в блоге компании (там же можно задать интересующие вопросы).
— в блоге компании Teradata (http://habrahabr.ru/company/teradata/blog/) есть ряд технических статей, написанных специалистами компании, обладающими бОльшими знаниями платформы и СУБД Teradata и готовыми ответить на возникающие вопросы.
Глобальное обнаружение взаимных блокировок запускается на PE через периоды, определенные в настройках (по умолчанию 4 минуты).
При обнаружении взаимной блокировки производится откат “младшей” транзакции.
Теперь о координации между AMPами:
PE осуществляет диспетчеризацию плана запроса.
Фиксация транзакций происходит отдельным шагом в конце плана выполнения запроса. Это очень похоже на двух-фазный commit в том смысле, что к этому моменту все AMPы уже готовы сделать commit, и поступает отдельное сообщение от PE к AMPам для фиксации транзакции.
Откат транзакций — также через PE. Если какой-то AMP столкнулся с ошибкой данных, требующей отката транзакции, то он сообщает об этом PE. Далее PE отправляет AMPам сообщение, что нужно откатить транзакцию. Каждый AMP откатывает свои изменения, и снимает блокировки.
Насчет «shared nothing»: выполнение запросов осуществляется параллельно, но выполнение фиксации/отката транзакции требует синхронизации.
Безусловно, как блокировки, так и транзакции координируются в MPP системе.
Что касается транзакций, то каждый AMP ведет транзакционный журнал и сохранят в нем before images «своих» строк таблиц.