In-Memory Option меняет вид следующей Экзадаты

Ранее я уже описал свои предположения о технических характеристиках Экзадаты Х5-2.

Добавим несколько слов о том, как опция In-Memory изменит облик следующего поколения Экзадат (чисто мои предположения, возражения приветствуются). 

IMO реализована в виде специализированных процессов (в количестве CPU_COUNT/2),

которые после старта инстанса строят Columnar Store в IM-пуле (оперативной памяти) сервера.

Очевидно, что процесс построения CS 

-  требует много ЦПУ

- предельно сильно нагружает ввод-вывод, потому что выполняется полное табличное сканирование больших объемов данных. 

- и сопровождается большим объемом блокировок из-за массовой вставки блоков в буферный кэш.

Оракл не зря ограничил количество этих процессов величиной CPU_COUNT/2, чтоб оставить место для работы остальных процессов БД. Также очевидно, что сканирование больших сегментов + подъем их в память на серверах стандартной архитектуры приведет к 100%+ загрузке ввода вывода на длительный период - на много часов, потому что требуется просканировать все исторические таблицы, поднять их в память и построить из них CS-сегменты.

После старта инстанса эта работа будет происходить на фоне активных чтений с дисков в буферный кэш (в интересах OLTP-приложений), хард парсинга, и т.д. Т.е. после старта инстанса загруженность серверов БД будет около 100% на протяжении многих часов.

Вероятно также будут заметные проблемы с блокировками.

В общем, будет наблюдаться самый худший сценарий, аналогичный одновременному выполнению OLTP и DWH в одном сервере в одной БД.

1.

Селлы в Экзадате всегда недогружены, а БД-ноды всегда перегружены.

Отсюда один шаг до очевидного предположения :

В Экзадате сканированием табличных сегментов и преобразованием их в CS будут заниматься селлы. Скорее всего Оракл добавит дополнительный функционал в серверные процессы СХД, чтобы СХД формировала CS-сегменты и раздавала их серверам БД прямо в In-Memory-пул, других вариантов нет.

2.

Применительно к Экзадате мне кажется, что Оракл не будет создавать два формата Columnar Store - один для НСС, а второй для IMO. Это сложно и для разработки и для эксплуатации и для техподдержки, и главное, для оптимизатора и выполнения SQL. Скорее всего формат Columnar Store один, а НСС - это Columnar Store,  дополнительно сжатый gz или bz. Т.е внутри это один и тот же оптимально построенный CS. Не может быть двух оптимальных CS у одного Оракла. Если таблицы уже находятся в НСС-формате, то работа селлов будет заключаться в распаковке и передаче CS в IM-пул - минимальный объем работ. Не верится, что Оракл будет переупаковывать данные из одного формата в другой.

3.

Серверов БД бывает много, например 8 штук, как в случае Full Rack, или еще больше, если связать несколько Экзадат.

Это означает,  что все 8 IM-пулов всех 8 серверов БД будут хранить одни и те же данные, т.е. содержимое памяти у всех 8 серверов будет 8-кратно дублировано. В случае объединения нескольких Экзадат эта пропорция еще более ухудшается.

Поэтому для улучшения масштабирования Оракл может применить еще одно решение на Экзадате: IM-пул может быть выделен в физической памяти селла или на флэш-дисках. В этом случае расход памяти будет однократный, чтение с дисков - тоже. Каждый селл будет хранить свою часть IM-пула автоматически, читая primary-экстент соответствующей таблицы.

Количество серверов хранения больше, чем серверов БД (отношение 14 к 8), поэтому 

- хранить в их памяти CS-сегменты еще более надежно, чем в серверах БД,

- при выходе из строя одного селла производительность всей Экзадаты пострадает в меньшей степени, чем при выходе из строя одного сервера БД, потому что теряется меньше данных

- также в сервере хранения проще,легче,быстрее восстановить утраченные сегменты, чем в сервере БД,

- серверов хранения больше, чем серверов БД и им не требуется дополнительно хранить и обслуживать SGA в своей оперативной памяти, поэтому они могут хранить больше CS-данных, чем серверы БД.

Поэтому есть вероятность, что Оракл увеличит оперативную или флэш память в серверах хранения с тем, чтобы каждый из них содержал свою долю IM-пула.

Сейчас Оракл и разрешил политику DUPLICATE для CS-сегментов только на Экзадате (однократное выполнение дискового сканирования).

В не-Экзадатовских RAC разрешена только политика
DISTRIBUTE   AUTO | BY { ROWID RANGE | PARTITION | SUBPARTITION } - что означает, что каждая БД-нода содержит только свою часть таблицы и соответственно сканирует свою долю экстентов.

4.

С учетом Flash Cache Persistence (сохранения содержимого FC после рестарта селл) производительность Экзадаты должна пострадать в гораздо меньшей степени, чем производительность стандартных архитектур. OLTP-операции будут получать данные из FC и не будут создавать сколько-нибудь заметную нагрузка на жесткие диски. Поэтому деградации производительности для OLTP-операций на Экзадате будет незаметно.

Временно (на несколько часов) пострадают операции Smart Scan которые также выполняют сканирующие операции, аналогичные операциям построения CS-сегменов.