Oracle Database In-Memory. Part 2

В этой части я постараюсь перейти к техническим деталям - тем, которые доступны без документации и продукта (напомню, что сам продут ожидается в июле).

In-Memory собирается обрабатывать данные в памяти. Ларри несколько раз упоминал M6-32 с 32 TB памяти на борту как машину для таких задача. Однако, я не знаю ни одной инсталляции Oracle, которая использовала бы более 2TB памяти под SGA на одном узле. Пожалуйста напиши, если вам известна такая система, с указанием OS и версии DB. Интересно,  как именно будет организована память под хранение данных в In-Memory, но иного варианта как отдельную структуру памяти в SGA я пока не вижу.


Если вы попытаетесь использовать более 1TB под Oracle, вам скорее всего потребуется использовать huge pages (Linux) или large pages (AIX).  Это связано с тем, что если использовать меньшие размеры страниц памяти, кол-во запросов на преобразование вирутального адреса в реальной сильно возрастает, что приводит к проблема с TLB регистрами процессора - регистр не справляется, время обращения к памяти сильно  увеличивается.

В принципе, проблем, с тем, чтобы правильно сконфигурировать систему нет, но есть например известный факт, что hugepages (large pages) несовместимы с Automaic Memory Management (AMM).

"Each CPU scans local in-memory columns"
Далее,  для больших машинах класса M6-32/Power 795  производительность сильно зависит от того, приходится ли процессорам обращаться к ближней памяти (те памяти на своей процессорной плате)  или дальней (на других процессорных платах). По моим ощущениям, правильное распределение памяти - процессор может давать 20-40% производительности.

Насколько я знаю, обеспечить правильное распределение памяти можно только с помощью поддержки NUMA. NUMA можно сконфигурировать в Oracle, нет проблем, но это должно быть опять такие документировано как требование к In-Memory, для больших машин.

Как мне кажется, наиболее востребованным окажется In-Memory именно в кластерах машин с памятью до 1 Tb, поскольку там нет необходимости ни с чем вышеописанным иметь дело.

"Scans use super fast SIMD vector instructions"

SIMD - Single instruction, multiple data, возможность за один такт выполнить инструкцию над массивом данных. Оказывается существует уже много лет, вот только разработчики баз данных обратили на это внимание в этом году

(источник картинки)

Ларри во время выступления даже сказал, что под SIMD инструкции хорошо бы задействовать GPU..и на сайте Intel я нашел потрясающую штуку - проект Xeon Phi. Это сопроцессор с 61 ядром который как раз поддерживает еще более продвинутый SIMD чем текущие процессоры. Ожидаем Exadata V6 c сопроцессорами для обработки данных в памяти! -) 

Небольшое замечание - я пока не нашел нигде расшировки для каких именно операций (join, group by, aggregations) будет использоваться SIMD. Возможно это вопрос времени, постепенно все допишут. 

Что хотелось бы увидеть:   In-Memory индексы (их обещают, непонятно будут ли у них те же ограничения что у Exadata или нет),  возможность обновления данных в памяти без декомпрессии всего блока хранения (мы еще не знаем,  что собственно будет блоком хранения данных).

Пока я вижу следующую архитектурную проблему: для аналитических запросов нужны как правило связи между многими таблицами, но число колонок, требуемых для запросов,  весьма ограничено. Так как можно помещать в память только таблицы или их партиции, много места будет занято в памяти колонками, которые никогда не будут использоваться в аналитике. Конечно возможность сохранять в памяти отдельные колонки, или кубы,  или материализованные представления кажутся более щадящими и востребованными. Возможно мы все это и увидим в следующих версиях.