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

Откуда: Киев
Сообщений: 289
andrey_anonymous
ИМХО наоборот, Вы не поняли о чем я писал.
Попытаемся разобраться :-)
andrey_anonymous
1) Передача по интерконнекту - перераспределение данных или нет?
В терминологии Teradata — нет.
Перераспределение это: читаем данные, передаем через интерконнект, пишем на диск другого узла.
В данном случае данные передаются от узла, через интерконнект непосредственно клиенту.
andrey_anonymous
ИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.
Я как раз и пытаюсь объяснить, что merge происходит "на лету", финальная выборка не материализуется. Используется для этого программный или аппаратный компонент ByNET я не знаю, но это и не суть важно т.к. merge на много менее ресурсоемкая операция по сравнению с сортировкой подвыборок.
andrey_anonymous
2) Прежде чем клиенту будет выдана первая строка, все узлы должны завершить свои локальные сортировки и материализовать результат, в противном случае корректный merge просто не получится.
Сто пудов.
andrey_anonymous
3) Через interconnect дожен протиснуться весь объем результирующей выборки.
Вообще, вне зависимости от наличия или отсутствия сортировки, данные передаются клиенту через интерконнект (кроме, конечно, данных узла, к которому присоеденен пользователь).
andrey_anonymous
Итог: не наблюдаю технологических преимуществ teradata.
Преимуществ перед чем? Назовите другую СУБД, которая умеет распараллеливать сортировку тогда сможем сравнивать.
andrey_anonymous
Параллелится и все такое, но не вижу способа, который дал бы teradata технологическое преимущество над RAC, который тоже все это умеет
С точки зрения параллельного выполнения, имеем три с половиной вида джойна:
1) обе таблицы партиционированы по ключам соединения;
2) одна из таблиц (tab1) партиционирована по ключу соединения, другая (tab2) нет;
2а) то же, но tab2 много меньше tab1;
3) соединение происходит не по partition keys.

Случай раз)
TD - локальный джоин, без перераспределения строк
Ora - Full Partition-wise Join

Случай два)
TD - перераспределение tab2 таблицы по ключу соединения, либо (если tab1 << tab2) копирование на все узлы tab1
Ora - параллельный join невозможен (ИМХО)

Случай два "а")
TD - копирование tab2 на все узлы
Ora - Partial Partition-wise Join (требуется динамическое партиционирование таблицы)

Случай три)
TD - перераспределение обоих таблиц либо копирование меньшей на все узлы
Ora - параллельный join невозможен (ИМХО)

Т.е. Teradata обеспечивает параллельное выполнение практически любого запроса.
andrey_anonymous
Назовите пожалуйста преимущества описанного Вами способа над архитектурой shared-disk
Цель применения shared nothing архитектуры в Teradata — обеспечение линейной и неограниченной масштабируемости системы. Масштабируемость shared disk архитектуры растет нелинейно и ограничена большим количеством latch'ей необходимых для организации совместного доступа к диску. В Терадате же каждый AMP монопольно владеет своей порцией данных, ему не надо синхронизировать взаимодействие с дисками с соседними AMP'ами.
А технологии джойнов в TD изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared nothing архитектурой.
andrey_anonymous
Не угадали. Второй, третий и далее узлы получат свои данные из кэша (т.е. физического чтения с дисков уже не будет).
Если учесть, что в RAC нет необходимости "давить" IO, то все становится еще забавнее :)
ОК, из кэша, но через интерконнект :-)
13 окт 06, 16:21    [3260183]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Терминология в Teradata - отдельная "песня". Все называется "никак у людей". Зачем придумывать свои термины когда есть общепризнанные мне непонятно.
14 окт 06, 00:24    [3261610]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
contr
Member

Откуда:
Сообщений: 1909
Oleg Ivanov
Перераспределение это: читаем данные, передаем через интерконнект, пишем на диск другого узла.
Зачем пишем? И какое отношение это имеет к перераспределению данных с целью выполенния запроса?
Oleg Ivanov
В данном случае данные передаются от узла, через интерконнект непосредственно клиенту.
Ora: the same;
Oleg Ivanov
andrey_anonymous
ИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.
Я как раз и пытаюсь объяснить, что merge происходит "на лету", финальная выборка не материализуется.
В ora в идентичной ситуации - тоже.
Oleg Ivanov
merge на много менее ресурсоемкая операция по сравнению с сортировкой подвыборок.
Почти.
Если не рассматривать параллельные операции.
Но замнем для ясности изложения.
Oleg Ivanov

andrey_anonymous
2) Прежде чем клиенту будет выдана первая строка, все узлы должны завершить свои локальные сортировки и материализовать результат, в противном случае корректный merge просто не получится.
Сто пудов.
т.е. в этой части чудес нет.
ОК.
Oleg Ivanov
andrey_anonymous
3) Через interconnect дожен протиснуться весь объем результирующей выборки.
Вообще, вне зависимости от наличия или отсутствия сортировки, данные передаются клиенту через интерконнект (кроме, конечно, данных узла, к которому присоеденен пользователь).

ОК. В ORA аналогично, что очевидно.
Oleg Ivanov
andrey_anonymous
Итог: не наблюдаю технологических преимуществ teradata.
Преимуществ перед чем? Назовите другую СУБД, которая умеет распараллеливать сортировку тогда сможем сравнивать.
Как Вы уже, несомненно, догадались, я назову oracle :)
Oleg Ivanov
andrey_anonymous
Параллелится и все такое, но не вижу способа, который дал бы teradata технологическое преимущество над RAC, который тоже все это умеет
С точки зрения параллельного выполнения
Случай раз)
идентичен для систем, пропускаем.
Oleg Ivanov

Случай два)
TD - перераспределение tab2 таблицы по ключу соединения, либо (если tab1 << tab2) копирование на все узлы tab1
Ora - параллельный join невозможен (ИМХО)
И что же ему мешает? ИМХО, Вы заблуждаетесь.
Oleg Ivanov
Случай два "а")
TD - копирование tab2 на все узлы
Ora - Partial Partition-wise Join (требуется динамическое партиционирование таблицы)
Ни в коем разе. Это просто соединение, никакого partition-wise не будет. Общая ситуация по "тяжести" аналогична таковой в TD
Oleg Ivanov
Случай три)
TD - перераспределение обоих таблиц либо копирование меньшей на все узлы
Ora - параллельный join невозможен (ИМХО)
Возможен, почему нет? Другое дело, что:
- сама ситуация невыгодна что для TD, что для ora.
- ситуация свидетельстует об ошибке в дизайне хранилища, тоже симметрично для TD и Ora
Oleg Ivanov
Т.е. Teradata обеспечивает параллельное выполнение практически любого запроса.
Хм... Ora как бы тоже обеспечивает, но при этом может отследитьситуации, когда parallel невыгоден и отказаться от него.
Потенциальный + оракелю и минус террадате.
Oleg Ivanov
andrey_anonymous
Назовите пожалуйста преимущества описанного Вами способа над архитектурой shared-disk
Цель применения shared nothing архитектуры в Teradata — обеспечение линейной и неограниченной масштабируемости системы. Масштабируемость shared disk архитектуры растет нелинейно и ограничена большим количеством latch'ей необходимых для организации совместного доступа к диску.
В данном случае Вы жестоко передергиваете. Готов обсуждать приватно, но в форуме реакция одна ЛОЖЬ.
Oleg Ivanov
В Терадате же каждый AMP монопольно владеет своей порцией данных, ему не надо синхронизировать взаимодействие с дисками с соседними AMP'ами.
Надо-надо, рассматривайте плиз ВСЕ кейсы.
Oleg Ivanov
А технологии джойнов в TD изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared nothing архитектурой.
Парирую: "А технологии джойнов в Ora изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared disk архитектурой."
Oleg Ivanov

andrey_anonymous
Не угадали. Второй, третий и далее узлы получат свои данные из кэша (т.е. физического чтения с дисков уже не будет).
Если учесть, что в RAC нет необходимости "давить" IO, то все становится еще забавнее :)
ОК, из кэша, но через интерконнект :-)
Оракелю тут НЕ НУЖЕН интерконнект. Имелся ввиду кэш стораджа.
14 окт 06, 03:17    [3261728]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Зл0й
Терминология в Teradata - отдельная "песня". Все называется "никак у людей". Зачем придумывать свои термины когда есть общепризнанные мне непонятно.


Похоже, что многие общепризнанные термины появляются после того, как они появляются в Терадате. Всё-таки, Терадата - пионер в области СУБД для хранилищ данных.


contr
Зачем пишем? И какое отношение это имеет к перераспределению данных с целью выполенния запроса?


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

andrey_anonymous
ИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.


Хотел бы ещё раз поддержать Олега - Терадате не требуется отдельный узел для операции merge, которая, естественно, значительно дешевле сортировки.

contr
Почти.
Если не рассматривать параллельные операции.
Но замнем для ясности изложения.


Хотелось бы именно внести ясность. Возникает впечатление, что Вы сомневаетесь в том, что merge дешевле.

Назовите другую СУБД, которая умеет распараллеливать сортировку тогда сможем сравнивать.
contr
Как Вы уже, несомненно, догадались, я назову oracle :)


Кстати, Вас не затруднит закинуть сюда план параллельного выполнения запроса Oracle с сортировкой не по полю, по которому сделан partitioning?
Интересно было бы посмотреть.
Равно как и планы запросов для случаев раз, два, три, рассматриваемых выше.
В отместку, т.е. в ответ, я хотел сказать :) готов запостить планы Терадаты.

contr
Хм... Ora как бы тоже обеспечивает, но при этом может отследитьситуации, когда parallel невыгоден и отказаться от него.
Потенциальный + оракелю и минус террадате.


Ну, Терадата, скажем, тоже умеет так. Например,
SELECT c1, c2, c3 
FROM table_1
WHERE unique_primary_index=5

Выполнится, в общем случае, за одно чтение с диска.

Назовите другую СУБД, которая так сумеет. Подозреваю, что сначала почитается индекс, а потом данные. В Терадате же первичный индекс - это не индекс, а функция.

contr
- ситуация свидетельстует об ошибке в дизайне хранилища, тоже симметрично для TD и Ora


На все случаи не надизайнишь. На то она и СУБД хранилища, чтобы уметь запросы Ad Hoc выполнять эффективно, для которых, возможно, дизайн не очень удобен.

contr
В данном случае Вы жестоко передергиваете. Готов обсуждать приватно, но в форуме реакция одна ЛОЖЬ.


Хотелось бы опять-таки поддержать коллегу. Зачем же так резко?
Я, пожалуй, соглашусь, что архитектура shared nothing по масштабируемости превосходит shared disk, потому как у последней существуют неизбежные накладные расходы на координацию доступа к расшаренному ресурсу, которые отсутствуют в shared nothing.

contr
Надо-надо, рассматривайте плиз ВСЕ кейсы.

Например?

contr
А технологии джойнов в Ora изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared disk архитектурой


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

contr
Оракелю тут НЕ НУЖЕН интерконнект. Имелся ввиду кэш стораджа.

Интересно, с какой скоростью будет выметаться пресловутый кэш на терабайтных объёмах данных с несколькими сотнями пользователей, параллельно выполняющими запросы по таблицам с сотнями миллионов записей?
Всё конечно здорово, только кэш в хранилищах данных - далеко не панацея. К тому же, дорого это. Там пока диски правят и, наверное, долго ещё будут править. Поэтому скорость работы с большими объёмами данных зависит от оптимальной (параллельной) работы с дисками.
Хотя, время покажет. Может, через лет восемь-десять Оракл догонит по производительности Терадату :)

С уважением,
Константин Лисянский
http://lissianski.narod.ru
17 окт 06, 00:23    [3268511]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Константин Лисянский
Перераспределение данных - это создание временной таблицы (spool file в терминологии Терадаты), перераспределённой по первичному индексу (столбцу или набору столбцов, по которому таблица распределяется по узлам), отличному от первичного индекса таблицы с целью последующих манипуляций (сортировка, агрегирование, джойн). При перераспределении таблица пишется на диски.
Обязательно писать на диск?! АФАИР, речь шла о небольшой таблице, ведущей в соединении... Я понимаю зачем писать на диск если не хватает памяти. Но писать всегда?
Хм...
Предлагаю для определенности называть перераспределением все-таки выборку данных и распространение их по интерконнекту на заинтересованные узлы, безусловная запись временного объекта - все-таки скорее имплементация чем принцип.
Константин Лисянский
andrey_anonymous
ИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.

Хотел бы ещё раз поддержать Олега - Терадате не требуется отдельный узел для операции merge, которая, естественно, значительно дешевле сортировки.
Знаете, Константин, я не верю в чудеса. Независимо от стоимости операции должен быть CPU, который эту операцию выполнит. И немножечко RAM для буферизации. Хоть горшком обзовите, но оно должно быть.
Константин Лисянский
Назовите другую СУБД, которая умеет распараллеливать сортировку тогда сможем сравнивать.
contr
Как Вы уже, несомненно, догадались, я назову oracle :)

Кстати, Вас не затруднит закинуть сюда план параллельного выполнения запроса Oracle с сортировкой не по полю, по которому сделан partitioning?
Интересно было бы посмотреть.
Не хотелось бы прямо сейчас делать специальный тесткейс на parallel, но что-то подобное можно увидеть тут.
Готов прокомментировать выбор поста если что-то останется непонятно.
Константин Лисянский
SELECT c1, c2, c3 
FROM table_1
WHERE unique_primary_index=5
Выполнится, в общем случае, за одно чтение с диска.

Назовите другую СУБД, которая так сумеет. Подозреваю, что сначала почитается индекс, а потом данные. В Терадате же первичный индекс - это не индекс, а функция.
Функция от чего? Очень интересно, как именно терадата найдет нужную строку за одно чтение.
Если я правильно понял, то на оракеле аналогичное поведение продемонстрирует однотабличный хеш-кластер, но цена вопроса - производительность некоторых операций DML
Константин Лисянский

contr
- ситуация свидетельстует об ошибке в дизайне хранилища, тоже симметрично для TD и Ora

На все случаи не надизайнишь. На то она и СУБД хранилища, чтобы уметь запросы Ad Hoc выполнять эффективно, для которых, возможно, дизайн не очень удобен.
Вот именно эффективность-то как раз и под вопросом, на то он и Ad-Hoc :)
Константин Лисянский
Я, пожалуй, соглашусь, что архитектура shared nothing по масштабируемости превосходит shared disk, потому как у последней существуют неизбежные накладные расходы на координацию доступа к расшаренному ресурсу, которые отсутствуют в shared nothing.
Спорное утверждение, поскольку в shared nothing сущствуют накладные расходы на перераспределение данных, отсутствующие в shared disk :)
Константин Лисянский

contr
А технологии джойнов в Ora изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared disk архитектурой

Я думаю, что в то время, когда разрабатывалась Терадата, Оракл ещё не знал, что такое параллелизм.
Из этого должен следовать какой-то вывод кроме того, что когда-то деревья были выше а трава зеленее?
Константин Лисянский
contr
Оракелю тут НЕ НУЖЕН интерконнект. Имелся ввиду кэш стораджа.
Интересно, с какой скоростью будет выметаться пресловутый кэш на терабайтных объёмах данных с несколькими сотнями пользователей
Если вернетесь к рассматриваемому кейсу то увидите, что это как раз один из тех немногих сценариев, когда кэш на терабайте будет эффективен.
Константин Лисянский
скорость работы с большими объёмами данных зависит от оптимальной (параллельной) работы с дисками.
Тут Вы оспариваете как раз подход TeraData. Чуть выше по топику речь шла о том, что для эффективной работы интерконнекта производительность ввода-вывода в терадате искусственно ограничена.
А в shared disk наоборот - поднимают как могут, все диски заставляют работать в параллель.
Константин Лисянский

Хотя, время покажет. Может, через лет восемь-десять Оракл догонит по производительности Терадату :)

Тут уже был отсыл к TPC-H. Что-то я там терадату не видел...
Может, будущее уже наступило? =)
17 окт 06, 01:51    [3268566]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Павел Новокшонов
Member

Откуда: Moscow -> Atlanta, GA
Сообщений: 90
Про Оракл не скажу не знаю просто. Для приведенного примера в Teradata для table_b можно построить то что называется single-table join index c альтернативным Primary Index на column_b27. Соответсвенно когда table_a будет джойнится с table_b редистрибуции не потребуется, т.к. будет читаться индекс и данные уже будут лежать на нужных AMP-ах.

Bynet сложно заткнуть в принципе. Скорее проблемы с производительностью возникают когда сотня другая пользователей начинает одновременно долбить систему навороченными запросами по таблицам с миллиардами записей, но даже в этом случае ограничивающими фактороми будут CPU, диск и ограничение по кол-ву используемых AMP Worker Tasks (подпроцессов сидящих внутри каждого AMP’a).

Teradata сознательно похерила тесты TPC, Winter VLDB survey и прочее потому что эти бенчмарки уже давно далеки от реальной жизни. Надо смотреть живые системы, которые давно превосходят все искусственно придуманные тесты.
17 окт 06, 07:35    [3268683]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Павел Новокшонов
Про Оракл не скажу не знаю просто. Для приведенного примера в Teradata для table_b можно построить то что называется single-table join index c альтернативным Primary Index на column_b27. Соответсвенно когда table_a будет джойнится с table_b редистрибуции не потребуется, т.к. будет читаться индекс и данные уже будут лежать на нужных AMP-ах.
Т.е. провести статическое перераспределение данных, фактически продублировав таблицу?
Понятно, что в техническом плане ora не отстанет - там можно создать глобальный секционированный индекс или материализованное продставление.
Но цена вопроса тоже понятна - DML + maintenance
Павел Новокшонов

Bynet сложно заткнуть в принципе.
Что же это за чудо такое, что его "в принципе" сложно заткнуть? Интерконнект с диспетчеризацией и прочими наворотами, пропускная способность которого превышает пропускную способность RAM в несколько раз?
Верится как-то очень с трудом.
Павел Новокшонов
Teradata сознательно похерила тесты TPC, Winter VLDB survey и прочее потому что эти бенчмарки уже давно далеки от реальной жизни. Надо смотреть живые системы, которые давно превосходят все искусственно придуманные тесты.

А вот это соображение обычно начинают приводить когда с результатами тестов имеются определенные проблемы - Oracle тоже когда-то так поступала, но в последние годы что-то прекратила :)
17 окт 06, 10:22    [3269131]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Oleg Ivanov
Member

Откуда: Киев
Сообщений: 289
contr
Ora: the same;
contr
Oleg Ivanov
andrey_anonymous
ИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.
Я как раз и пытаюсь объяснить, что merge происходит "на лету", финальная выборка не материализуется.
В ora в идентичной ситуации - тоже.
contr

Oleg Ivanov
andrey_anonymous
Итог: не наблюдаю технологических преимуществ teradata.
Преимуществ перед чем? Назовите другую СУБД, которая умеет распараллеливать сортировку тогда сможем сравнивать.
Как Вы уже, несомненно, догадались, я назову oracle :)
Таки нашел описание процесса параллельной сортировки в Oracle RAC.
Сравните с сортировкой в Teradata.
contr
Oleg Ivanov
merge на много менее ресурсоемкая операция по сравнению с сортировкой подвыборок.
Почти.
Если не рассматривать параллельные операции.
Но замнем для ясности изложения.
??? что вы имеете в виду?
contr
Oleg Ivanov

Случай два)
TD - перераспределение tab2 таблицы по ключу соединения, либо (если tab1 << tab2) копирование на все узлы tab1
Ora - параллельный join невозможен (ИМХО)
И что же ему мешает? ИМХО, Вы заблуждаетесь.
contr
Oleg Ivanov
Случай три)
TD - перераспределение обоих таблиц либо копирование меньшей на все узлы
Ora - параллельный join невозможен (ИМХО)
Возможен, почему нет? Другое дело, что:
- сама ситуация невыгодна что для TD, что для ora.
- ситуация свидетельстует об ошибке в дизайне хранилища, тоже симметрично для TD и Ora
А можно ссылку на раздел документации в котором подробно описан процесс параллельного выполнения join не по ключам партиционирования?
Я сумел найти только невнятные упоминания о динамическом партиционировании и статью в которой говорится, что RAC не умеет параллельно выполнять агрегацию. Это правда?
contr
Oleg Ivanov
Случай два "а")
TD - копирование tab2 на все узлы
Ora - Partial Partition-wise Join (требуется динамическое партиционирование таблицы)
Ни в коем разе. Это просто соединение, никакого partition-wise не будет. Общая ситуация по "тяжести" аналогична таковой в TD
Документация называет такой случай Partial Partiton-wise Join :-)
contr
Oleg Ivanov
Т.е. Teradata обеспечивает параллельное выполнение практически любого запроса.
Хм... Ora как бы тоже обеспечивает, но при этом может отследитьситуации, когда parallel невыгоден и отказаться от него.
Потенциальный + оракелю и минус террадате.
Тут Константин ответил
contr
Oleg Ivanov
andrey_anonymous
Назовите пожалуйста преимущества описанного Вами способа над архитектурой shared-disk
Цель применения shared nothing архитектуры в Teradata — обеспечение линейной и неограниченной масштабируемости системы. Масштабируемость shared disk архитектуры растет нелинейно и ограничена большим количеством latch'ей необходимых для организации совместного доступа к диску.
В данном случае Вы жестоко передергиваете. Готов обсуждать приватно, но в форуме реакция одна ЛОЖЬ.
Допустим у вас RAC из четырех узлов с массивом XX.
Вы утверждаете, что докупив еще 4 узла и аналогичный массив вы получите друкратное увеличение производительности системы? И так до бесконечности?
contr
Oleg Ivanov
В Терадате же каждый AMP монопольно владеет своей порцией данных, ему не надо синхронизировать взаимодействие с дисками с соседними AMP'ами.
Надо-надо, рассматривайте плиз ВСЕ кейсы.
AMP для своей части данных выполняет:
- чтение и изменение
- загрузку
- построение индексов
- backup and recovery
- агрегацию
- сортировку
- журналирование
Какие другие случаи я должен рассмотреть?
contr
Oleg Ivanov
А технологии джойнов в TD изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared nothing архитектурой.
Парирую: "А технологии джойнов в Ora изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared disk архитектурой."
С версии 7.1 (на сколько помню, где-то 1994)
contr
Oleg Ivanov

andrey_anonymous
Не угадали. Второй, третий и далее узлы получат свои данные из кэша (т.е. физического чтения с дисков уже не будет).
Если учесть, что в RAC нет необходимости "давить" IO, то все становится еще забавнее :)
ОК, из кэша, но через интерконнект :-)
Оракелю тут НЕ НУЖЕН интерконнект. Имелся ввиду кэш стораджа.
ОК
17 окт 06, 13:36    [3270600]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Что же это за чудо такое, что его "в принципе" сложно заткнуть? Интерконнект с диспетчеризацией и прочими наворотами, пропускная способность которого превышает пропускную способность RAM в несколько раз?
Верится как-то очень с трудом.


Это интерконнект с возможностью сообщений тапа точка-точка, broadcast и multicast со своим протоколом, оптимизированным под операции СУБД (в отличие от, например TCP/IP). Плюс "прочие навороты" в виде интеллекта, необходимого для выполнения операции merge, которая обсуждалась выше. Плюс механизмы обеспечения надёжности (двойное резервирование), плюс самоконфигурируемость (актуально для больших систем - не надо настраивать ручками).
С RAM, пожалуй, я бы не стал сравнивать - не о тех объёмах данных идёт речь, чтобы их туда запихивать. А вот, для дисков вполне нормально. Поэтому Павел правильно говорит, что заткнуть его трудно, ежели его общая пропускная способность растёт пропорционально количеству добавляемых узлов и в силу того, что суммарная пропускная способность дисков, подключённых к одному узлу ограничена в силу ограниченного количества дисков.

По-моему, так (с).

andrey_anonymous
А вот это соображение обычно начинают приводить когда с результатами тестов имеются определенные проблемы - Oracle тоже когда-то так поступала, но в последние годы что-то прекратила :)


На моей памяти ещё ни разу ни один потенциальный клиент не поинтересовался результатами тестов. Задают вопросы типа "а где это работает, на каких объёмах сырых данных, сколько пользователей засыпают базу сложными запросами одновременно, свозите посмотреть на таких клиентов". А по поводу тестов ещё никто не спрашивал, кроме как в этом форуме.

Вы когда машину покупаете, наверное, интересуетесь у друзей, не до какой скорости её разогнали на дне соляного озера, а как им на ней ездится в реальной жизни?


andrey_anonymous
Обязательно писать на диск?! АФАИР, речь шла о небольшой таблице, ведущей в соединении... Я понимаю зачем писать на диск если не хватает памяти. Но писать всегда?
Хм...
Предлагаю для определенности называть перераспределением все-таки выборку данных и распространение их по интерконнекту на заинтересованные узлы, безусловная запись временного объекта - все-таки скорее имплементация чем принцип.


На диск, конечно, писать обязательно не всегда, но в большинстве случаев, если речь идёт об обработке больших таблиц. Всё-таки, память узла не резиновая - 4ГБ всего, если речб идёт о 10 AMP на узел, то с учётом требований операционки и (ну, например, 500 МБ) каждому из 10 процессов можно рассчитывать примерно на 350 МБ. Понятно, чтьо много туда не запихаешь, только небольшие таблицы. Всё остальное летит на диск.
Хотя в целом, с Вами согласен - можно для общности обсуждения принять Ваше определение.


andrey_anonymous
Знаете, Константин, я не верю в чудеса. Независимо от стоимости операции должен быть CPU, который эту операцию выполнит. И немножечко RAM для буферизации. Хоть горшком обзовите, но оно должно быть.


Как уже сказано выше, bynet имеет такие элементы.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
23 окт 06, 21:47    [3298866]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Не хотелось бы прямо сейчас делать специальный тесткейс на parallel, но что-то подобное можно увидеть тут.
Готов прокомментировать выбор поста если что-то останется непонятно.


Ага. Не очень понятно, в каком месте там параллельная сортировка. Я слаб в чтении планов запросов от Oracle, извините.

И если простой запрос сделать типа

SELECT val FROM ane_test ORDER BY val ASC

То как будет выполняться параллельная сортировка?

С уважением,
Константин Лисянский
http://lissianski.narod.ru
23 окт 06, 22:23    [3298984]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Функция от чего? Очень интересно, как именно терадата найдет нужную строку за одно чтение.
Если я правильно понял, то на оракеле аналогичное поведение продемонстрирует однотабличный хеш-кластер, но цена вопроса - производительность некоторых операций DML


Функция от значения столбца (комбинации значений столбцов), выступающего в роли первичного индекса. Когда Терадата выполняет INSERT, то значение уникального первичного индекса хешируется, в результате, получается значение, указывающее на то, какой AMP будет деражать у себя эту строку. Далее спомощью структуры, напоминающей отдалённо трёхуровневое дерево, запись размещается в нужное место диска. Эта структура с болшой вероятностью хранится в памяти. Далее при считывании происходит обратная процедура - значение константы, находящейся в условии WHERE первичный индекс = константа, хэшируется. При этом Терадата определяет, какой AMP отвечает за хранение этой записи и обращается к нему с просьбой найти такую запись. Используя резидентную структуру AMP определяет физическое местоположение записи на диске (точнее, блок, в котором эта запись лежит), дальше читается блок и запись из него выбирается. Получается одно чтение с диска.


andrey_anonymous
Вот именно эффективность-то как раз и под вопросом, на то он и Ad-Hoc :)


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


andrey_anonymous
Если вернетесь к рассматриваемому кейсу то увидите, что это как раз один из тех немногих сценариев, когда кэш на терабайте будет эффективен.


Покажите, для меня не очевидно.


andrey_anonymous
Тут Вы оспариваете как раз подход TeraData. Чуть выше по топику речь шла о том, что для эффективной работы интерконнекта производительность ввода-вывода в терадате искусственно ограничена.
А в shared disk наоборот - поднимают как могут, все диски заставляют работать в параллель.


Не совсем так - пропускная способность интерконнекта не разгоняется в силу отсутствия в этом необходимости из-за того, что пропускная способность дисков суть - константа. Вместе с ростом скорости дисков, bynet тоже по необходимости разгоняли.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
23 окт 06, 22:50    [3299079]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Константин Лисянский
andrey_anonymous
Что же это за чудо такое, что его "в принципе" сложно заткнуть? Интерконнект с диспетчеризацией и прочими наворотами, пропускная способность которого превышает пропускную способность RAM в несколько раз?
Плюс "прочие навороты" в виде интеллекта, необходимого для выполнения операции merge, которая обсуждалась выше. Плюс механизмы обеспечения надёжности (двойное резервирование), плюс самоконфигурируемость (актуально для больших систем - не надо настраивать ручками).
Это специальное выделенное оборудование или реализуется средствами обычных узлов?
Константин Лисянский
Вы когда машину покупаете, наверное, интересуетесь у друзей, не до какой скорости её разогнали на дне соляного озера, а как им на ней ездится в реальной жизни?
Неудачный пример - при покупке авто я самое пристальное внимание уделяю результатам крэш-тестов, сравнительным тестам приличных изданий и прочим источникам информации. Друзьям - в последнюю очередь, просто ввиду их принципиальной субъективности :)
Константин Лисянский
Ага. Не очень понятно, в каком месте там параллельная сортировка. Я слаб в чтении планов запросов от Oracle, извините.
Ничего страшного, я поясню.
Условие задачи Вы, видимо, прочитали.
Надо отсортировать данные из нескольких разделов и взять N первых.
Изюминка обсуждаемого плана - это отдельная сортировка каждого из разделов, взятие первых N элементов из каждого, sort merge результатов и еще одна отсечка первых N элементов.
Еще один момент: сортировка в разделах совпала с локальным индексом, поэтому физически не выполнялась.
Разумеется, выборки и обработка разделов безусловно параллелятся - в конкретном примере parallel не применялся, поскольку интересовали совсем другие аспекты.
Константин Лисянский
Далее спомощью структуры, напоминающей отдалённо трёхуровневое дерево, запись размещается в нужное место диска. Эта структура с болшой вероятностью хранится в памяти.

Ну то есть обычный доступ к hash-разделу по локальному индексу.
В оракеле принято считать логический ввод-вывод, т.е. три уровня дерева+чтение блока - четыре логических чтения. Физических от нуля до четырех, наиболее вероятно - одно-два.
Ничего оригинального тут нет.
Константин Лисянский
При этом нужно уметь эффективно параллельно делать фул скан. В этом плане с Терадатой трудно соревноваться. Уж очень быстро она это умеет делать.

Пока я так и не увидел чего-то такого, что давало бы TeraData безусловное преимущество. Очень быстро - за счет чего?
Вряд ли быстрее чем disk io...
Константин Лисянский
Покажите, для меня не очевидно.
Я могу ошибаться, но в данном случае в shared-disk отдельные узлы будут делать запросы к относительно недалеко расположенным блокам. При этом с учетом ширины страйпа вероятность того, что один из узлов поднимет в кэш данные, которые будут тут же затребованы другим не самая маленькая. То есть shared disk не должен проиграть shared-nothing на параллельном чтении на равном количестве дисков.
24 окт 06, 00:00    [3299182]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Это специальное выделенное оборудование или реализуется средствами обычных узлов?


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


andrey_anonymous
Неудачный пример - при покупке авто я самое пристальное внимание уделяю результатам крэш-тестов, сравнительным тестам приличных изданий и прочим источникам информации. Друзьям - в последнюю очередь, просто ввиду их принципиальной субъективности :)


Понятно. Очевидно, краш-тесты автомобилей более-менее приближены к реальным условиям столкновений.
В случае тестов TPC это далеко не так. Там таблиц в схеме намного меньше, чем можно джойнов в запросе сделать.

andrey_anonymous
Ничего страшного, я поясню.
Условие задачи Вы, видимо, прочитали.
Надо отсортировать данные из нескольких разделов и взять N первых.
Изюминка обсуждаемого плана - это отдельная сортировка каждого из разделов, взятие первых N элементов из каждого, sort merge результатов и еще одна отсечка первых N элементов.
Еще один момент: сортировка в разделах совпала с локальным индексом, поэтому физически не выполнялась.
Разумеется, выборки и обработка разделов безусловно параллелятся - в конкретном примере parallel не применялся, поскольку интересовали совсем другие аспекты.


Понятно. Ну, тогда это пример, на мой взгляд не показателен для данной дискуссии. Хотя, наверное, в качестве разминки для ума подойдёт.

andrey_anonymous
Ну то есть обычный доступ к hash-разделу по локальному индексу.
В оракеле принято считать логический ввод-вывод, т.е. три уровня дерева+чтение блока - четыре логических чтения. Физических от нуля до четырех, наиболее вероятно - одно-два.
Ничего оригинального тут нет.


Ясно. Кстати, оптимизатор при выборе стратегий считает логический ввод-вывод или физический? По-моему, если логический, это не совсем правильно. Разница может быть ощутимой.

andrey_anonymous
Пока я так и не увидел чего-то такого, что давало бы TeraData безусловное преимущество. Очень быстро - за счет чего?
Вряд ли быстрее чем disk io...


Элементарно. Терадата конфигурируется всегда с большим количеством дисков. Допустим, на одном узле 10 единиц параллелизма (AMP, в терминах Терадата). Это означает, что к нему будет присоединено 10 лочических дисковых зеркальных пар. По факту, логическая пара может состоять из 4 дисков. Таким образом, к узлу может быть присоединено до 40 дисков.
Возьмём систему начального уровня в 10 узлов. Это 100 единиц параллелизма и 400 дисков. Каждая единица параллелизма занимается обработкой своего кусочка таблицы, которая хешированием равномерно размазывается между ними.
Допустим, мы имеем дело с фулл-сканом таблицы в 1 миллиард записей. После хеширования каждый AMP получает по 1 сотой такой таблицы, то есть по 10 миллионов записей. Что такое 10 миллионов записей в режиме full scan? Копейки.


andrey_anonymous
Я могу ошибаться, но в данном случае в shared-disk отдельные узлы будут делать запросы к относительно недалеко расположенным блокам. При этом с учетом ширины страйпа вероятность того, что один из узлов поднимет в кэш данные, которые будут тут же затребованы другим не самая маленькая. То есть shared disk не должен проиграть shared-nothing на параллельном чтении на равном количестве дисков.


Я немного не понял, при чём тут страйпы, но базовая идея такая - если у Вас shared disk, то, как бы Вы не старались, всегда найдутся два параллельных процесса, которые захотят читать из разных блоков диска (или писать туда). Кто-то будет должен дождаться. В случае shared nothing общего диска нет, поэтому степень праллелизма по дискам всегда будет выше. Даже при одинаковом количестве дисков. Кстати, нужно ещё поискать такую аппаратную платформу, на которой работает Оракл с таким количеством дисков, чтобы она сравнилась со средней конфигурацией Терадата (возьмём к примеру, систему из 50 узлов - это 100 процессоров, 2 Терабайта ОЗУ, и 2 тысячи дисков, если я правильно сосчитал). Тут уже разговор переходит в практическую плоскость. Где она такая железка? Это, кстати, к вопросу о масштабируемости.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
24 окт 06, 07:57    [3299459]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Константин Лисянский


Элементарно. Терадата конфигурируется всегда с большим количеством дисков. ..
Это 100 единиц параллелизма и 400 дисков.

А что мешает Оракл, или, скажем, DB2 сконфигурировать с 400 дисками?

Константин Лисянский

Я немного не понял, при чём тут страйпы, но базовая идея такая - если у Вас shared disk, то, как бы Вы не старались, всегда найдутся два параллельных процесса, которые захотят читать из разных блоков диска (или писать туда). Кто-то будет должен дождаться.

А что, на Терадате можно только по одному запросу за раз запускать? :)
24 окт 06, 10:24    [3300044]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
Константин Лисянский
andrey_anonymous
Это специальное выделенное оборудование или реализуется средствами обычных узлов?

И то идругое. Вставляется в узлы в виде PCI-адаптеров, плюс ещё дополнительные внешние коммутаторы. Плюс, естественно, софт для управления всем этим, который частично работает на узле, и частично на самой железяке.
Эта штука жестко завязана на TeraData или может быть использована отдельно?
Константин Лисянский
andrey_anonymous
Неудачный пример - при покупке авто я самое пристальное внимание уделяю результатам крэш-тестов, сравнительным тестам приличных изданий и прочим источникам информации. Друзьям - в последнюю очередь, просто ввиду их принципиальной субъективности :)
Понятно. Очевидно, краш-тесты автомобилей более-менее приближены к реальным условиям столкновений.
В той же мере, в какой TPC приближены к "реальной жизни".
Тут проблема в том, что две одинаковых "реальных жизни" в природе встретить очень сложно. Поэтому проще внести поправки относительно показателей, полученных на некоторой референсной методике, чем гадать как проявит себя "реальная" жизнь в конкретном окружении под конкроетной задачей.
Константин Лисянский
andrey_anonymous
Разумеется, выборки и обработка разделов безусловно параллелятся - в конкретном примере parallel не применялся, поскольку интересовали совсем другие аспекты.

Понятно. Ну, тогда это пример, на мой взгляд не показателен для данной дискуссии.
Как хотите. На мой взгляд показателен именно в том смысле, что оптимизатор oracle воспринимает и обрабатывает разделы таблицы как независимые наборы данных и имеет механизмы для объединения результатов.
Константин Лисянский
andrey_anonymous
В оракеле принято считать логический ввод-вывод, т.е. три уровня дерева+чтение блока - четыре логических чтения. Физических от нуля до четырех, наиболее вероятно - одно-два.
Ничего оригинального тут нет.

Ясно. Кстати, оптимизатор при выборе стратегий считает логический ввод-вывод или физический? По-моему, если логический, это не совсем правильно. Разница может быть ощутимой.
Оптимизатор у оракеля достаточно сложен.
Расчет ведется по LIO, но оценки стоимости зависят и от вероятности встретить нужные блоки индекса в буферном кэше, и от количества блоков, считываемых при FTS за одну операцию ввода-вывода, и от соотношения времени считывания такого "пакета" к физическому чтению одного блока (обычно блок индекса при кэш-промахе).
Поэтому, на мой взгляд, в проигрыше тут TeraData, если, конечно, не умеет оценить влияние кэш-промахов при выборе индексного метода доступа (а это можно сделать если считать именно LIO).
Константин Лисянский
andrey_anonymous
Пока я так и не увидел чего-то такого, что давало бы TeraData безусловное преимущество. Очень быстро - за счет чего?
Вряд ли быстрее чем disk io...
Элементарно. Терадата конфигурируется всегда с большим количеством дисков.
Возьмём систему начального уровня в 10 узлов. Это 100 единиц параллелизма и 400 дисков. Каждая единица параллелизма занимается обработкой своего кусочка таблицы, которая хешированием равномерно размазывается между ними.
:)
В таких условиях и oracle справится с 1млрд не дороже терадаты - берем 10 10-процессорных SMP машин, 400 дисков, соответствующим образом проектируем базу...
И ведь тоже, зараза, распараллелит :)
Выходит, все преимущество TeraData - в железках?
Константин Лисянский

andrey_anonymous
То есть shared disk не должен проиграть shared-nothing на параллельном чтении на равном количестве дисков.
но базовая идея такая - если у Вас shared disk, то, как бы Вы не старались, всегда найдутся два параллельных процесса, которые захотят читать из разных блоков диска (или писать туда). Кто-то будет должен дождаться. В случае shared nothing общего диска нет, поэтому степень праллелизма по дискам всегда будет выше.

Боюсь, тут все не так просто.
- конкурирующие сессии (многопользовательское окружение) создадут те же самые проблемы для TeraData.
- на shared disk можно при желании собрать систему, распределяющую и обрабатывающую данные похожим на shared-nothing способом, а вот обратное неверно, следовательно, shared nothing by design решает более узкий класс задач.
Константин Лисянский
Кстати, нужно ещё поискать такую аппаратную платформу, на которой работает Оракл с таким количеством дисков, чтобы она сравнилась со средней конфигурацией Терадата (возьмём к примеру, систему из 50 узлов - это 100 процессоров, 2 Терабайта ОЗУ, и 2 тысячи дисков, если я правильно сосчитал). Тут уже разговор переходит в практическую плоскость. Где она такая железка? Это, кстати, к вопросу о масштабируемости.

Первое что приходит в голову - ЦОД Oracle в Техасе.
Счет узлам идет на тысячи, если не на десятки тысяч.
Обслуживает все филиалы Oracle по миру + сдает приложения в аренду.
24 окт 06, 11:32    [3300597]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
andrey_anonymous

Первое что приходит в голову - ЦОД Oracle в Техасе.
Счет узлам идет на тысячи, если не на десятки тысяч.

Там имхо в рекламке не сказано, что все эти тыщщи узлов - это одна БД...

Ну и вот ещё навскидку про применение RAC в DWH:
http://www.dba-oracle.com/t_rac_clusters_data_warehouse.htm
24 окт 06, 12:12    [3300961]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
kmike
Там имхо в рекламке не сказано, что все эти тыщщи узлов - это одна БД...

Уверен что не одна.
Oracle clusterware, АФАИК, поддерживает не более сотни узлов.
Далее только объединять несколько систем в распределенную БД.
Однако "вендрский" clusterware еще скромнее в этом отношении.
Полагаю, что если что-то в TeraData и есть - то это тот самый байнет, заменяющий, опять-таки если я правильно понял, этот самый clusterware
24 окт 06, 12:21    [3301013]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Дык вроде байнет-это собсно среда передачи данных, ну может со своим протоколом, ибо tcp/ip в надёжной локальной сети-дорого и ненужно...

А clusterware-это библиотечки, обеспечивающие всякое там membership services..

В общем, хотелось бы услышать суть-чем "закрытое" решение от Терадаты лучше, чем та же DB2 DPF на commodity компонентах - каких-нибудь Оптеронах, что ли, с Infiniband.
24 окт 06, 12:41    [3301183]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
kmike
Дык вроде байнет-это собсно среда передачи данных, ну может со своим протоколом
Получается что не просто СПД, если еще и SMJ делает :)
Плюс объединение сотен узлов - подобного clusterware я не знаю.
kmike
В общем, хотелось бы услышать суть-чем "закрытое" решение от Терадаты лучше, чем та же DB2 DPF на commodity компонентах - каких-нибудь Оптеронах, что ли, с Infiniband.

Мне тоже интересно, вот и выспрашиваю который пост - но нас уже двое :)
24 окт 06, 12:48    [3301241]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Далось вам это clusterware... DB2, если уж на то пошло, может вообще без него жить, насколько я понимаю. Clusterware типа HACMP там обеспечивает в основном HA, а не функционирование всей системы в целом, и это хорошо, ИМХО :)

Никто ж не мешает сконфигурировать, например, 128-узловую систему DB2 в виде 4х кластеров по 32 узла.

Пропускная способность Bynet как-то тоже не впечатляет на фоне Infiniband, которых, к тому же, в каждый узел можно натыкать много :)

В общем, вопрос о преимуществах Teradata открыт :)
24 окт 06, 14:04    [3302053]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
kmike
Никто ж не мешает сконфигурировать, например, 128-узловую систему DB2 в виде 4х кластеров по 32 узла.

Мне кажется, это должно быть больше похоже на распределенную БД.
Впрочем, я мало знаю про DB2 - можно в такой системе создать единственную таблицу, которая разляжется на все имеющиеся носители и будет прозрачно (т.е. без дополнительных телодвижений со стороны приложения) обрабатываться?
24 окт 06, 14:16    [3302154]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Отож. В смысле, можно.
24 окт 06, 14:43    [3302400]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
kmike
Отож. В смысле, можно.

А что будет если одна из 32-процессорных систем недоступна?
24 окт 06, 14:44    [3302415]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Ну если запросу понадобятся данные, находящиеся на недоступном узле-то оппа.
Для этого и существует например HACMP, чтобы запустить упавшую партицию на другом узле.
24 окт 06, 14:51    [3302467]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
kmike
А что мешает Оракл, или, скажем, DB2 сконфигурировать с 400 дисками?


Ну, DB2 - это отдельный разговор. У них та же архитектура shared nothing, и, к слову сказать, они и являются основным конкурентом Терадаты в области хранилищ данных.

Но, Вы правы - и то и другое можно сконфигурировать с болшим количеством дисков.
Вопрос дальше - как размазывать таблицы по всему этому хозяйству, и в какой мере это помогает параллелизму в Оракл.


kmike
А что, на Терадате можно только по одному запросу за раз запускать? :)


Ага, вроде того :)

andrey_anonymous
Эта штука жестко завязана на TeraData или может быть использована отдельно?


Разработана специально для Терадаты и используется вместе с ней.
По-моему, в своё время Informix XPS тоже работал на серверах с bynet, но это в прошлом тысячелетии.


andrey_anonymous
В той же мере, в какой TPC приближены к "реальной жизни".
Тут проблема в том, что две одинаковых "реальных жизни" в природе встретить очень сложно. Поэтому проще внести поправки относительно показателей, полученных на некоторой референсной методике, чем гадать как проявит себя "реальная" жизнь в конкретном окружении под конкроетной задачей.


Хромает методика референсная. Если взять, кпримеру, проблему соединения 10 таблиц, то там уже такая комбинаторика, что если оптимизатор не использует эвристические подходы для отбрасывания заведомо дорогих вариантов. На маленьком количестве джойнов, оптимизатор не ставится в такие условия. В реальной же жизни больше 10 джойнов - это ежедневные запросы в хранилищах.

andrey_anonymous
Как хотите. На мой взгляд показателен именно в том смысле, что оптимизатор oracle воспринимает и обрабатывает разделы таблицы как независимые наборы данных и имеет механизмы для объединения результатов.


Это, конечно, здорово, но к параллелизму не вижу как относится. Где параллельная сортировка и параллельные джойны?


andrey_anonymous
Оптимизатор у оракеля достаточно сложен.
Расчет ведется по LIO, но оценки стоимости зависят и от вероятности встретить нужные блоки индекса в буферном кэше, и от количества блоков, считываемых при FTS за одну операцию ввода-вывода, и от соотношения времени считывания такого "пакета" к физическому чтению одного блока (обычно блок индекса при кэш-промахе).
Поэтому, на мой взгляд, в проигрыше тут TeraData, если, конечно, не умеет оценить влияние кэш-промахов при выборе индексного метода доступа (а это можно сделать если считать именно LIO).


Оптимизатор Терадата учитывает физические параметры системы, на которой она работает, то есть частоту процессоров, скорость вращения жёстких дисков, пропускную способность bynet. К примеру, один и тот же запрос на системе одного размера при прочих равных может быть выполнен по-разному (например, будут выбраны разные алгоритмы джойнов). Вряд ли Оракл так умеет. Так как он весь из себя переносимый и должен работать на всём, включая утюги и электрочайники :), он и оперирует логическими показателями, что на мой взгляд есть недостаток.
Кстати, несмотря на то, что оптимизатор "достаточно сложен", я так понимаю, народ его зинтует безбожно. В то время, как в Терадате хинтов вообще никогда не было. Типа, настоящий cost-based optimizer.

andrey_anonymous
В таких условиях и oracle справится с 1млрд не дороже терадаты - берем 10 10-процессорных SMP машин, 400 дисков, соответствующим образом проектируем базу...
И ведь тоже, зараза, распараллелит :)
Выходит, все преимущество TeraData - в железках?


Распараллелит, но как? Это к вопросу про показать план запроса.
Не совсем в железках - это всё вместе, и железки и софт. Аппаратно-программный комплекс.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
24 окт 06, 23:27    [3305168]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить