Comments 28
Технология не новая: http://en.wikipedia.org/wiki/K_(programming_language)
ей уже лет 20+, успешно используется в особенности банках.
ей уже лет 20+, успешно используется в особенности банках.
и время ответа должно составлять буквально секунды, а не секунды
«В любом OLTP-приложении есть поддержка отчетности» — с чего Вы взяли?
Наверное, неточно выразился. Имелось в виду, что чистых OLTP систем, то есть приложений, в которых присутствуют только транзакции на вставку/удаление.модификацию, практически не бывает.
Большинтсво бизнес-приложений являются системами смешанного типа: в них есть и транзакционная нагрузка, и аналитическая нагрузка. Аналитическая нагрузка может быть как в виде отчетности, а может быть и в неявном виде — в виде аналитических запросов, например: проверка балансов при закрытии операционного дня в АБС, выгрузка сводных данных в внешние системы и т.д.
Большинтсво бизнес-приложений являются системами смешанного типа: в них есть и транзакционная нагрузка, и аналитическая нагрузка. Аналитическая нагрузка может быть как в виде отчетности, а может быть и в неявном виде — в виде аналитических запросов, например: проверка балансов при закрытии операционного дня в АБС, выгрузка сводных данных в внешние системы и т.д.
К сожалению, не догоняю про колонки: являются ли они по сути индексом? Или они как раз наоборот, представляют собой список без какого-либо индекса? Почему join на них гораздо эффективнее?
Это обычные столбцы, без всяких изменений. Реляционная таблица разворачивается по столбца и в таком виде записывается в память. При этом каждый блок памяти (MEmory Compession Unit) хранит значение только одного столбца. Индексы никак в области колоночного хранения не сохраняются, поскольку не имеют реляционной структуры (не хранятся в виду строк и столбцов).
Join на колоночном представлении быстрее, поскольку конвертируеится в фильтры. Фильтры быстрее работают на колоночном представленнии, поскольку используют векторные регистры процессора.
Понятно что речь идет только об аналитических индексах, то есть там где возникает сканирование большого количества строк
Если индекс имеет высокую селективноcть, например — индекс на первичый ключ по identify-полю, в этом случае, конечно, колоночное сканирование не используется — оно не выгодно. Сканирование по столбцам выгодно когда индекс неселективен, либо его дорого содержать (если он многостолбцовый).
Но Вам не нужно думають об этой внутренней кухне — SQL-оптимизатор автоматически сам выбирает для SQL-запроса сканированрие по столбцам или доступ через индекс
Join на колоночном представлении быстрее, поскольку конвертируеится в фильтры. Фильтры быстрее работают на колоночном представленнии, поскольку используют векторные регистры процессора.
Понятно что речь идет только об аналитических индексах, то есть там где возникает сканирование большого количества строк
Если индекс имеет высокую селективноcть, например — индекс на первичый ключ по identify-полю, в этом случае, конечно, колоночное сканирование не используется — оно не выгодно. Сканирование по столбцам выгодно когда индекс неселективен, либо его дорого содержать (если он многостолбцовый).
Но Вам не нужно думають об этой внутренней кухне — SQL-оптимизатор автоматически сам выбирает для SQL-запроса сканированрие по столбцам или доступ через индекс
Если индекс имеет высокую селективноcть
Высокая селективность это до скольки процентов? «говорите точно сколько вешать в граммах» (с)
А еще подскажите про обычные индексы интересно, как то можно сделать, чтобы аналогично вышеописанному можно было выполнить их прелоад в память фоновыми процессами?
А если заранее снять статистику для оптимизатора dbms_stats.gather_schema_stats?
Это не то, что нужно?
Это не то, что нужно?
Вы про прелоад индекса? Думаю это не то, что нужно… Или сбор статистики загружает индекс с диска в оперативную память?
ну если db_cache_size позволяет, индекс и так будет в памяти лежать
Сразу после старта базы или все таки после первого его использования? Все таки in-memory кэш это одно — когда сначала на диске, первое обращение, прочитанное с диска кэшируется в памяти и повторные обращения уже идут в память к закэшированному (если оно не было вытеснено чем то другим) и in-memory storage это когда еще до обращения все вычитывается в память и всегда там хранится. Я спрашиваю о втором варианте.
Разработчики SAP HANA кусают локти от зависти
Дык в аналитических базах DML особо и не нужен — залил данные раз в день, а остальное через speed layer (я про lambda architecture)
Почему в статье нет реальных замеров насколько увеличилась производительность, время доступа и т.д.?
В каких редакциях поддерживается? Если только в Enterprise — сколько стоит лицензия на эту опцию?
Надеюсь теперь транзакции в Сбербанке будут работать побыстрее
Очень крутая статья! Я читал про эту особенность, но не отнесся к ней серьезно, а зря! Тут она описана очень хорошо! Я как OCP понимаю мощь данной технологии!
Но все же я жду когда Оракл полностью реализует поколоночное хранение, а не как сейчас только в Экзадате и только сжатые!
Но все же я жду когда Оракл полностью реализует поколоночное хранение, а не как сейчас только в Экзадате и только сжатые!
Sign up to leave a comment.
Такое не забывается — Oracle Database In-Memory