Power of Oracle BI
IBM подготовила очень хорошую статью о преимуществах систем на основе процессора Power 7 для Oracle Business Intelligence. Прежде всего в этой статье нет никакой маркетинговой истерики - если заказчик хочет Oracle BI - пожалуйста, никаких проблем. Далее описываются преимущества платформы - виртуализация, надежность. Дается принципиальная картинка референсной архитектуры. Но самое главное - есть ссылки, как начать нормальный процесс сайзинга.
Для тех, кто уже знает какая лучшая в мире платформа для Oracle BI -) - приводится специальная табличка производительность Power 770 (топовый midrange или нижний hi end как вам больше нравится -)
Обратите внимание на Total I/O bandwith: 236GB/sec. Чтобы понять много это или мало, можно обратится к этому документу. C дисков Exadata Full Rack дает 25 Gb/sec14Gb/sec, с Flash - 75.6 GB/sec без сжатия. Ну а если вся база помещается на Flash, то почему бы просто не купить SSD диски ?
Для тех, кто уже знает какая лучшая в мире платформа для Oracle BI -) - приводится специальная табличка производительность Power 770 (топовый midrange или нижний hi end как вам больше нравится -)Обратите внимание на Total I/O bandwith: 236GB/sec. Чтобы понять много это или мало, можно обратится к этому документу. C дисков Exadata Full Rack дает 25 Gb/sec
Сообщения
Наверное я недопонял или невнимательно прочитал.
ОтветитьУдалитьBI работает на сервере приложений. Посылает запрос к базе и дальше ждет ответа от базы. По результатам возвращенного ответа рисует графики и таблички.
То есть, в целом в BI системе основная нагрузка находится на стороне базы. И тут понятно, что на Экзадате 75Gb/sec это довольно хорошо. Так как Экзадата и ворочает данные.
А вот что за цифра 236Gb/sec тут я не понял. В статье про базу ничего внятного не написано.
Если это I/O просто внутри сервера на котором крутится апсервер - то это ни о чем. Основная нагрузка не там.
И про какой BI (10,11) идет речь тоже неясно. Они сильно отличаются
>в целом в BI системе основная нагрузка находится на стороне базы
ОтветитьУдалить>что за цифра 236Gb/sec тут я не понял
Это цифра для сервера обслуживающего БД, если сервер набит под завязку картами ввода-вывода. Из картинке с reference architecture мне кажется это понятно.
>BI (10,11) Они сильно отличаются
Это не так важно для сайзинга, нагрузку на БД вряд ли зависит от версии, скорее от требуемых запросов, не так ли ?
Неа, непонятно. Смотри в табличке, где 3236Gb/s у колонки заголовок Memory. Значит это не про диски и не про базу.
ОтветитьУдалитьА просто карты ввода-вывода не очень интересно по-моему.
Поясни, плиз.
>А просто карты ввода-вывода не очень интересно по-моему.
ОтветитьУдалитьЭто карты ввода-вывода и это очень интересно, поскольку понаставить дисков это уже не проблема, 1000 дисков уже ставится в дисковый массив, проблема смочь этим воспользоваться. Кстати, спасибо что отметил еще и производительность памяти - для обработки на стороне БД это также важная характеристика. У тебя кстати, есть такая цифра ? -)
Цифра по памяти? Навсидку нет, но наверное можно найти.
ОтветитьУдалитьНо все равно. 1000 дисков это хорошо, но статья-то про BI, а причем тут BI - непонятно. Наверное Cognos должен также быстро работать :)
>причем тут BI - непонятно
ОтветитьУдалитьСтатья про то, что есть железо с вполне конкурентными характеристиками производительности и достаточно интересными возможностями платформы, и есть описанный процесс сайзинга. С другой стороны у нас есть утверждение что smart scan и компрессия наше все и отсутсвие процесса сайзинга, или по крайней мере мне он неизвестен. Если тебе известен - пожалуйста ссылку на описание.
Поджожди.
ОтветитьУдалитьПричем тут BI и смартскан?
BI - это приложение, выполняющееся на сервере приложений.
Смартсканы - это то, что выполняется в Экзадате.
Не надо смешивать. Статья называется про BI. Значит то, что там написано должно иметь отношение именно к слою сервера приложения.
Про базу там мало что говорится.
Ты конкретно сказал про пропусную способность 236Gb/s, которую можно достичь на 1000 дисках.
Ок. Следуем твое логике. В Экзадате 12х14=168 дисков. Не 1000. Если бы их было 1000, то скорость была бы не 75Gb/s, а 446Gb/s.
Да, я знаю про флеши. Просто следую логике.
То, что IBM сделало такой док с сайзингом - отлично. Правда. Но все же речь идет о слое приложения, а не о базе.
Я не сильно разбираюсь в железе, но мне кажется есть тут какое-то противоречие.
>BI - это приложение, выполняющееся на сервере приложений.
ОтветитьУдалитьВ документе речь идет o reference architecture, стр 4 документа, а не только о сервере приложения.
>способность 236Gb/s, которую можно достичь на 1000 дисках.
Не совсем так. Я написал что в современном дисковом массиве можно поставить до 1000 дисков, но это даст нам не 236 Gb/s а ~1,000 Gb/sec но переварить одна 770 это будет не в состоянии, придется ставить 4 шт. В твоем расчете придется поставить 6 полных шкафов, что сделать можно.
>Но все же речь идет о слое приложения, а не о базе.
О чем идет речь в документе написано под картинкой Reference Architecture на стр 4 документа.
>Я не сильно разбираюсь в железе, но мне кажется есть тут какое-то противоречие.
Только то, что для тебя BI это прежде всего сервер приложений, а документ рассказывает обо всех компонентах системы. На картинке ты найдешь даже ASM.
Речь идет о том, что все серверные компоненты BI решения можно разместить в рамках Power систем - и сервер приложения, и БД, и Репозиторий. Если хочется можно установить поверх RAC. А можно разместить в одной физической машине в LPAR.
Дима, я понимаю что ты об этой картинке. ASM и базу я там видел.
ОтветитьУдалитьИ я понял твою мысль, что сервак позволяет теоретически прокачать 236Gb/s если ему дадут какой-нить сторадж который может это выдать. Допустим это так.
Я просто считаю, что некорректно сравнивать с Exadata, которая является DB Machine. Конкретно некорректно сравнивать ее реальные 75Gb/s c теоретическими 236Gb/s.
И, кстати ты ощибся, даже в вайтпейпе на которую ты даешь ссылку, написано что быстрые диски выдают 1,8Gb/s на ячейку, что для fullrack = 14x1.8=25.2Gb/s. Мы на тестах достигали близкие к этим показатели. Ну а теперь добавим HCC и допустим у нас база пожалась в 8 раз - вот тебе и все 75х8=600Gb/s
Док полезный, спасибо, что дал ссылку. просто сравниваются совсем разные вещи.
>ASM и базу я там видел.
ОтветитьУдалитьХорошо
>75Gb/s c теоретическими 236Gb/s.
На картинке явно написано что 236Gb/s это пропускная способность адаптеров одной машины, а современный дисиковый массив легко выдаст в несколько раз больше.
Статья про сайзинг, а не про конкретную имплементацию, поэтому я и делаю сравнение, чтобы понять а в какой области мы играем со своим сайзингом.
>вот тебе и все 75х8=600Gb/s
Ноу проблем, у нас база пожалась в 3 раза (обычную компрессию ведь никто не отменял ?) и вот тебе 236*3 = 706 Gb/s
>для fullrack = 14x1.8=25.2Gb/s. Мы на тестах достигали близкие к этим показатели
Есть какая-нибудь статистика с тестов которая может подтвердить это ? AWR, iostat ?
Поговори с Игорем Мельниковым, возможно у него осталось.
ОтветитьУдалитьЯ тебе могу дать только честное слово, что это так. Ибо сам видел :)
Дисковый массив из 1000 дисков не может делать 1000гб/сек, а только на порядок меньше!
ОтветитьУдалить>Дисковый массив из 1000 дисков не может
ОтветитьУдалитьПохоже вы правы Борис, что-то мой ibm'омский калькулятор стал привирать слишком часто. Постараюсь посчитать завтра поточннее. Спасибо !
>На картинке явно написано что 236Gb/s это пропускная способность адаптеров одной машины, а современный дисиковый массив легко выдаст в несколько раз больше.
ОтветитьУдалитьДолго смеялся. Назовите модель такого "современного дискового массива". Ни одна СХД даже из категорий Hi-End даже близко к такой цифре не приближается.
> Ни одна СХД даже из категорий Hi-End
ОтветитьУдалитьЯ с Andrey P спорил, а не с вами. А он этого не заметил -) Кажется вы правы, я переоценил существующие дисковые массивы. Я вообще в них ничего не понимаю, только никому ни слова..
>даже близко к такой цифре не приближается.
На сайте EMC для модели Symmetrix VMAX в разделе maximum system specifications дается оценка 192Gb/s. Так что таки приближается.
>На сайте EMC для модели Symmetrix VMAX в разделе maximum system specifications дается оценка 192Gb/s. Так что таки приближается.
ОтветитьУдалитьИзвиняюсь за резкость, но Вы правильно сказали. О том, что ничего не понимаете в СХД. Цифра 192Gb/s для VMAX это некая "Полоса пропускания сети Virtual Matrix" что не имеет НИКАКОГО отношения к тому, сколько МБ сможет выдать этот массив. Поменьше читайте маркетинговой чепухи, лучше посмотрите результаты тестов СХД.
>Я с Andrey P спорил, а не с вами. А он этого не заметил -)
ОтветитьУдалитьДа нет, я то как раз заметил, что есть какая-то фигня - и вся моя переписка об этом. Просто я ни раз не спец в СХД, поэтому поверил тебе, что есть массивы, которые могут столько выжать, хотя ни разу не встречал на картинках такого.
>Цифра 192Gb/s ...не имеет НИКАКОГО отношения к тому, сколько МБ сможет выдать этот массив.
ОтветитьУдалитьЕще раз посмотрел сайт EMC. 1 VMAX engine обладает полосой пропускания 24Gb/s, можно поставить всего 8 таких engine. 24 * 8 = 192.
Если вы утверждаете что полоса пропускания никак не коррелирует с тем сколько MB может выдать массив - дайте цифру сколько выдает 1 engine по вашим данным.
В том же документе дается харакетристика Internal Data Rate до 2Gb/s на диск (?) сразу для нескольких типов дисков (FLASH и SATA).
>Да нет, я то как раз заметил
ОтветитьУдалитьОбидно, я так старался -))
Тут вот какая штука. По whitepaper full rack дает 25Gb/sec (ты прав, не 14 как я написал), и это честное чтение с дисков, но вот данные про чтение с flash все таки явно предполагает что данные закэшированы. Производители дисковых массивов не дают данных о производительности при чтении из кэша. Так что если ты хочешь сравнивать 75Gb/s то нужно как-то найти данные, какая будет призводительность дискового массива если данные берутся из кэша.
Но даже это похоже не самое главное. Я почему спросил у тебя про графики. Не уверен что есть много приложений которые могут 'сожрать' столько данных в сек.
>Дисковый массив из 1000 дисков не может делать
ОтветитьУдалитьЯ нашел тесты на DS8000 из которых можно предположить что полностью забитый дисками массив даст порядка 50Gb/s. Еще раз - это апросикмация тестов, а не теоретический расчет. Что остается за этой цифрой - какое время отклика будет на операцию чтения и каков размер этой самой операции чтения. Так что даже эту цифру можно опротестовать -)
Спасибо за замечание!
>Но даже это похоже не самое главное. Я почему спросил у тебя про графики. Не уверен что есть много приложений которые могут 'сожрать' столько данных в сек.
ОтветитьУдалитьТы забыл, что смысл работы Экзадаты не в том чтобы завалить приложение данными. Она делает SmartScan - из миллиардов записей выбирает только небольшое подмножество, что попадают под условие или вообще агрегирует.
То есть, в приложение вообще может вернуться 1 запись после скана миллиарда записей. А в этом случае чем быстрее сканируется, тем быстрее будет результат.
>смысл работы Экзадаты
ОтветитьУдалитьЯ плохо/неправильно выразился. Приложений, которые могут 'накормить' Exadata такой работой
А в чем тут проблема?
ОтветитьУдалитьНаверное одна сессия (запрос) редко сканирует терабайт за раз. А если у тебя 100 или 1000 сессий, каждая из которых сканит по 10 гигов, то почему бы и нет?
>то почему бы и нет?
ОтветитьУдалитьПо моему мнению для диска (SAS/SATA) есть большая разница - сканирует его 1 сессия или 1000 одновременно. Это не так ? Мне и хочется понять, есть ли реальные приложения, для которых достигается 25Gb/s. Что эти приложения делают. Сколько там сессий.
Чуть выше мы говорили про 236Gb/s, а теперь выясняется, что и 25 не загрузишь :)
ОтветитьУдалитьБыли бы ресурсы, а загрузить не проблема. Поудаляй индексы и пожалуйста, например.
У нас было тестирование, когда достигались похожие цифры, правда там сессий было более 10000
10000 сессий одновременно дергающих одни и те же диски а диски продолжают выдавать максимальную производительность ? Те у них бесконечно быстрое перемещение головки ? Это звучит странно, нет ?
ОтветитьУдалитьЧестно говоря я не знаю, как работает приоритезация и очереди на ячейках, может быть тут и не важно сколько сессий.
ОтветитьУдалитьЯ просто говорю о том, что цифры близкие к 25Gb/s
>цифры близкие к 25Gb/s
ОтветитьУдалитьЯ тебе верю. Просто все тесты которые видел я были основаны на чтении из flash cache а не с дисков. Просто авторы тестов редко когда хотят исследовать что на самом деле происходило. Поэтому мне и хотелось получить статистику с cells.
Игоря лучше спросить.
ОтветитьУдалитьЯ сам делал засечки, когда не использовался флешкеш и было 18Gb/s
Но я не ставил задачу именно понять достигаются ли 25 гигов. просто засек в какой-то момент времени.
>огда не использовался флешкеш и было 18Gb/s
ОтветитьУдалитьКак ты это делал ? куда ты смотрел чтобы это понять ?
Sql Monitor показывает по запросу.
ОтветитьУдалить>Sql Monitor показывает по запросу.
ОтветитьУдалитьЯ не понял. Для тупых - что такое SQL Monitor, что он показывает ?
SQL Monitor(ing) - это офигенный тул (часть EM), который позволяет на Exadata (и, возможно, не только) смотреть как отрабатываются запросы по каждому шагу плана и пишет разную статистику.
ОтветитьУдалитьНапример по запросу он может показать сколько он выполнялся, какие шаги были, сколько данных было прочитано на каждом шаге и т.п.
Ну, собсно, даже без него, зная размер таблицы (dba_segments) и зная сколько идет по ней фулскан типа sum(a) можно посчитать сколько было прочитано за секунду.
Если таблица весит 10 тер, то, понятно ни о каком флеше тут речь не идет (да и по вьюхам это видно)
>SQL Monitor(ing)
ОтветитьУдалитьты имел в виду Real Time SQL Monitoring, http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/instance_tune.htm#CACGEEIF
это не часть EM, а возможность БД, и работает конечно где угодно.
>- это офигенный тул
+1
>сколько данных было прочитано на каждом шаге
Я тебе верю. Ты убедительно рассказываешь. Конечно, если бы я бы был каким-то меркантильным кю, я бы конечно спросил как при 10000 сессиях один запрос типа sum выдает 18gb/s и не значит ли что общую производительность также можно умножить на 10000, но я не буду. Я мог бы сказать что таблица 10Tb после сортировки и сжатия полностью помещается в flash cache, но я не меркантильный.
Доверие для меня гораздо важнее. Важнее любой статистики, сриншотов, AWR, iostat и прочей ерунды -)
Нее. Я про графический тул, хотя, возможно он использует тот мониторинг, на который ты дал ссылку.
ОтветитьУдалитьСтранно, что я даже нагуглить не могу внятный скриншот тулза о котором я говорю. Что то похожее вот:
http://www.interface.ru/iarticle/img/25998_60225557.jpg
Вернее, наверное это оно и есть, только тут как минимум нет коэффициента Cell offloading, значит это не Exadata.
10000 сессий были у Игоря. Я ему верю. Это я могу лохануться, он врядли. Я гонял запросы по одному. В одну сессию.
Это были 10 тер, 10 несжатых тер. Сжатыми они занимали гораздо меньше места, но скорость скана была такая же, что косвенно подтверждает...
10 тер во флеш по любому не поместятся.
AWR я не снимал, так как цель была не в этом. 18Gb/s просто появились как побочный эффект экспериментов
>> смысл работы Экзадаты
ОтветитьУдалить> Я плохо/неправильно выразился.
> Приложений, которые могут
> 'накормить' Exadata такой работой
есть многое на свете, друг горацио, чего не снилось ни вам, ни вашим мудрецам.
иными словами - оперируй фактами. нет фактов - не оперируй :) ибо нефиг :)
ranger/ESSC
>Это были 10 тер,
ОтветитьУдалить>Я гонял запросы по одному
Андрей, у меня нет сомнений в заявленных в pdf файле цифрах. Oracle никогда не врет, я проверял много раз. Ты тоже вряд ли можешь перепутать цифры. Вопрос в том, что если одна сесссий достигает 18Gb/s то что будет когда сессий будет 10 или 100 ? Те интересна была бы статистика с приложения. см например что получали в своем время
http://www.google.com/url?sa=t&source=web&cd=2&ved=0CCgQFjAB&url=http%3A%2F%2Fwww.wintercorp.com%2Fwhitepapers%2FMeasuring%2520the%2520Performance%2520of%2520the%2520Oracle%2520Exadata%2520Storage%2520Server.pdf&rct=j&q=%20exadata%20perfomance%20test%20winter%20corp&ei=JD98ToDHAqj04QTpiqXHDg&usg=AFQjCNFEf8pUqMj5A_IQO3EnZsuggE5TUA&sig2=paQHx1Sk0fkHdVdonDorgw&cad=rja
когда было еще 14 Gb/s. Как я писал, да, достигается, но не все время и на весьма специальной нагрузке. Если я правильно понял число сессий там было маленьким. Вот все это мне и было бы интересно.
Ок. Наверное я нечетко выразился.
ОтветитьУдалитьУ нас было много тестирований.
Там где участвовал я лично был случай когда я гонял в одну сессию фулсканы по 10 терабайтной таблице - и у меня получались скорости в районе 18Gb/s
В тоже время у Игоря было совсем другое тестирование с другими профилями нагрузу - там было много сессий с которткими и длинными запросами и он смотрел суммарную нагрузку на ячейки, и вот она была больше, чем 18gb/s. Не знаю, сохранились ли у него доки - это к нему больеш вопрос.
*** Дальше моя спекуляция***
Мое ощущение, возможно неправильное, что для ячейки не важно сколько реально сессий просит с нее данные, скорее всего она про это вообще не знает, а просто отрабатывает запросы на тех блоках, что ей присылают сверху.
Какая ей разница скнировать 10Tb от одной сессии или 10 тер от 1000 сессий, если все равно блоки размазаны по ячейкам?