Oracle Multitenant. Part 3
Хочется подвести некоторые итоги.
Великолепная опция, одна из самых сильных после появления RAC. Отличная интеграция со snapshot, которые можно использовать для test систем вместе flahback database - я не успел про это написать, но это здорово.
IDC написала отличный отчет, где понятным для руководства языком поясняются достоинства опции. Я не писал о том, что управлять одной базой вместе 10 гораздо легче, все кто читают этот блог, это знают лучше меня, но повторить руководству может быть и не лишним.
Оказалось, что совсем недавно был замечательный семинар по теме Multitenant,но презентаций оттуда я найти не могу. Надеюсь, их скоро выложат. Update 1. Презентации уже доступны!
Теперь немного о достигнутых заказчиками результатах - опции уже год и они должны быть. В отчете IDC на странице 10 приводится такой: компания смогла уменьшить buffer cache на 25% при сохранении того же performance. Сейчас нет ничего дешевле оперативной памяти и покупать EE опцию чтобы уменьшить buffer cache это…<придумайте сравненение сами>
Единственный результаты которые я нашел - это тест Oracle. Консалидация 252 баз данных на T5.
Насколько я понял, сравнили две конфигурации - каждая БД в вирутальной машине (не указано, какая именно это была технологи, Zones или LDOM) с конфигурацией Multitenant.
Во-первых, сразу сделал вывод что кол-во TPS больше в Multitenant. Конечно есть накладные расходы виртуальных машин, но они же не 50%. Не могу понять, как у них это получилось.
Во-вторых, в случае Multitenant уменьшилось кол-во Storage IOPS необходимых для достижения того же кол-ва TPS. Это возможно только если базам данных в виртуальных машинах не хватало памяти под buffer cache. Те оба результата были получены с помощью зажимая кэша баз данных в виртуальных машинах? Более подробных реультатов тестов нет, ничего сказать нельзя.
Но самое главное, давайте посмотрим на стоимость решения. Предположим мы консолидировали БД которые использовали Partitining и Tuning and Diagnostic Pack.
Считаем по price list, процессорные лицензии:
Вариант с Multitenant:
EE Partitioning Diagnostic Tuning Multitenant Cores Core F
47,500 + 11,500 + 7,500 + 5,000 + 17,500 = 89K * 128 * 0.5 = $5, 696, 000
Вариант с множеством VM
47,500 + 11,500 + 7,500 + 5,000 = 71, 500 * 192 * 0.5 = $ 6, 864, 000
Больше $1M в терминах прайс листа! Конечно не стоит забывать, что данная экономия возникла при консолидации 252 баз данных. Хотелось бы увидеть более приближенный к жизни пример консолидации ~ 4-12 баз данных. Экономика может сильно отличаться в этом случае.
Отличная опция, DBA даже не нужно изучать что такое виртуализация, а с Exadata и про железо и storage знать ничего не нужно -)
Великолепная опция, одна из самых сильных после появления RAC. Отличная интеграция со snapshot, которые можно использовать для test систем вместе flahback database - я не успел про это написать, но это здорово.
IDC написала отличный отчет, где понятным для руководства языком поясняются достоинства опции. Я не писал о том, что управлять одной базой вместе 10 гораздо легче, все кто читают этот блог, это знают лучше меня, но повторить руководству может быть и не лишним.
Оказалось, что совсем недавно был замечательный семинар по теме Multitenant,
Теперь немного о достигнутых заказчиками результатах - опции уже год и они должны быть. В отчете IDC на странице 10 приводится такой: компания смогла уменьшить buffer cache на 25% при сохранении того же performance. Сейчас нет ничего дешевле оперативной памяти и покупать EE опцию чтобы уменьшить buffer cache это…<придумайте сравненение сами>
Единственный результаты которые я нашел - это тест Oracle. Консалидация 252 баз данных на T5.
Насколько я понял, сравнили две конфигурации - каждая БД в вирутальной машине (не указано, какая именно это была технологи, Zones или LDOM) с конфигурацией Multitenant.
Во-первых, сразу сделал вывод что кол-во TPS больше в Multitenant. Конечно есть накладные расходы виртуальных машин, но они же не 50%. Не могу понять, как у них это получилось.
Во-вторых, в случае Multitenant уменьшилось кол-во Storage IOPS необходимых для достижения того же кол-ва TPS. Это возможно только если базам данных в виртуальных машинах не хватало памяти под buffer cache. Те оба результата были получены с помощью зажимая кэша баз данных в виртуальных машинах? Более подробных реультатов тестов нет, ничего сказать нельзя.
Но самое главное, давайте посмотрим на стоимость решения. Предположим мы консолидировали БД которые использовали Partitining и Tuning and Diagnostic Pack.
Считаем по price list, процессорные лицензии:
Вариант с Multitenant:
EE Partitioning Diagnostic Tuning Multitenant Cores Core F
47,500 + 11,500 + 7,500 + 5,000 + 17,500 = 89K * 128 * 0.5 = $5, 696, 000
Вариант с множеством VM
47,500 + 11,500 + 7,500 + 5,000 = 71, 500 * 192 * 0.5 = $ 6, 864, 000
Больше $1M в терминах прайс листа! Конечно не стоит забывать, что данная экономия возникла при консолидации 252 баз данных. Хотелось бы увидеть более приближенный к жизни пример консолидации ~ 4-12 баз данных. Экономика может сильно отличаться в этом случае.
Отличная опция, DBA даже не нужно изучать что такое виртуализация, а с Exadata и про железо и storage знать ничего не нужно -)
Сообщения
Дмитрий - супер обзор,
ОтветитьУдалитьА последий вывод - это не шутка, это тенденция.
Уже выложил!
ОтветитьУдалитьhttp://www.igormelnikov.com/2014/06/oracle-multitenant-option.html
Дмитрий,
ОтветитьУдалитьматериалы нашего семинара по Multitenant уже доступны в блоге Игоря Мельникова.
Спасибо за обзор.
Борис.
Игорь, Борис - спасибо, сообщение обновил.
ОтветитьУдалить>>>сравнили две конфигурации - каждая БД в вирутальной машине (не указано, какая именно это была технологи, Zones или LDOM) с конфигурацией Multitenant.
ОтветитьУдалитьсравнивались, как я понял конфигурации Multitenant и «просто много баз в одном разделе» <- это видимо в понимании oracle означает виртуализацию )
>>>вывод что кол-во TPS больше в Multitenant.
>>>в случае Multitenant уменьшилось кол-во Storage IOPS
Три основных фактора победы Multitenant в данном тесте:
1. Multitenant база делала лограйтером на 100.000 IOPs меньше чем просто много баз вместе. В варианте Multitenant лограйтер начал лепить коммиты от разных PDBs в пачки по аж 38 штук. Что помешало использовать BATCH commit во всех индивидуальных базах для такого же эффекта неизвестно. Батчевые коммиты отменили в 12c? Или результаты красивые не получались?
2. Удалось сэкономить память двумя основными способами. 150Гб честной экономии от существенно меньшего количесва background процессов (почти 10 тысяч штук в случае «плохой» консолидации) и 150Гб от непонятно почему ужавшегося Shared Pool. Не от того ли он ужался почти в 5 раз что все (или большинство из 252 баз) использовали одни и те же sql-выражения и курсоры? Как часто такое случается при консолидации 252 разных баз? Сэкономленная память пошла на увеличение Buffer Pool (как раз +300Гб получилось) -> меньше чтений с диска -> больше TPS приложению
3. В варианте Multitenant сильно меньше background процессов, в случае плохой консолидации они приводили к потреблению отмеренных им 68% CPU вот в такой пропорции: 40 %user + 28 %sys. В случае Multitenant пропорция была другой: 58 %user + 10 %sys, естественно что пользовательским сессиям досталось больше процессора в случае Multitenant. Большой вопрос, конечно, почему Solaris не может нормально переключать контекст между жалкими 10ю тысячами процессов и уходит в 30% SYS =) думаю другая ОС справилась бы лучше )
Итого: 1. много лограйтер IOPs можно было победить и в простом варианте. 2. Если не шулерствовать с shared Pool экономия памяти получается 150-200Гб по деньгам не так дорого для двух-терабайтной машины. 3. очевидно, есть какие-то проблемы с context-switching в solaris —> можно решить уйдя в другую ОС
>>>Больше $1M в терминах прайс листа!
Опция конечно хорошая и возможно она найдет еще своих пользователей, только вот экономический эффект от нее может не быть таким красивым )
подробности теста тут —> http://www.oracle.com/technetwork/database/multitenant/learn-more/oraclemultitenantt5-8-final-2185108.pdf
Иван, спасибо за ссылку - очевидно я не смог найти ее из за бана в Гугле -). Если посмотреть на конфигурацию, используемую в тесте, там 1/3 баз данных имела размер 1Gb, другая - 5Gb, третья - 15Gb. Вряд ли это слишком реалистическая ситуация у заказчиков. На мой взгляд, Oracle хотел продемонстрировать техническую возможно поместить 252 БД в одну. Также они пишу что все базы были одинаковыми - очевидно за счет это нагрузка складывалась так хорошо. На самом деле заказчикам все равно на сколько будет там записей LGWR - нужно чтобы было не хуже чем в оригинале и стоило дешевле.
УдалитьВ документе они даже не стали считать экономику. Вот это меня и заставило ее посчитать. К сожалению, более реальных примеров за год использования мне не удалось найти. Вот к эти бы примерам, если они и найдутся, можно было применить твои выводы.