Pull to refresh

Comments 30

Забавно. Но фактически архитектура крайне незатейлива во всем, кроме пресловутого 1M строк оптимизатора, о котором рассказано, как о черном ящике ((
Архитектура Shared Nothing, которая в целом описана в статье, и правда не сильно затейлива. Но есть такое выражение — «Дьявол в мелочах». Если рассматривать каждый компонент внимательно, то вокруг него находится множество вопросов, которые закрываются порой интереснейшими решениям. Подробное описание всего займет не одну сотню страниц и явно утомит читателя. Если что-то конкретное интересует больше чем остальное — спрашивайте смело :)
А каким образом реализована поддержка ACID?
Атомарность поддерживается транзакционными механизмаи и журналами. В Терадате существует целый ряд журналов. В частности есть Transient Journal, служащий для того, чтобы обеспечивать возможность отката транзакций. В нем содержится описание состояния затронутых данных до начала операции. И в случае отката транзакции, состояние восстанавливается из него.

Согласованность обеспечивается через обычные check'и перед сообщением об успешном завершении операции.

Изолированность достигается как обычно блокировками разных уровней и уровнями изоляций транзакций. Можно читать как чистые так и грязные данные.

Транзакционность работает в том числе за счет WAL логов, в которые дублируются изменения данных и в ключевые моменты (например, коммиты) лог принудительно скидывается на диск. Так в том числе обеспечивается Надежность.
PE в системе всегда один? Как работают транзакции, если в рамках одной транзакции затрагиваются данные на нескольких нодах хранения?
На узле может быть запущено несколько PE. Приведенная в статье схема — схема узла.
Что касается транзакций, то каждый AMP ведет транзакционный журнал и сохранят в нем before images «своих» строк таблиц.
Как разруливается ситуация, когда с разных PE запускаются 2 транзакции, которые выполняются на нескольких AMP одновременной (одних и тех же), обе транзакции пытаются обновить одни и те же строки? Если одна из них откатывается — как откатываются данные на остальных AMP?

То есть из своего опыта кажется, что транзакции должны быть распределёнными, что-то типа PAXOS или ZAB. Что в Teradata?
2 сессии, вне зависимости от того, с каким узлом они установлены, не могут одновременно модифицировать одни и те же строки. Это обеспечивается механизмом блокировок.

Безусловно, как блокировки, так и транзакции координируются в MPP системе.
То есть всё таки не shared nothing? Можно подробностей про координацию транзакций?
Каждый AMP отвечает за блокировки «своих» строчек данных. Если AMP получил запрос на блокировку одних и тех же данных от двух PE (или даже от двух сессий на одном и том же PE), то эти блокировки ставятся в очередь — на каждом AMPе, независимо друг от друга.

Теперь о координации между AMPами:

PE осуществляет диспетчеризацию плана запроса.

Фиксация транзакций происходит отдельным шагом в конце плана выполнения запроса. Это очень похоже на двух-фазный commit в том смысле, что к этому моменту все AMPы уже готовы сделать commit, и поступает отдельное сообщение от PE к AMPам для фиксации транзакции.

Откат транзакций — также через PE. Если какой-то AMP столкнулся с ошибкой данных, требующей отката транзакции, то он сообщает об этом PE. Далее PE отправляет AMPам сообщение, что нужно откатить транзакцию. Каждый AMP откатывает свои изменения, и снимает блокировки.

Насчет «shared nothing»: выполнение запросов осуществляется параллельно, но выполнение фиксации/отката транзакции требует синхронизации.
А кто в этой схеме разруливает перекрёстные блокировки, ведущие к дедлокам? В варианте с 2 одновременными запросами, блокирующими одни и те же данные на разных AMP, кто следит за тем, что блокировки встанут в очередь в одинаковом порядке?
Локально на AMP-ах обнаружение взаимных блокировок запускается через фиксированные 30-ти секундные интервалы.
Глобальное обнаружение взаимных блокировок запускается на PE через периоды, определенные в настройках (по умолчанию 4 минуты).
При обнаружении взаимной блокировки производится откат “младшей” транзакции.
К словам Евгения также хочу добавить следующее:
«Каждый AMP отвечает за блокировки «своих» строчек данных» — работает в ситуации RowHash Lock, в более тяжелом случае необходима блокировка всей таблицы (Table Lock). В этой ситуации используется техника Pseudo Table Lock: каждой таблице присваивается ответственный за неё AMP, и когда запрос хочет работать с таблицей, PE запрашивает у ответственного AMPа, не занята ли таблица другим.
UFO just landed and posted this here
Да, действительно, на Хабре давно уже никому не нужны технические статьи, а вот скандалы-интриги-расследования всегда в цене, пример всем известного местного сотрудника Тематических Медиа с именем на «а», и его коллег, показывающих то, что скрыто, крайне убедителен.
UFO just landed and posted this here
Мне интересно будет послушаь про статистику и отсутствие хинтов.
Например, есть табличка с миллиардом записей и индексированное поле в ней, содержащее, например, пару тысяч уникальных значений с очень неравномерным распределением по количеству — по некоторым значениям всего пару строк, по другим десятки тысяч и т.д
Как оптимизатор поймет, когда использование индекса будет эффективно, а когда быстрее просмотреть таблицу целиком, если в where есть условие для этого поля?
По индексированным полям собирается статистика. Это гистограммы, показывающие распределение количества строчек по диапазонам значений. Для каждого диапазона фиксируются его границы, общее количество строчек в диапазоне, модальное значение, количество строк на модальное значение, и т.д. Далее для конкретного условия where Оптимизатор смотрит нужный диапазон значений для той константы, которая указана в условии where, и делает оценку количества значений.

В Вашем примере среднее количество строчек на значение равно 500 тыс. (миллиард записей разделить на пару тысяч уникальных значений). Если есть какие-то пиковые значения, то они попадут в модальные значения, и Оптимизатор будет знать об них точную информацию. В остальных случаях, делаются оценки. Понятно, что сильно неравномерное распределение по количеству влияет на точность оценок.

Отсутствие хинтов — это когда пользователи пишут только SQL-запрос. Хинты — это когда пользователи пишут как SQL-запрос, так и план выполнения для него. Как правило, для большинства пользователей первый случай удобнее.

Если какой-то план неоптимален и «хочется написать хинты» — то, как правило, это либо отсутствует статистика, либо устаревшая статистика.

Для указанного выше примера, я бы предложил уточнить постановку задачи — какая таблица рассматривается (проводки, CDRы, ...), есть ли партиционирование (по времени), какая колонка имеет сильно неравномерное распределение по количеству строчек. Для конкретной задачи всегда удобнее найти нужное решение.
А что с устаревшей статистикой?
В MS SQL, например, сталкивался с такой ситуацией — процедура, которая работает в нескольких потоках и активно добавляет записи в таблицу в начале выполнения и очищает таблицу в конце выполнения через некоторое время просто перестает выполняться — статистику «перекашивает», и процедура намертво зависает. Помогает ей только сброс статистики с таблицы.
Возможна ли здесь такая ситуация?
После глобальных изменений данных (изменилось >10% строк) рекомендуется вручную пересобирать статистику. Однако Teradata и сама сможет определить, что статистика устарела, сравнив гистограмму статистики с семплом, взятым с одного AMPа. В этом случае статистика не будет использоваться и оптимизатор будет использовать эвристики.
ребят, никакая статитстика никогда не бывает полной — у оптимизатора нет полной информации о том сколько записей вернёт каждый подзапрос в плане, особенно если критерии отбора достаточно сложные. Из-за этого оптимизатор выбирает неправильный порядок соединений.

Можно написать оптимизатор на 100 млн строк кода, но с этим ничего не сделаешь — до выполнения запроса данных у оптимизатора нет. А разработчик обычно это знает.

Не спорю что в 99% случаев оптимизатор разберётся и без советов разработчика. Но ручками лазить всё равно приходится. Нужны ли обязательно хинты, когда лезешь ручками — обсуждаемо. А так тезис автора напомнил SAP facts: «SAP StreamWork has a fully automated mode that does the business decisions for you»
Вспомнилась старая фраза: есть ложь, есть наглая ложь и есть статистика :)
Задача оптимизатора (и его качество), на мой взгляд, во многом заключается в том, чтобы максимально повысить вероятность (те самые 99%) в которых никуда лазить не надо. А в тех случаях когда приходится лазить, то в Терадате это лечится, так сказать, органически, путем предоставления оптимизатору недостающей информации. И все счастливы :)
«2 копейки» в дополнение: в случае обнаружения устаревшей статистики, эвристика будет использоваться для неиндексированных колонок, для индексированных — статистика, полученная семплированием
Для начала хотел бы поять главное -для каких задач хороша Терадата по сравнению скажем с MS SQL и для каких плоха? И не говорите, что для всех хороша.

ERP?
Система построения отчётов?
Фэйсбукоподобный интернет проект?

А то вы как-то сразу от дирижёров к хэшам и оптимизаторам.

Навскидку (на самом деле ничего не знаю про Терадату) есть подозрение, что это очередная СУБД из 70х с 1% рынка и лицензиями по 100К, хочет получить 1.01% рынка, при помощи обсуждения гик-порно в социальных сетях.
Если кто-то скажет, что Терадата хороша для абсолютно всех задач, то я смело поставлю минус в карму. Терадата это анализ больших объемов данных. Может ли она быть OLTP? Технически — вполне. Но на практике стремления к такому нет. Зачем пытаться завоевывать область, в которой MPP системе по архитектуре сложно конкурировать с транзакционками?
Терадата хороша для быстрой обработки больщущих объемов данных. Залил сотенку терабайт данных и можно крутить и анализировать их как хочешь. Всей конторой. Одновременно. Если петабайт есть, так вообще прекрасно. Узлы в параллель будут пытаться находить и обрабатывать данные.

Терадата это Хранилища Данных. В каком-то из документов на сайте видел фразу «Data warehousing it’s not just something we do – it’s all we do». Кастомная аналитика, отчеты, аналитический CRM, data mining — лишь небольшой список задач, которые хорошо решаются с помощью СУБД Терадата. Фейсбукоподобный интернет проект я бы лично на Терадате делать не стал, и пусть Цукерберг меня осудит если захочет.

Сравнивать с другими СУБД — дело неблагодарное, и холливор начнется, потому что у каждого свои задачи и свои данные. И никто не будет прав или не прав на 100%. Но есть официальные мероприятия называемые benchmark. Это когда в системы разных вендоров заливаются одни и те же данные, готовятся одни и те же запросы. Дальше берется что-нибудь типа jMeter и системы начинают меряться [censored] производительностью. Составляются отчеты, на каких типах запросов какая система показала какие времена откликов, как выбирала данные, как вставляла и т.п. Результаты показываются заказчику, который был заинтересован в дуэли и он делает для себя вывод, какая система подходит лучше именно для его задач и для его данных. Т.к. данные и задачи для benchmark берутся из его среды.
en.wikipedia.org/wiki/Teradata#Customers
Если смотреть с точки зрения бизнес юзера DWH (т.е. аналитика) большой плюс Терадаты в ее оптимайзере — не надо никаких хинтов (как в Оракле) и можно писать джойны на десятки и сотни таблиц. Ну и параллелизм, которого нет в MySQL.
+ что сказано mrz0diak habrahabr.ru/company/teradata/blog/160821/#comment_5548911
В платформах Warehouse Appliance этот компонент(BYNET) может быть реализован софтверно поверх Ethernet. В более серьезных платформах Active Enterprise Data Warehouse это отдельный аппаратный модуль, ибо с такими объемами Ethernet уже не эффективен.
А еще Teradata может его эмулировать для SMP (single node platform) если у нас Teradata Express Edition, ведь сам физический слой и не нужен.
Всё верно. В SMP редакции СУБД как правило не стоит вопрос обеспечения максимальной производительности. И в версиях для виртуальных машин (Teradata Virtual Machine Edition) так же физический слой не нужен, реализация исключительно на уровне ПО.
mrz0diak О тред еще живой. У меня вопрос, я вот пишу диплом на тему оптимизации запросов в Teradata, насколько то, что я проверю на Teradata`e express edition, поднятой очевидно на виртуалке, будет соответствовать реальности, ведь там будет только два AMP`a? Включая, но не ограничиваясь влиянием индексов на распределение данных и времени запросов.
Скажем так: отличаться будет. Первое что приходит в голову — оптимизатор принимает те или иные решения в т.ч. основываясь на статистике по количествую записей и их объему. Поэтому при тех же параметрах физ. модели (PI, SI, партиции и пр.) но при совершенно другом объеме данных и решения оптимизатора могут быть другими. Плюс на Express Edition не будет учтено влияние таких вещей как Teradata Intelligent Memory, Teradata Virtual Storage, которые есть на аппартно-программной версии Teradata.
Так что в принципе отличия будут, но на мой взгляд не критичные в рамках дипломной работы.
Sign up to leave a comment.