суббота, 23 апреля 2011 г.

Такой большой и очень умный

Многие многоопытные администраторы баз данных Oracle, рассуждая о возможном использовании флэш модулей, расположенных на ячейках Экзадаты, демонстрируют действительно незаурядные фантазии ;) Я попробую показать, что лучше всего эти модули использовать именно так, как по умолчанию их кон фигурируют инженеры Oracle, т.е. как Smart Flash Cache. Но сначала всё-таки давайте узнаем, что же это такое.
Что бы было наглядно понятно, чем кэш в ячейках Exadata отличается от кэша в обычном дисковом массиве, приведу небольшой и хорошо зарекомендовавший в мире ИТ пример.  

Когда размер имеет значение
Всем известно, что все современные процессоры имеют несколько уровней кэш. Самые производительные оснащаются КЭШем сразу трёх уровней. Что бы показать тенденцию рассмотрим процессор Intel Xeon X7560, используемый в Exadata модели X2-8.

Уровень
Размер
Латентность (циклы)
L1
32+32 KB на ядро
4
L2
256 KB на ядро
9
L3
24 MB всего (3 МБ на ядро)
63


Вывод из этого прост и вполне очевиден – чем дальше уровень кэш от места, где непосредственно используются данные, тем более медленная, а значит, дешевая память в нем используется. Но главное, все же ни в этом – разница в размерах этих КЭШей составляет порядок.
Если сопоставить размеры оперативной памяти в серверах базы данных с размером Flash Cache на ячейках Exadata, то мы получим следующее:

Модель
Конфигурация
Размер RAM
Размер Flash Cache
X2-8
FULL
2TB
5.3TB
X2-2
FULL
768GB
5.3TB
X2-2
HALF
384GB
2.6TB
X2-2
QUARTER
192GB
1.1TB

Учитывая, что размер буферов СУБД для OLTP приложений в таких конфигурациях вряд ли будет превышать 20-30% от общего размера памяти, мы как раз и получаем те самые доказанные практикой соотношения в порядок. При этом, следуя приведенным выше канонам стоимость памяти на основе FLASH существенно дешевле динамической памяти, используемой в серверах БД.
В этой связи не совсем понятно, какой смысл приобретать high-end дисковые массивы с кэш из дорогой динамической памяти, максимальный размер которой измеряется сотнями гигабайт, что сопоставимо с конфигурируемым размером кэша буферов?! С моей точки зрения в таких случаях гораздо эффективней потратить деньги на увеличение оперативной памяти серверов, а в дисковом массиве оставить размер кэш, который покроет потребности для обеспечения быстрых операций записи.
Но вернемся в к Экзадате, которая следуя “классическим канонам”  кэширования, имеет правильный кэш.  Вторая отличительная особенность этого кэш угадывается в его названии - SMART FLASH CACHE.

Почему кэш SMART?
Строя интеллектуальный сторадж, который умеет обращаться с сохраняемой на нём информации ни как с обезличенным набором битов и байтов, а как с данными СУБД Oracle, было трудно отказаться от соблазна “интеллектуализировать” и алгоритм кэширования.
Ячейки Exadata относятся к кэшированию данных избирательно, отдавая приоритет блокам, к которым с большой вероятностью потребуется повторный доступ. Здесь работают во многом похожие алгоритмы на те, которые определяют правила сохранения данных в КЭШе буферов экземпляра СУБД.
Поэтому данные, которые читаются большими порциями, кэшироваться не будут, если только на уровне сегмента не определить атрибут CELL_FLASH_CACHE KEEP. Всё очень знакомо, неправда ли? "Издревле" подобной операцией пользовались для того, что бы закрепить блоки определенного сегмента в КЭШе экземпляра самой СУБД.

CREATE TABLE pt (c1 number)
  PARTITION BY RANGE(c1)
   (PARTITION p1 VALUES LESS THAN (100)
     STORAGE (CELL_FLASH_CACHE DEFAULT),
    PARTITION p2 VALUES LESS THAN (200)
     STORAGE (CELL_FLASH_CACHE KEEP));

ALTER INDEX tkbi STORAGE (CELL_FLASH_CACHE NONE);

У CELL_FLASH_CACHE  может быть три значения, по названиям которых можно угадать политики, которые они определяют - KEEP, NONE, DEFAULT.  А еще есть хинты…
Я не буду в подробностях вдаваться во все тонкости работы SMART FLASH CACHE, скажу лишь, что эффективность его работы действительно потрясающая.
Посмотрите на AWR отчеты Ваших OLTP систем и найдите время, которое тратится на одиночную операцию чтения. Сколько? На практике испытаний с использованием high end дисковых массивов знаю, что эта величина чаще всего крутится около значения в 5мс. (Ну и где эффект быстрого, но маленького КЭШ этих дорогих железок?)
А теперь давайте глянем на пример тяжелого испытания OLTP системы на Exadata X2-8. Около 15 тысяч одновременных сессий с СУБД, выполняющих около 4M logical reads/с при 14K IOPS для всей СУБД.



Пусть Вас не вводит в заблуждение число 1мс – если не округлять, то у нас получится 6192с/7445684 = 0.83мc. (Посчитал и понял, что пример неудачный :) - чаще всего этот показатель составляет около 0.7мс)
Не почувствовать разницу легко, если она почти на порядок :)

А еще флэш память Exadata ячеек можно сконфигурировать как диски ASM… И в этом месте у администраторов СУБД Oracle начинают чесаться руки. 

“Иногда лучше молчать, чем говорить” (с) <- это я про себя.
Сразу следуют вполне естественные предложения:
-          “А давайте на ASM Flash-дисках разметим редологи!”
-          “А можно создать на нем табличное пространство для горячих объектов?”
-          “А что если туда забабахать Database Smart Flash Cache?”
-         
Всё это конечно можно, но зачем? Oracle создал действительно сбалансированную конфигурацию вплоть до тонкостей. Не трогайте ничего, до тех пор, пока действительно не будете понимать, к каким последствиям приведут Ваши действия.

И все же?! А что если редологи туда? В ответ приведу данные из того же отчета. Cессии на экземпляре генерировали redo порядка 6МБ/с.



А если посчитаем без округлений: 2126c/3458313 = 0.61мс!!!
- Ууупс! А чего так быстро? А всё дело в другом КЭШе :) В обычном кэше, который есть на большинстве дисковых контроллеров. На дисковых контроллерах, которые находятся в каждой ячейке Exadata есть КЭШ из динамической памяти размером 512МБ. Итого 512МБ * 14 ячеек = 7ГБ на конфигурацию FULL. Оказывается вполне достаточно, что бы покрыть потребности в записи такого объема redo (стоит учесть, что второй узел в этом тесте генерировал почти столько же redo).
 И только не нужно меня убеждать в том, что скорость записи на FLASH будет превосходить скорость записи в динамическую память :)

Поехали дальше… 
Как на счет табличного пространства с горячими объектами? Наверное, будет работать быстрее, чем с FLASH CACHE, но только до тех пор, пока FLASH CACHE не разогреется. Относительно времени жизни экземпляра СУБД Oracle это преимущество будет несоизмеримо мало, а после кратковременной эйфории начинется глубокое похмелье - на FLASH дисках данные же нужно дублировать! В результате для горячих объектов будет использоваться в два раза больше дорогой FLASH памяти, что существенно снижает эффективность ее использования. Этого мы добивались?

Ну а желание разместить на FLASH дисках ячеек Database Smart Flash Cache легко бьется другим конём – давайте подумаем и сопоставим время, которое необходимо для обращения к FLASH-карте размещенной в слоте PCI из самой ячейки Exadata со временем, которое необходимо для обращения к ней же с внешнего сервера БД. Огромная разница в латентности при практически совпадающем функционале.

Еще варианты будут?