Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472

тогда скажем так... наихудшую производительность кластер на оракле
показывает на массовых апдейтах..


Posted via ActualForum NNTP Server 1.3

9 окт 06, 18:27    [3238814]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Ноготок Ландышевич
Guest
ScareCrow
тогда скажем так... наихудшую производительность кластер на оракле
показывает на массовых апдейтах..
Чушь полнейшая, ибо
andrey_anonymous
Господа, ну нельзя говорить такие вещи "вообще", без привязки к конкретной системе и ситуации
9 окт 06, 18:58    [3238921]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Ноготок Ландышевич


Теперь уже цветочный бизнес ?

ps. а в остальном поддерживаю
10 окт 06, 13:13    [3241438]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Андрей Прохоров
Зл0й
Например Teradata умеет ну очень быстро делать full table scan - "все в параллель". Зато если построить join так что узлы начнут активно слать друг другу данные по Bynet'у то при достаточном этого траффика Teradata "заткнется". Оракл "заткнется" как только все узлы начнут активно лезть в одни и те же данные, блокировать их итп., диск-то общий. "Чудес на свете не бывает".

На самом деле наоборот. На сложных join-ах Oracle отваливается гораздо быстрее, а вот механизм блокировок у него более развит и здесь возможностей заткнутся у него гораздо меньше чем у Teradat-ы.


Для начала Терадата: Все очень просто. Предположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27. Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet. Ведь они же раскиданы по amp'ам исходя из хеширования по column_b1. Теперь предположим что обе таблицы по 200 миллионов записей, чтобы жизнь медом не казалась. Все. Приплыли.

С ораклом все еще проще, база данных (т.е. то что на диске) одна, совместно используемая различными узлами. Когда идет чтение - проблем не вижу так как оно в Оракле не блокирующее, хотя успешность его не гарантируется. Что касается update в Хранилищах данных, то я лично делаю вот как:
- строю отдельный staging tablespace куда кладу все staging tables
- ETL гоняю на одном узле, он "упирается" все равно в i/o а не CPU или RAM, много узлов там не поможет
- когда staging закончен делаю insert в специальную таблицу которая лежит в fact tablespace.
- потом делаю из нее exchange partition в fact table

Все работает "на ура", "мухой", "на раз". Так что в ХД кроме как возможности быстро делать full table scan я не вижу радикальных преимуществ терадэйты над Ораклом. В OLTP же терадэйту почти не применяют, ее механизм блокировок далек от совершенства.
10 окт 06, 21:27    [3244395]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Мимо ходил
Guest
Зл0й
Для начала Терадата: Все очень просто. Предположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27. Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet. Ведь они же раскиданы по amp'ам исходя из хеширования по column_b1. Теперь предположим что обе таблицы по 200 миллионов записей, чтобы жизнь медом не казалась. Все. Приплыли.


Хм, а "Приплыли" что означает? Будет выбрана стратегия реализации join (в данном случае скорее всего будет merge join, через redistribute), узким местом которой является суммарное IO узлов (у терадаты все стратегии join кроме одной упираются в IO узлов). То есть, при добавлении узлов скорость выполнения запроса будет расти линейно, от кол-ва узлов. Для не индексированных таблиц. Ну это у всех так, в том числе наверное и у Oracle, в случае shared-nothing конфигураций. Где же затык терадаты?
10 окт 06, 23:06    [3244549]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Мимо ходил

Хм, а "Приплыли" что означает? Будет выбрана стратегия реализации join (в данном случае скорее всего будет merge join, через redistribute), узким местом которой является суммарное IO узлов (у терадаты все стратегии join кроме одной упираются в IO узлов). То есть, при добавлении узлов скорость выполнения запроса будет расти линейно, от кол-ва узлов. Для не индексированных таблиц. Ну это у всех так, в том числе наверное и у Oracle, в случае shared-nothing конфигураций. Где же затык терадаты?


Когда все узлы начинают дружно слать друг другу по Bynet'у записи то затык происходит в пропускной способности Bynet'а, которая безусловно велика но небезгранична. Суммарная пропускная способность узлов по IO выше на порядок чем Bynet'а собственно (120MB per second per node bandwidth). Предположим узлов 40, на каждом из них висит NCR'овский сказевый дисковый массив. Какова их суммарная пропускная способность по IO 40 SCSI каналов?

Насчет линейно растущей скорости это вы в рекламном проспекте NCR прочитали? Она линейно растет только в случае AMP-local join. Teradata вообще-то не единственная СУБД MPP-архитектуры. У них у всех при Table Redistribution происходит утыкание в пропускную способность интерконнекта.

Shared-nothing конфигурация Оракла - для меня нечто новое. Ни разу не видел. Я даже сомневаюсь что Оракл сам по себе поддерживает такую конфигурацию. С помощью "надстройки" над ним наверное shared-nothing сделать можно, как и с любой СУБД. Вот DB2 EEE, Informix XPS и Tandem такую конфигурацию поддерживают, это точно.
11 окт 06, 00:10    [3244654]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Мимо ходил
Guest
Зл0й
Когда все узлы начинают дружно слать друг другу по Bynet'у записи то затык происходит в пропускной способности Bynet'а, которая безусловно велика но небезгранична. Суммарная пропускная способность узлов по IO выше на порядок чем Bynet'а собственно (120MB per second per node bandwidth). Предположим узлов 40, на каждом из них висит NCR'овский сказевый дисковый массив. Какова их суммарная пропускная способность по IO 40 SCSI каналов?

Насчет линейно растущей скорости это вы в рекламном проспекте NCR прочитали? Она линейно растет только в случае AMP-local join. Teradata вообще-то не единственная СУБД MPP-архитектуры. У них у всех при Table Redistribution происходит утыкание в пропускную способность интерконнекта.

Shared-nothing конфигурация Оракла - для меня нечто новое. Ни разу не видел. Я даже сомневаюсь что Оракл сам по себе поддерживает такую конфигурацию. С помощью "надстройки" над ним наверное shared-nothing сделать можно, как и с любой СУБД. Вот DB2 EEE, Informix XPS и Tandem такую конфигурацию поддерживают, это точно.


Коллега, я не продавец (продавец тут уже выступал) и знаю о чем говорю - работаю с этим каждый день. Всё это оффтоп, так что пишу последнее сообщение в этой ветке.

1) Пропускная способность Bynet в актуальной версии - 180Mb в секунду на узел. Если рассмотреть Ваш пример на двухузловой системе, каждый узел может разослать не больше 100 млн. записей, а на самом деле меньше (только чужие строки). Если предположить что разослать нужно 70млн, размер строки 100 байт с overhead то нужно разослать 7Гб. 40 секунд. Читать он их будет дольше, и не нужно ссылаться на показатели интерфейсов, блоки со строками в терадате рассыпаны в случайном порядке, это не потоковое видео.
Хотя конечно можно сконфигурировать такую систему что она заткнет байнет. Именно для этого конфигурациями занимаются люди из терадаты.

2) Даже если предположить что в качестве среды передачи данных для Bynet будет использоваться 10Mbit/s Ethernet система будет масштабироваться линейно. Если вдвое увеличить систему то на каждый амп и узел данных будет приходится вдвое меньше, и чтобы их переслать времени нужно вдвое меньше (вспомните, что байнет это иерархическая топология и она не заткнется, как общая шина, просто от кол-ва пакетов). Отсюда и масштабируемость на таких задачах, свойственная shared-nothing.

3) В документации по Oracle написано что RAC работает на shared nothing: Data Warehousing Guide 10g Release 1 (10.1)
Page 5-28
11 окт 06, 09:47    [3245339]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
Зл0й
Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet.

Коллега, Вы не понимаете как работает join в Teradat-е, поэтому делаете ошибочные выводы.
11 окт 06, 09:52    [3245366]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Андрей Прохоров
Зл0й
Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet.

Коллега, Вы не понимаете как работает join в Teradat-е, поэтому делаете ошибочные выводы.


Это не я не понимаю, это создатели FAQ на сайте teradata.com наверное не понимают как в ней join реализован:

FAQ

During spool redistributions to different AMPs (merge joins where primary indices are different), some records come to the same AMP after rehashing on the basis of join columns. Do they really go to the BYNET or message-passing layer for rehashing, or are these records directly spooled locally?

A1:
When rows are redistributed during join processing, there is a same-node optimization that is done by the message system. ...


То есть если primary indices are different то происходит-таки redistribution. Оно и понятно, если мы раскидали одну таблицу по узлам исходя из hash(employee_id) а другую по hash(some_other_id) а join делаем по social_security_number то записи с однаковым social_security_number из этих двух таблиц будут на разных узлах лежать, и слать их придется по байнету. Или я опять не понимаю что-то?
11 окт 06, 19:59    [3249961]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Мимо ходил

1) Пропускная способность Bynet в актуальной версии - 180Mb в секунду на узел. Если рассмотреть Ваш пример на двухузловой системе, каждый узел может разослать не больше 100 млн. записей, а на самом деле меньше (только чужие строки). Если предположить что разослать нужно 70млн, размер строки 100 байт с overhead то нужно разослать 7Гб. 40 секунд. Читать он их будет дольше, и не нужно ссылаться на показатели интерфейсов, блоки со строками в терадате рассыпаны в случайном порядке, это не потоковое видео.
Хотя конечно можно сконфигурировать такую систему что она заткнет байнет. Именно для этого конфигурациями занимаются люди из терадаты.

То есть они специально ограничивают пропускную способность диска, чтобы байнет не "заткнулся". Соответственно ограничителем по масштабируемости MPP (shared-nothing) архитектуры является-таки интерконнект, хоть и не напрямую а косвенно. Если бы не "узкое место" (читай-байнет) можно было бы себе позволить i/o поблатнее. В этом ИМХО и заключается основной "косяк" данной архитектуры. В свое время Sun Microsystems не стал заниматся этой архитектурой как бесперспективной именно из-за этого "косяка".
11 окт 06, 20:29    [3250043]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
Зл0й
То есть если primary indices are different то происходит-таки redistribution. Оно и понятно, если мы раскидали одну таблицу по узлам исходя из hash(employee_id) а другую по hash(some_other_id) а join делаем по social_security_number то записи с однаковым social_security_number из этих двух таблиц будут на разных узлах лежать, и слать их придется по байнету. Или я опять не понимаю что-то?

Теперь, все правильно и это вовсе не
Зл0й
... amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet.

А теперь, раcскажите, как и сколько времени Oracle будет выполнять такой join.
11 окт 06, 21:40    [3250158]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Андрей Прохоров
Зл0й
... amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet.

А теперь, раcскажите, как и сколько времени Oracle будет выполнять такой join.

oracle поступит много проще - каждая из нодов, занимающихся обработкой запроса, будет читать свои данные прямо из стораджа и проводить соединение одним из трех базовых методов.
При этом если обнаружится пересечение по блокам данных (словари), то каждый узел будет располагать собствеными копиями блоков и мешать соседям не будет.
Поскольку dml-активность в сценарии не предполагается, то трафик interconnect будет очень мал и производительность соединения будет определяться только возможностями подсистемы вода-вывода.
11 окт 06, 23:40    [3250452]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
andrey_anonymous
oracle поступит много проще - каждая из нодов, занимающихся обработкой запроса, будет читать свои данные прямо из стораджа и проводить соединение одним из трех базовых методов.

Каким образом данные станут "своими" для узлов если не используется partitioning?
На сколько я помню документацию, чтобы добиться сбаланисрованной нагрузки на ноды нужно чтобы:
- количество партиций было кратно количесту узлов
- партции должны быть примерно одинакового размера
А что будет, если join придется делать не по тем полям, по которым сделан partitioning?
andrey_anonymous
При этом если обнаружится пересечение по блокам данных (словари), то каждый узел будет располагать собствеными копиями блоков и мешать соседям не будет.

Копиями таблицы в 200 млн. записей?
andrey_anonymous
Поскольку dml-активность в сценарии не предполагается, то трафик interconnect будет очень мал и производительность соединения будет определяться только возможностями подсистемы вода-вывода.

Ну да?! А процессоры отдыхают при join-е без индекса?
12 окт 06, 01:37    [3250638]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Андрей Прохоров
andrey_anonymous
oracle поступит много проще

Каким образом данные станут "своими" для узлов если не используется partitioning?
Почему не используется partitioning? Мне казалось, обсуждаются равноценные инсталляции. А то ведь можно для пущей достоверности теста потребовать запустить оракеля на калькуляторах и удесятерить объем данных...
Андрей Прохоров
На сколько я помню документацию, чтобы добиться сбаланисрованной нагрузки на ноды нужно чтобы:
- количество партиций было кратно количесту узлов
- партции должны быть примерно одинакового размера
И что из этого следует? Может быть, в архитектуре share nothing эти правила не имеют значения?
Андрей Прохоров
А что будет, если join придется делать не по тем полям, по которым сделан partitioning?
Тоже что и в терадате, только интерконнект перегружать не потребуется - диски-то общие...
Андрей Прохоров
andrey_anonymous
При этом если обнаружится пересечение по блокам данных (словари), то каждый узел будет располагать собствеными копиями блоков и мешать соседям не будет.

Копиями таблицы в 200 млн. записей?
????? С чего Вы это взяли?
Андрей Прохоров
andrey_anonymous
Поскольку dml-активность в сценарии не предполагается, то трафик interconnect будет очень мал и производительность соединения будет определяться только возможностями подсистемы вода-вывода.
Ну да?! А процессоры отдыхают при join-е без индекса?

Вообще говоря, ДА. Некоторую нагрузку можно наблюдать в случае HASH JOIN, но лимитирует все-таки IO.
12 окт 06, 01:55    [3250648]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
andrey_anonymous
Почему не используется partitioning?
...
Может быть, в архитектуре share nothing эти правила не имеют значения?

Да, коллега, shared nothing может работать по совсем по другим принципам. Partitioning в Teradata не имеет никакого отношения к распределению данных между узлами и к паралельной обработке. И есть способы join-а гораздо более эффективные, чем HASH JOIN (который к стати используется при объединении короткой и длинной таблицы, а не двух длинных)
Поэтому Зл0й привел пример, в котором Oracle находится в заведомо проигрышной ситуации.
И лучше избегать утвеждений
andrey_anonymous
Тоже что и в терадате
, пока не познакомились с новой архитектурой.
12 окт 06, 09:18    [3250979]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Андрей Прохоров
andrey_anonymous
Почему не используется partitioning?
...
Может быть, в архитектуре share nothing эти правила не имеют значения?

Да, коллега, shared nothing может работать по совсем по другим принципам.


Скажите пожалуйста, какой же "принцип" в share nothing:
- Позводит данным, которыми заведует узел N1, соединиться с данными, находящимися на узле N2, минуя узел N1 и кластерный interconnect
- Позволит равномерно загрузить узлы, если данные по этим узлам распределены неравномерно

А какой метод соединения, отсутствующий в oracle, может предложить teradata для соединения двух длинных неиндексированных таблиц? Буду признателен за конкретную ссылку.

Насчет hash join в oracle Вы таки заблуждаетесь, коллега.
12 окт 06, 10:33    [3251423]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Oleg Ivanov
Member

Откуда: Киев
Сообщений: 289
andrey_anonymous
oracle поступит много проще - каждая из нодов, занимающихся обработкой запроса, будет читать свои данные прямо из стораджа и проводить соединение одним из трех базовых методов.
На сколько я понимаю архитектуру РАКа, Oracle НЕ МОЖЕТ задействовать для выполнения ОДНОГО запроса НЕСКОЛЬКО узлов. Я не прав?

andrey_anonymous
Скажите пожалуйста, какой же "принцип" в share nothing:
- Позводит данным, которыми заведует узел N1, соединиться с данными, находящимися на узле N2, минуя узел N1 и кластерный interconnect
Объединять можно только строки, расположенные на одном узле.
Ключевая идея в том, что и перераспределение, и объединение будут выполнятся параллельно всеми узлами.

andrey_anonymous
Андрей Прохоров
Ну да?! А процессоры отдыхают при join-е без индекса?
Вообще говоря, ДА. Некоторую нагрузку можно наблюдать в случае HASH JOIN, но лимитирует все-таки IO
А сортировки при Merge Join не требуют CPU? Не уверен, что затык всегда в IO.
А кроме джойнов бывают еще агрегации и сортировки, которые требуют "много" CPU.
Терадата выполняет агрегацию и сортировку параллельно всеми узлами, при чем сортировка никогда не требует перераспределения данных.
12 окт 06, 13:41    [3253086]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
DimaR
Member

Откуда:
Сообщений: 1570
[quot Oleg IvanovНа сколько я понимаю архитектуру РАКа, Oracle НЕ МОЖЕТ задействовать для выполнения ОДНОГО запроса НЕСКОЛЬКО узлов. Я не прав?[/quot]
Неправ

https://www.sql.ru/forum/actualthread.aspx?bid=26&tid=157336&pg=3&hl=teradata+oracle#1329317

вот в этом топике уже обсуждалось teradata и oracle
12 окт 06, 13:53    [3253185]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Yo.!!
Guest
Oleg Ivanov
На сколько я понимаю архитектуру РАКа, Oracle НЕ МОЖЕТ задействовать для выполнения ОДНОГО запроса НЕСКОЛЬКО узлов. Я не прав?

конечно может, если оптимизатор решит, что ганять данные по интерконекту быстрей чем обработать самому запрос распараллелится. но в реальной жизни оптимизатор как я понимаю так не решает, т.к. это невыгодно.

http://www.oracle.com/technology/pub/articles/conlon_rac.html
12 окт 06, 13:55    [3253194]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Oleg Ivanov
andrey_anonymous
oracle поступит много проще - каждая из нодов, занимающихся обработкой запроса, будет читать свои данные прямо из стораджа и проводить соединение одним из трех базовых методов.
На сколько я понимаю архитектуру РАКа, Oracle НЕ МОЖЕТ задействовать для выполнения ОДНОГО запроса НЕСКОЛЬКО узлов. Я не прав?
Нет, не правы.
Oleg Ivanov
andrey_anonymous
Скажите пожалуйста, какой же "принцип" в share nothing:
- Позводит данным, которыми заведует узел N1, соединиться с данными, находящимися на узле N2, минуя узел N1 и кластерный interconnect
Объединять можно только строки, расположенные на одном узле.
Ключевая идея в том, что и перераспределение, и объединение будут выполнятся параллельно всеми узлами.
Oracle умеет ровно то же самое. Partition-wise join называется.
Oleg Ivanov
andrey_anonymous
Андрей Прохоров
Ну да?! А процессоры отдыхают при join-е без индекса?
Вообще говоря, ДА. Некоторую нагрузку можно наблюдать в случае HASH JOIN, но лимитирует все-таки IO
А сортировки при Merge Join не требуют CPU? Не уверен, что затык всегда в IO.
А кроме джойнов бывают еще агрегации и сортировки, которые требуют "много" CPU.
Сортировки требуют, агрегация - далеко не всякая.
Oleg Ivanov

Терадата выполняет агрегацию и сортировку параллельно всеми узлами, при чем сортировка никогда не требует перераспределения данных.

"Никогда не говори никогда" (с).
Полагаю, не составит труда предложить такой order by, который потребует распределения данных.
Про распараллеливание я уже говорил - oracle умеет в том числе межнодовый параллелизм.
12 окт 06, 13:59    [3253225]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Oleg Ivanov
Member

Откуда: Киев
Сообщений: 289
andrey_anonymous
Полагаю, не составит труда предложить такой order by, который потребует распределения данных.
Думаю, составит :-)
Сортировка всегда выполняется локально, на AMP. Окончательный MERGE производит ByNET в процессе передачи данных клиенту. Так сказать, преимущество программно-аппаратной реализаци.

andrey_anonymous
Oracle умеет ровно то же самое. Partition-wise join называется.
Я думал мы говорим о случае когда объединение происходит НЕ по ключам партиционирования...
Если объединять по ключам партиционирования — Oracle может выполнять Partition-wise join, а Teradata локальный джоин без перераспределения.
Partial Partition-wise Join в Oracle, ИМХО, хорош для объединения "большой" партиционированной таблицы с "маленькой". В таком случае Teradata просто копирует "маленькую" на все узлы, т.е. перераспределения "большой" не происходит.

За ссылки по RAC — спасибо. Я раньше считал, что параллельные процессы, порожденные одной сессией, могут быть только в пределах одного узла.
12 окт 06, 14:26    [3253417]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Oleg Ivanov
andrey_anonymous
Полагаю, не составит труда предложить такой order by, который потребует распределения данных.
Думаю, составит :-)
Сортировка всегда выполняется локально, на AMP.
т.е. это частичная сортировка
Oleg Ivanov
Окончательный MERGE производит ByNET в процессе передачи данных клиенту.
То есть окончательная сортировка требует как перераспределения данных, так и ресурсов на их обработку, что и требовалось доказать ;)
Oleg Ivanov
andrey_anonymous
Oracle умеет ровно то же самое. Partition-wise join называется.
Я думал мы говорим о случае когда объединение происходит НЕ по ключам партиционирования...
Тогда не понял пассажа про локальные соединения в терадата, не требующие перераспределения данных.
Oleg Ivanov
Если объединять по ключам партиционирования — Oracle может выполнять Partition-wise join, а Teradata локальный джоин без перераспределения.
Partial Partition-wise Join в Oracle, ИМХО, хорош для объединения "большой" партиционированной таблицы с "маленькой".
????? нет, его основное предназначение - независимое соединение совпадающих разделов, если оно возможно. "Маленькие" и "большие" таблицы тут совершенно ни при чем.
Oleg Ivanov
В таком случае Teradata просто копирует "маленькую" на все узлы, т.е. перераспределения "большой" не происходит.
Ораклу даже копировать не придется, каждый узел просто прочитает "меленькую" в собственный buffer cache :)
12 окт 06, 14:35    [3253487]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Мимо ходил
Guest
Не удержался: коллеги работающие с Oracle, вопрос был как (какой тип join, как разводится по узлам) и сколько времени в этой СУБД будет выполнятся следующий join:
Зл0й
Для начала Терадата: Все очень просто. Предположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27.

То есть, по column_a1 и column_b1 сделан hash-partitioning (первичный индекс в терадате это первичный метод доступа). Join по условию column_a1=column_b27. Индексов нет, таблицы по 200mln rows.
12 окт 06, 14:58    [3253725]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Oleg Ivanov
Member

Откуда: Киев
Сообщений: 289
andrey_anonymous
Oleg Ivanov
andrey_anonymous
Полагаю, не составит труда предложить такой order by, который потребует распределения данных.
Думаю, составит :-)
Сортировка всегда выполняется локально, на AMP.
т.е. это частичная сортировка
Oleg Ivanov
Окончательный MERGE производит ByNET в процессе передачи данных клиенту.
То есть окончательная сортировка требует как перераспределения данных, так и ресурсов на их обработку, что и требовалось доказать ;)
ИМХО вы не поняли очем я написал. Локальная сортировка происходит на узлах независимо, далее для передачи выборки клиенту используется интерконнект — ByNET. В случае сортировки, ByNET не просто передает данные клиенту, а еще производит merge отсортированных выборок. Merge "простая" операция и никакого перераспределения не происходит, но в результате клиент получает "полностью" отсортированную выборку.

andrey_anonymous
Oleg Ivanov
andrey_anonymous
Oracle умеет ровно то же самое. Partition-wise join называется.
Я думал мы говорим о случае когда объединение происходит НЕ по ключам партиционирования...
Тогда не понял пассажа про локальные соединения в терадата, не требующие перераспределения данных.
Oleg Ivanov
Если объединять по ключам партиционирования — Oracle может выполнять Partition-wise join, а Teradata локальный джоин без перераспределения.
Partial Partition-wise Join в Oracle, ИМХО, хорош для объединения "большой" партиционированной таблицы с "маленькой".
????? нет, его основное предназначение - независимое соединение совпадающих разделов, если оно возможно. "Маленькие" и "большие" таблицы тут совершенно ни при чем.
Full Partition-wise Join — применяется когда объединение происходит по partition key обоих таблиц; прямой аналог в Teradata — локальные джойны, т.е. когда объединение происходит по Primary Index обоих таблиц.
Для Partial Partition-wise Join достаточно, чтобы объединение происходило по partiton key одной из таблиц, при этом вторая динамически "партиционируется". ИМХО это выгодно делать когда "партиционируемая" таблица много меньше первой; как такие джойны реализованы в Терадата я уже писал.
andrey_anonymous
Oleg Ivanov
В таком случае Teradata просто копирует "маленькую" на все узлы, т.е. перераспределения "большой" не происходит.
Ораклу даже копировать не придется, каждый узел просто прочитает "меленькую" в собственный buffer cache :)

Ключевое слово тут "Каждый". Т.е. количество дисковых операций одинаково, а ByNET "забить" небольшой таблицей тяжело :-)
12 окт 06, 15:54    [3254209]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Oleg Ivanov
andrey_anonymous
То есть окончательная сортировка требует как перераспределения данных, так и ресурсов на их обработку, что и требовалось доказать ;)
ИМХО вы не поняли очем я написал. Локальная сортировка происходит на узлах независимо, далее для передачи выборки клиенту используется интерконнект — ByNET. В случае сортировки, ByNET не просто передает данные клиенту, а еще производит merge отсортированных выборок. Merge "простая" операция и никакого перераспределения не происходит, но в результате клиент получает "полностью" отсортированную выборку.
ИМХО наоборот, Вы не поняли о чем я писал.
1) Передача по интерконнекту - перераспределение данных или нет? ИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.
2) Прежде чем клиенту будет выдана первая строка, все узлы должны завершить свои локальные сортировки и материализовать результат, в противном случае корректный merge просто не получится.
3) Через interconnect дожен протиснуться весь объем результирующей выборки.
Итог: не наблюдаю технологических преимуществ teradata.
Oleg Ivanov
Для Partial Partition-wise Join достаточно, чтобы объединение происходило по partiton key одной из таблиц, при этом вторая динамически "партиционируется".
Это уже не partition-wise, это самое обычное соединение с partition iterator.
Параллелится и все такое, но не вижу способа, который дал бы teradata технологическое преимущество над RAC, который тоже все это умеет.
Oleg Ivanov
ИМХО это выгодно делать когда "партиционируемая" таблица много меньше первой;
Ну еще бы, через интерконнект большую табличку особо не погоняешь :)
Oleg Ivanov
как такие джойны реализованы в Терадата я уже писал.
Назовите пожалуйста преимущества описанного Вами способа над архитектурой shared-disk
Oleg Ivanov
andrey_anonymous
Oleg Ivanov
В таком случае Teradata просто копирует "маленькую" на все узлы, т.е. перераспределения "большой" не происходит.
Ораклу даже копировать не придется, каждый узел просто прочитает "меленькую" в собственный buffer cache :)

Ключевое слово тут "Каждый". Т.е. количество дисковых операций одинаково, а ByNET "забить" небольшой таблицей тяжело :-)

Не угадали. Второй, третий и далее узлы получат свои данные из кэша (т.е. физического чтения с дисков уже не будет).
Если учесть, что в RAC нет необходимости "давить" IO, то все становится еще забавнее :)
12 окт 06, 18:52    [3255630]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить