Comments 28
Подтверждаю, в банках в полный рост используют чтобы time series хранить. Вот только язык Q — это для настоящих сварщиков.
«В любом OLTP-приложении есть поддержка отчетности» — с чего Вы взяли?
Наверное, неточно выразился. Имелось в виду, что чистых OLTP систем, то есть приложений, в которых присутствуют только транзакции на вставку/удаление.модификацию, практически не бывает.
Большинтсво бизнес-приложений являются системами смешанного типа: в них есть и транзакционная нагрузка, и аналитическая нагрузка. Аналитическая нагрузка может быть как в виде отчетности, а может быть и в неявном виде — в виде аналитических запросов, например: проверка балансов при закрытии операционного дня в АБС, выгрузка сводных данных в внешние системы и т.д.
К сожалению, не догоняю про колонки: являются ли они по сути индексом? Или они как раз наоборот, представляют собой список без какого-либо индекса? Почему join на них гораздо эффективнее?
Это обычные столбцы, без всяких изменений. Реляционная таблица разворачивается по столбца и в таком виде записывается в память. При этом каждый блок памяти (MEmory Compession Unit) хранит значение только одного столбца. Индексы никак в области колоночного хранения не сохраняются, поскольку не имеют реляционной структуры (не хранятся в виду строк и столбцов).
Join на колоночном представлении быстрее, поскольку конвертируеится в фильтры. Фильтры быстрее работают на колоночном представленнии, поскольку используют векторные регистры процессора.

Понятно что речь идет только об аналитических индексах, то есть там где возникает сканирование большого количества строк
Если индекс имеет высокую селективноcть, например — индекс на первичый ключ по identify-полю, в этом случае, конечно, колоночное сканирование не используется — оно не выгодно. Сканирование по столбцам выгодно когда индекс неселективен, либо его дорого содержать (если он многостолбцовый).

Но Вам не нужно думають об этой внутренней кухне — SQL-оптимизатор автоматически сам выбирает для SQL-запроса сканированрие по столбцам или доступ через индекс
Если индекс имеет высокую селективноcть

Высокая селективность это до скольки процентов? «говорите точно сколько вешать в граммах» (с)

А еще подскажите про обычные индексы интересно, как то можно сделать, чтобы аналогично вышеописанному можно было выполнить их прелоад в память фоновыми процессами?
А если заранее снять статистику для оптимизатора dbms_stats.gather_schema_stats?
Это не то, что нужно?
Вы про прелоад индекса? Думаю это не то, что нужно… Или сбор статистики загружает индекс с диска в оперативную память?
ну если db_cache_size позволяет, индекс и так будет в памяти лежать
Сразу после старта базы или все таки после первого его использования? Все таки in-memory кэш это одно — когда сначала на диске, первое обращение, прочитанное с диска кэшируется в памяти и повторные обращения уже идут в память к закэшированному (если оно не было вытеснено чем то другим) и in-memory storage это когда еще до обращения все вычитывается в память и всегда там хранится. Я спрашиваю о втором варианте.
Дык в аналитических базах DML особо и не нужен — залил данные раз в день, а остальное через speed layer (я про lambda architecture)
Все верно, — никто не спорит. Эта технология нужна для ускорения запросов. Ведь именно из запросов состоит нагрузка в аналитической системе.
Почему в статье нет реальных замеров насколько увеличилась производительность, время доступа и т.д.?
Ну помилуйте! Технология вышле недавно. Сейчас идут тестирования у ряда крупных заказчиков. Как только тестирования завершатся и заказчик даст разрешение на публикацию, — мы обязательно сообщим конкретные результаты!
>> Технология вышле недавно
Ей же вроде почти год или я что-то перепутал?
В каких редакциях поддерживается? Если только в Enterprise — сколько стоит лицензия на эту опцию?
Да эта опция только для Enterprise. Называется Oracle Database In-Memory Option. В прайс-листе Oracle можете найти цену (без скидок!). -Он открыт.
Гугл в помощь. :-)
Надеюсь теперь транзакции в Сбербанке будут работать побыстрее
Очень крутая статья! Я читал про эту особенность, но не отнесся к ней серьезно, а зря! Тут она описана очень хорошо! Я как OCP понимаю мощь данной технологии!
Но все же я жду когда Оракл полностью реализует поколоночное хранение, а не как сейчас только в Экзадате и только сжатые!
Поколоночное хранение данных на диске? Только в Экзадате и только в сжатом виде. Разве не знали?
Про хранение на диске не знал, что вообще такое есть, думал поколоночное есть только для in-memory.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

30 December 1999

Location

США

Employees

Unknown

Registered

9 August 2008