Oracle 12c in-Memory option
Добавлено: 11 июл 2014, 22:19
Призентация опции in-Memory in Oracle 12c
в двух словах, если выкинуть все комерческие словечки Ларри Елисона, сводится к простой идее.
База данных, в облсти Shared-memory будет представляться в 2-х форматах.
Один старый -- в виде записей. Создал запись, обновил записть, и т.д. все как обычно.
Второй -- те же данные организованы в виде колонок ( таблица режется вертикально, а не горизонтально как в первом случае ).
Первый вариант для OLTP. Тут все по прежнему. Ничего менять не надо.
Второй вариант "Аналитический" для отчетов, где надо суммарные данные по колонкам. Тут данные уже представлены как колонки, и отчеры делаются в разы быстрее.
Это разделение только в памяти! На диске все как раньше. И на диск пишет только OLTP часть.
Ведь вторая "Аналитическая" часть данные не меняет.
OLTP при этом тоже начинает работать быстрее. Так как все индексы которые не нужны для OLTP удаляются из базы (часть 1). Соответственно Оракл исключает индексы ( большинство из них ) из транзакций, переводя их в аналитическую часть 2. А чем меньше индексов -- тем быстрее данные создаются и меняются. Фактически мы оставляем только несколько уникальный индексов для проверки корректности ввода. Индексы для поиска из OLTP части удаляются. И строятся в Аналитической части по мере необходимости. Ведь поиск идет только по 2-ой части.
Короче это шампунь и кондиционер в одном флаконе, то есть OLTP и DataWarehouse вместе.
Конечно надо больше RAM для этого. Ну и что. В той машине что на сцене стоит 32 TB памяти. В эту память влезут наверно все Прогрессовые базы не только в России, но и по всем приложениям всего мира
в двух словах, если выкинуть все комерческие словечки Ларри Елисона, сводится к простой идее.
База данных, в облсти Shared-memory будет представляться в 2-х форматах.
Один старый -- в виде записей. Создал запись, обновил записть, и т.д. все как обычно.
Второй -- те же данные организованы в виде колонок ( таблица режется вертикально, а не горизонтально как в первом случае ).
Первый вариант для OLTP. Тут все по прежнему. Ничего менять не надо.
Второй вариант "Аналитический" для отчетов, где надо суммарные данные по колонкам. Тут данные уже представлены как колонки, и отчеры делаются в разы быстрее.
Это разделение только в памяти! На диске все как раньше. И на диск пишет только OLTP часть.
Ведь вторая "Аналитическая" часть данные не меняет.
OLTP при этом тоже начинает работать быстрее. Так как все индексы которые не нужны для OLTP удаляются из базы (часть 1). Соответственно Оракл исключает индексы ( большинство из них ) из транзакций, переводя их в аналитическую часть 2. А чем меньше индексов -- тем быстрее данные создаются и меняются. Фактически мы оставляем только несколько уникальный индексов для проверки корректности ввода. Индексы для поиска из OLTP части удаляются. И строятся в Аналитической части по мере необходимости. Ведь поиск идет только по 2-ой части.
Короче это шампунь и кондиционер в одном флаконе, то есть OLTP и DataWarehouse вместе.
Конечно надо больше RAM для этого. Ну и что. В той машине что на сцене стоит 32 TB памяти. В эту память влезут наверно все Прогрессовые базы не только в России, но и по всем приложениям всего мира