RuOUG
Единственное в чем я не согласен с Юрием, это с его определением, что Exadata storage выполняет sql. Возможно это чисто теоретический спор, однако мне он кажется важным.Давайте посмотрим, что Oracle понимает под выполнением sql запроса. Слева, вы видите семантическую диаграму.
Думаю, что большинство согласится, что parsing выполняет ядро СУБД Oracle. К фазам Optimization/Row Source Generation кажется тоже нет претензий - делается на стороне СУБД. Надеюсь пока все согласны.
Итак, мы подошли к Execution. Насколько я понял Юрия, поскольку Exadata storage выполняет I/O это и позволяет говорить, что она выполняет sql. Однако, берем определение: During execution, the SQL engine executes each row source in the tree produced by the row source generator.
Еще раз - все делает SQL Engine. Нужно ли говорить, что нет SQL Engine на стороне Exadata storage ? Exadata storage даже не получает текстов sql запросов, а только условия фильтрации и/или битовые маски для join. Если же аргумент 'Exadata storage делает ввод-вывод' для вас достаточен, чтобы решить, что это выполнение sql запроса, тогда любой storage, который делает ввод-вывод также выполняет sql запросы -)
Сообщения
Два попроса:
ОтветитьУдалить1) Когда Exadata научилась выполнять count, sum, agv, dense_rank и пр?
2) Чем Exadata с Flash Cache лучше обычного Оракла с Flash Cache для OLTP приложение?
Exadata с Flash Cache лучше обычного Оракла с Flash Cache хотя бы тем, что
ОтветитьУдалить- в Exadata он write-back,
- там можно держать redo,
- там можно располагать датафайлы и тем самым смартсканнить флешкэш.
>Exadata с Flash Cache лучше обычного Оракла с Flash Cache
УдалитьА чем Exadata с Flash Cache лучше чем разместить БД на SSD?
SSD - write back
там можно держать redo
там можно располагать датафайлы и скорость ввода-вывода такова, что нет смысла ничего смарсканить при цене этой фичи
Дмитрий, странный инжденер, но знатный тролль ;-)
Удалить>> А чем Exadata с Flash Cache лучше чем разместить БД на SSD?
- Тем, что это будет обычный "cached" со всеми латчами и пр.
- Задействованы всё те же CPU - в Exadata это нагрузка передается другому серверу
- смарт скан умеет не делать работу вообще (storage indexes), вместо того чтобы сканнить террабайты на SSD
Ага , я то же жду ответа на этот вопрос )
Удалить>но знатный тролль ;-)
Удалить>со всеми латчами и пр.
Делаем direct patch read и обходимся без латчей (по вашей терминологии)
>адействованы всё те же CPU -
на ввод-вывод - нет
>storage indexes
А меня partitioning устраивает по скорости, объем подберу так чтобы проблем не возникало
> Делаем direct patch read и обходимся без латчей (по вашей терминологии)
Удалитькстати, строго говоря, в этом случае тоже без латчей не обходится. попробуй догадаться каких именно :) это тебе задачка как знатоку Oracle :)
ranger.
>попробуй догадаться
Удалить>ranger
Попробуй забороть свои детские комплексы.
>- Тем, что это будет обычный "cached" со всеми латчами и пр.
>- Задействованы всё те же CPU - в Exadata это нагрузка передается другому серверу
>- смарт скан умеет не делать работу вообще (storage indexes), вместо того чтобы сканнить террабайты на SSD
Пара комментариев:
1) Есть мнение, что сматр-скан данным, расположенным на Flash, да еще и для OLTP особо не нужен, там такого рода запросы с горячим данным (мы же горячие данные на flash хотим положить?) большая редкость.
2) По поводу CPU - не аргумент, экзадатовские CPU тоже не манна небесная, которая с неба упала, нагрузку другому серверу можно передать расширив RAC (за счет экзадатовских нод), он же у нас масштабируется. Или уже не масштабируется и поэтому стало выгоднее городить огород из дополнительных специализированных нод?
С остальным согласен. На первый вопрос кто-нибудь ответит?
> На первый вопрос кто-нибудь ответит?
УдалитьДокладчик ошибся. Функции lag и dense_rank не оффлоадятся.
Как ошибся он и в том, что DML не оффлоадится. Offloadable части плана запроса оффлоадятся в DML также как и в DDL и в SELECT.
>>storage indexes
Удалить>А меня partitioning устраивает по скорости, объем подберу так чтобы проблем не возникало
Это равносильно "А меня всё устраивает по скорости, я так круто всё задизайню, что проблем не возникнет". Если всё хорошо, то ничего покупать не надо.
Я еще таких систем не видел, чтобы всё хорошо. Но это потому что их не Дмитрий дизайнил :-(
>>адействованы всё те же CPU -
>на ввод-вывод - нет
Разделим случаи примерно на OLTP и остальное.
В чистом OLTP надо запрашивать случайные одиночные блоки данных. Exadata здесь выступает как хранилище с быстрым временем отклика. Даже если построить такое хранилище на SSD, то даже так остаются преимущества в том что это Оракл стек, в поддержке, в том что offloading бэкапов и прочее прочее, что в любом случае будет вокруг OLTP.
Однако чистого OLTP никто в глаза не видел. И тогда, если нужен SmartScan, то, очевидно, его невозможно заменить SSD. Это передача нагрузки с DB уровня, ядра на DB освобождаются и уже не нужен IBM Power. В случае с SSD сканировать, декомпрессить, фильровать будут ноды DB. При этом внутренний параллелизм и передача уже готового результата. Плюс умение не делать работу вообще, в частности storage indexes.
>> Или уже не масштабируется и поэтому стало выгоднее городить огород из дополнительных специализированных нод?
УдалитьМасштабируется не RAC, а приложение. Даже если приложение хорошо масштабируется SmartScan будет полезен. А если не масштабируется, то и подавно.
>> Есть мнение, что сматр-скан данным, расположенным на Flash, да еще и для OLTP особо не нужен, там такого рода
>> запросы с горячим данным (мы же горячие данные на flash хотим положить?) большая редкость.
Если это чистое OLTP, то может SmartScan там был бы и не нужен. Обычно OLTP это только часть смешанной нагрузки.
>Функции lag и dense_rank не оффлоадятся
УдалитьНу давайте уже будем до конца честными и скажем, что не оффлодятся вообще никакие агрегатные и аналитические функции.
>Масштабируется не RAC, а приложение.
А RAC - не приложение? К нему понятие масштабируемости не применимо?
>Если это чистое OLTP, то может SmartScan там был бы и не нужен. Обычно OLTP это только часть смешанной нагрузки.
Ну, с тем, что это не помешает я согласен, но стоит ли оно того, если большую часть времени оно будет простаивать и выполнять роль обычного рейд-массива. Ведь смешанная нагрузка разная бывает, можно раз в месяц по выходным гонять отчет и тоже называть это смешанной нагрузкой.
>>Масштабируется не RAC, а приложение.
Удалить>А RAC - не приложение? К нему понятие масштабируемости не применимо?
имхо некорректная точка зрения, ибо рак сам по себе вряд ли полезен (рак, так сказать, ради рака).
>>Если это чистое OLTP, то может SmartScan там был бы и не нужен. Обычно OLTP это только часть смешанной нагрузки.
>Ну, с тем, что это не помешает я согласен, но стоит ли оно того, если большую часть времени оно будет простаивать и выполнять роль обычного рейд-массива.
кстати, рискну предположить, что относительно недорогого рейд-массива, так что и с этой точки зрения может быть оправдано.
ranger.
>кстати, строго говоря, в этом случае тоже без латчей не обходится.
УдалитьНу и кого они волнуют эти латчи? Это главная проблема приложений - конкуренция за латчи при direct path read?
Кстати, строго говоря, PCI Flash торчащий в экзадате - это обычное блочное утсройство для Linux, соответственно для Oracle DB это обычный диск, данные с которого надо сначал скопировать в SGA\PGA СУБД, прежде чем сделать с ними что-то блолее осмысленное. Итого, имеем эфемерный выигрыш на full scan'ах которые могут быть отСмартСканены, а на одноблочных индексных чтениях, коих даже в самых гибридных и уродских OLPT, которые мне приходилось видеть, все равно около 90%, имеет те же яйца "вид с боку".
>- смарт скан умеет не делать работу вообще (storage indexes), вместо того чтобы сканнить террабайты на SSD
Ощутимый выхлоп от этого будет только тогда, когда:
а) Известен характер запросов к данным
б) Данные при загрузке предварительно отсортированы таким образом, чтобы учесть пункт а
Если данные вставляются достаточно случайным образом, то ощутимого выигрыша перед другими механизмами кластеризации данных - нет. Та же хрень существует и в Netezza - называется Zone Maps, и там точно такие проблемы - чтобы почувствовать эффект от них, данные надо сортировать при загрузке.
>> а на одноблочных индексных чтениях, коих даже в самых гибридных и уродских OLPT, которые мне приходилось видеть,
Удалить>> все равно около 90%, имеет те же яйца "вид с боку".
А на что более всего жаловались люди, ты спрашивал? Скорость разных операций и отчетов может волновать их больше, чем твои 90% одноблочных чтений. Когда на табблицу нельзя добавить индекс, потому что их уже там 20, а без этого индекса операция занимает в 5 раз больше времени, чем необходимо.
Вот для этого и нужна Exadata - изменять работу очень тяжелые операций, чтобы они стали быстрыми и максимально ускорить одноблочные чтения для OLTP компоненты. Ускоряется эти одноблочные чтения просто быстрым кешем с write-back, ничего сверх секретного и ничего нового тут еще не придумали. Ускорение же full сканов естественно куда более "умная", навороченная часть, что вообщем и есть соль Exadata.
> Делаем direct patch read и обходимся без латчей (по вашей терминологии)
ОтветитьУдалитьможно поподробнее о прямом чтении патчей? :)
ranger.
>имхо некорректная точка зрения, ибо рак сам по себе вряд ли полезен (рак, так сказать, ради рака).
ОтветитьУдалитьИ да, и нет. Если приложение не масштабируется, даже если платформа позволяет, то это конечно проблема прилоежения. Но если платформа не позволяет, то приложение не при чем, так ведь? Если бы дело всегда было лишь в приложениях, то не было бы необходимости в создании Exadata, все сидели бы на RAC и радовались.
Так что вопрос остается в силе, почему вдруг для OLTP приложения (с DWH понятно) нагрузку выгонее распределять не горизонтально - другой ноде RACа, а вертикально - вниз по стеку на Exadata Cell?
Единственный аргумент с которым я могу согласится - это случай, когда по той же системе гоняется тяжелая отчетность (что уже давно является моветоном), где SmartScan может пригодится.
>> Если бы дело всегда было лишь в приложениях, то не было бы необходимости в создании Exadata,
Удалить>> все сидели бы на RAC и радовались.
Пожалуйста, вопрос только в цене. Чтобы добиться такого же эффекта как в Exadata надо гораздо больше ядер в обычном RAC, и гораздо более масштабный storage. Если подобное решение собирать без Exadata storage, то это будет в 10 раз более дорогое монстрообразное решение. Но и в этом случае не добиться таких эффектов Exadata, как отсутствие работы в некоторых случаях (storage indexes) и внутренний параллелизм на serial операциях с точки зрения DB node. При этом Exadata весь стек родной.
>> вопрос остается в силе, почему вдруг для OLTP приложения (с DWH понятно)
>> нагрузку выгонее распределять не горизонтально - другой ноде RACа,
>> а вертикально - вниз по стеку на Exadata Cell?
Для абстрактного чистого OLTP никакого распределения вертикально не требуется кроме быстрого одноблочного случайного чтения и быстрой асинхронной записи. Именно это Exadata и предлагает, плюс еще много всего интересного, что скорее всего понадобится, т.к. чистого OLTP никто в глаза не видел.
Немного по теме:
ОтветитьУдалить>>Насколько я понял Юрия, поскольку Exadata storage выполняет I/O это и позволяет говорить...
Дмитрий, очевидно, упрощает содержимое доклада, намеренно упуская очень важную часть SQL Execution - Smart I/O, решение о применении которого принимается на этапе Execution выполнения запроса, так же, как и выбор для доступа к данным метода direct path read, например
Доклад, действительно, продуманный, с описанием и плюсов, и минусов. Более того, по словам автора доклада Юрия Пудовченко, его работодатеть предоставляет возможность проведения бесплатных тестов приложений на своих Exadata-х, и очередь совсем небольшая
Было бы любопытно увидеть сравнительные тесты какого-нибудь практического приложения на Exadata и IBM Power, например - ведь только практика может являться критерием истины ?)
Немного по теме:
ОтветитьУдалить>>Насколько я понял Юрия, поскольку Exadata storage выполняет I/O это и позволяет говорить...
Дмитрий, очевидно, упрощает содержимое доклада, намеренно упуская очень важную часть SQL Execution - Smart I/O, решение о применении которого принимается на этапе Execution выполнения запроса, так же, как и выбор для доступа к данным метода direct path read, например
>> Exadata storage даже не получает текстов sql запросов, а только (!!!) условия фильтрации и/или битовые маски для join
- отлично описано важнейшее отличие от любого storage - видимо, неосознанно ;)
А доклад, действительно, продуманный, с описанием и плюсов, и минусов. Более того, по словам автора доклада Юрия Пудовченко, его работодатеть предоставляет возможность проведения бесплатных тестов приложений на своих Exadata-х, и очередь совсем небольшая
Было бы любопытно увидеть сравнительные тесты какого-нибудь практического приложения на Exadata и IBM Power, например - ведь только практика может являться критерием истины ?)
>>>Было бы любопытно увидеть сравнительные тесты какого-нибудь практического приложения на Exadata и IBM Power, например - ведь только практика может являться критерием истины ?)
Удалитьпрекрасное предложение! я бы тоже с удовольствием на сравнительные тесты посмотрел =) не подскажете, где их для экзадаты найти?
Смысл их сравнивать? Это разные вещи и не конкуренты. Упрощенно говоря IBM Power это CPU, тогда как Exadata это "умный сторадж". Легко придумать задачу (мы ведь говорим о БД Оракл), которая бы решалась только на Exadata и никак на IBM Power. Но сильно сложнее ту, которая бы решалась только на IBM Power и не решилась на Exadata.
Удалить> прекрасное предложение! я бы тоже с удовольствием на сравнительные тесты посмотрел =) не подскажете, где их для экзадаты найти?
Удалитьсначала гоните сравнительные тесты для power :)
ranger.
>>>сначала гоните сравнительные тесты для power :)
Удалитьhttp://bit.ly/US9Xcx -- выбирайте любой )
>>>Смысл их сравнивать? Это разные вещи и не конкуренты.
Удалитьсогласен. но жизнь показывает, что их сравнивают постоянно все кому не лень )
вот отличный пример: http://www.crn.com/slide-shows/data-center/240004454/five-companies-that-dropped-the-ball-this-week.htm
Добрый день.
ОтветитьУдалитьА Вы все это тут пишете. А кто-нибудь в глаза-то видел эту EX-adata-ОТИКУ?
Буквально 21 у меня закончились тесты SPARC SUPER Cluster'а, причем на свой страх и риски (по настоянию Oracle)тесты проводили с переводом реальной нагрузки на узел SuperCluster'а без какой-либо модификации настроек. Впечатление очень, очень положительное. IO как класс полностью исчезло. Из-за конфиденциальности не могу выложить отчет, но наша система смогла утилизировать HDD только на 10%. Т.е. на выходе из сервера было 19000 IPOS до HDD-дисков доходило только 1500 IOPS, по 500 IPOS на каждый Storage CELL. Ничего из фитч не использовали, т.к. не было цели и времени. В отличии от классической системы, как мы сейчас используем, FlashCache более избирательный и интеллектуальный чем "тупое" кеширование всего подряд, которое приводит к автоматическому решению следующих задач эксплуатации
- постоянному перегрузу кеша, нет необходимости его жесткого деления 'разрезания' между БД или хотами,
- не требуется специализированного подхода к выделению и переносу на SSD отдельных горячих-дата файлов и REDO
- нет проблем с понимание принципов работы динамического Tire-йнга и всяких Динамических пулов
- постоянное низкое время ответа при любой нагрузке, поверьте мы пригрузили хорошенько эту систему
- простота управления..
Теперь, правда, Oracle проявляет какую-то полную невменяемость как продавцы, но это уже совсем другая история...
Удачи...
Сергей...
P.S.
Тебе могут много расказывать о хорошей жизни какие-то дяди и тёти в БЛОГАХ и СТАТЬЯХ но только когда сам делаешь тесты и пробуешь "еду на вскус" ты можешь сказать, что тебе это подходит...