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 или нет),  возможность обновления данных в памяти без декомпрессии всего блока хранения (мы еще не знаем,  что собственно будет блоком хранения данных).

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

2 комментария:

  1. Анонимный25/6/14 7:27 PM

    Дмитрий,

    >> наиболее востребованным окажется In-Memory именно в кластерах машин с памятью до 1 Tb
    но данные придётся гонять между нодами, что дольше внутрисерверных задержек при обращении к "дальней памяти" будет

    Имеет смысл, имхо, обратить внимание на очень вовремя вышедшие процессоры линейки intel E7-2800/4800/8800 v2, содержащие до 15 физических ядер и поддерживающие до 1,5 TB RAM на процессор и технологии SIMD (Advanced Vector Extensions) - получаем хороший диапазон 2-8 сокетных серверов с памятью 3-12 TB - вот из них серверы и кластера для In-Memory и построятся ;)

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

    ОтветитьУдалить
  2. E7 v2 хороши - но проблема давно не в кол-ве памяти, а возможности ее использовать так, чтобы было не особенно больно за это. Я не даром спрашивал - а есть ли опыт работы с большими (> 1TB) SGA?

    >matview - query rewrite - In-Memory - было бы круто -))

    ОтветитьУдалить