бум !

В Апреле IBM анонсировала новые SSD диски и новую дисковую полку. 
Характеристики диска вы видете на картинке ниже (и даже есть сравнение с HDD). 



Обратите внимание на Latency - 0.2 ms, очень неплохо.  Диски эти сделаны по технологии eMLC, обычно на такие диски IBM дает гарантию 5 лет непрерывной записи.  Размер сектора обещают весьма странный 528byte, что дает надежду, что на них нормально заработают redo (redo на AIX поддерживают только 512 bytes, что пока делает не очень осмысленным их использование на SSD с размером блока 4K).  Кстати эти диски на write также производительнее чем HDD ! 

Ну и такие диски теперь можно поставить в 1U полку, которая как результат выдает  400K IOPS  (100% read 4K блоком)  и содержит 11 Tb сырых данных. 



К машине класса Power 740 (16 ядер, 2 сокета)  можно подключить две таких полки. Кстати, эти же две полки можно подключить одновременно к двум Power 740 - и вуаля, стройте кластер, хотите HA, хотите RAC - всего у нас будет 4 сокета, RAC бесплатно в составе Standard Edition.

Попробую суммировать - 800K IOPS, 9GB/s bandwith, RAC включен по вашему желанию.  Ба, да это же  Exadata Half Rack  !   Вместо 11 Linux машин (4 + 7)  за которыми нужно следить и патчить  - две (одна для варианта HA).   Любая версия Oracle которая вам нужна. Все данные уже на  SSD, ничего кэшировать не нужно.  Виртуализация. Сравнение по ядрам с Exadata 1/2 - читать здесь. Сравнение стоимости  - читать здесь.  Не хватает места  ? Никто не запрещает подключить к Power  машинкам еще и  Storwise, но и это скоро не понадобится, поскольку эти полки  научатся сами перекладывать горячие данные к себе на SSD с подключенных HDD полок.

Update 1.  World Record EBS Batch Benchmark. Использовалась машинка SunFire X4270 M3 подключенная к ssd дискам. Хочу напомнить, что  SunFire X4270 M2 - это Exadata storage cell. Те в собственных тестах Oracle  переключился на ssd вместе flash и Exadata storage. 


Читать дальше...

одной строкой

Здесь можно бесплатно скачать Expert Oracle Database Architecture, 2nd Edition by Tom Kyte.  Не знаю чего вы ждете, если еще не скачали.

А.Бачин представил новый журнал, который будет во многом посвящен технологиям компании Oracle.  Много полезного, очень рекомендую.  


Читать дальше...

какая то разводка ...

Извините, но слов из песни (в данном случае Шнура) не выкинешь. Сейчас поясню на конкретном примере. Когда приходят к заказчику и говорят - смотри какая у нас зверюшка, да мы тебе еще и скидку на лицензии дадим - если кто против, то я только за ( (С) Шнур опять таки). Но заказчик пошел очень умный. И говорит  - а вот если без вашей зверюшки,  сколько мне понадобится ядер ?  И вот тут начинается какая то разводка  сплошная техническая ошибка.

Конкретный пример - документ,  написанный для очень уважаемого заказчика очень уважаемым партнером. Уважаемый партнер берет Exadata Half Rack  в котором как мы знаем стоит 48 Intel Cores и ..немедленно к ним добавляет  еще ядра на ячейках - и говорит заказчику - смотри, сколько нам нужно ядер без Exadata !  Я когда документ  увидел, сразу вспомнил что с такой логикой уже где то встречался. А вот где:

">Во-первых в Exadata Half Rack не 48, а 132 ядра. (84 на ячейках)"  см комментарии к этому посту.

Я тогда подумал, что это шутка такая, складывать ядра в storage с ядрами для СУБД, чтобы унять так сказать сотрудника IBM -), но увидев это в документе для заказчика, понял, что в это действительно кто-то верит.

Правда заключается в том, что ядра в ячейках не обрабатывают sql запросы, не умеют их разбирать. Ядра в ячейках занимаются вводом-выводом, иногда компрессией-декомпрессией - но не sql запросами.

Наверно не все знают, что в современных дисковых массивах не гнушаются ставить те же самые Intel процессоры.  См например картинку слева - это контроллер дискового массива Storwise (производства IBM). Там установлен процессор Intel Jasper Forest. Кому нибудь приходило в голову складывать его Intel ядра при сайзинге ? Пока, к счастью нет. Предчувствую  радостные крики, что благодаря sql offload и компрессии меньше приходится работать центральным процессорам. Вполне вероятно, вопрос в том насколько нам это поможет -)



Возмем, для определенности, банковскую систему. Пик ее работы по CPU (а значит и запас на который нам нужно рассчитать ядра) приходится на день, когда все операционисты заняты вводом  платежей. Кэш базы данных максимально разогрет, все данные там, работаю только процессоры работающие на стороне СУБД. Процент ожидания ввода-вывода минимален.  По большому счету мне все равно что у меня на storage - у меня не хватает CPU на парсинг, логические чтения, блокировки.   Я привел график загрузки CPU одного из заказчиков - вы можете легко увидеть, что пик загрузки совпадает с минимум ожиданий по I/O.  Увы - ядра в storage, каим бы он не бы умным,  ничем не помогают в пике работы реального приложения. Возможно повторю всем известную истину, что расчет по CPU для любой системы делается для ее пиковой нагрузки, в прочее время нагрузка на CPU никого не интересует, в конце концов уплачено, и пусть они работают.


Вы думаете, это все что я хотел сказать ?  Нет - не дождетесь. Коллеги, которые так рьяно складывают ядра из разных частей своей системы совершенно упустили из виду,  что в Exadata стоит RAC.   Мелочь какая. В рассматриваемой нами Exadata Half Rack 4 узла кластера. Те кто ходил на семинары RAC Deep Dive for Developers знают, что масштабирование в кластере зависит от числа узлов. Для двух узлов коэффициент от 1.3 до 1.7, для 4- х узлов - в районе 3. В среднем по больнице.  Это значит, чтобы достичь такой же производительности как в single instance на 36 Cores в RAC  в 4-х узлах нужно взять 48.   Известное мне исключение из этого правила  - это SAP, приложение которое масштабируется практически линейно.  К сожалению это еще не все. 48 Cores нельзя в 4-х узловом кластере держать в загрузке 100% - во первых потому что кластер будет перегружаться, во вторых если один из узлов выйдет из строя, кто-то должен взять на себя его нагрузку. Итого, эффективная загрузка 48 Cores может быть только 75%.  Итого, пересчитываем, учитывая потери на RAC и максимальную возможную нагрузку - получаем 27 эффективных Cores для монолитной системы.  Или 54 потока.  Если вы вспомните я оценил коэффициент масштабирования в x3, возможно вам повезет и он будет выше, но оценка понятна.


Машина IBM Power 740  имеет 16 Cores на борту и 64 потока, а поэтому справится с пиковой нагрузкой так же эффективно как  Exadata Half Rack. Стоимости различаются на порядок.  Как же быть со storage ? В следующем посте я покажу вам storage c 800K IOPS подключенный к к Power 740 бесплатным бонусом вам пойдет виртуализация, которой просто нет в Exadata.

Exadata плохая ? Вовсе нет, в конце дня на ней можно будет очень быстро закрыть день, быстрее чем на обычном storage (за одним исключением).  Дорогое удовольствие правда получается, проще процедуру переписать если не устраивает.   RAC плохой ? Нет конечно, изначальная идея его была что его собирают на железе, которой ничего не стоит и тогда он оказывается выгоднее, чем один большой ящик.  Просто на основе отличных технологий сейчас занимаются какими то разводками -) 


Читать дальше...