В этому году не случилось поприсутствовать лично на Oracle OpenWorld, но если говорить про основные новости, то они обычно объявляются Ларри Эллисоном или другими высшими руководителями в так называемых Keynotes. А кейноты транслируются на сайте OOW. В том числе ведутся и прямые трансляции. Правда т.к. OOW проходит в Калифорнии, то прямые трансляции бывают или поздно вечером или глубоко ночью по московскому времени. Хотя мне удалось посмотреть почти все прямые трансляции, но неделя выдалась довольно нагруженная, так что могу написать что-то только сейчас.
Итак, что было объявлено интересного?

В воскресенье состоялось первое (и, к сожалению, единственное) выступление Ларри Эллисона. Первый анонос касался Oracle Database In-Memory Option. Что это такое?

В мире СУБД (особенно в области хранилищ данных и аналитики) уже не один десяток лет существуют споры между сторонниками хранения данных в таблицах по строкам и по колонкам.

Традиционное хранение по строкам универсально и используется в большинстве СУБД. Альтернативный, колоночный подход – разрезать все таблицы по колонкам и хранить колонки в виде отдельных объектов. Преимущества этого подхода в том, что:

  1. При выполненнии запроса читаются только те колонки, которые требуются в SQL запросе, так как остальные лежат физически в других объектах. В случае хранения по строкам нужно читать все данные, даже если они не нужны. Очевидно, что когда читаются только нужные колонки – скорость чтения будет гораздо выше.
  2. Данные, содержащиеся в одной колонке чаще всего однотипны и из-за этого очень хорошо сжимаются. Если сжимать обычную таблицу, коэфициент сжатия будет гораздо скромнее. СУБД с колоночным хранением обычно сжимают данные.

Но как это часто бывает, у такого подхода есть и свои недостатки:

  1. Базы данных с колоночным хранением обычно используются только для хранилищ данных, то есть для задач, где данные будут в основном читаться. Для транзакционных систем их использовать затруднительно.
  2. Так как объекты содержащие колонки обычно еще и сжимаются, то добавление новых значений в таблицу или обновление требуют зачастую по сути пересжатия данных во всей таблице во многих объектах, что очень плохо сказывается на проиводительности. (Кстати стоит заметить, что технология Hybrid Columnar Compression в Exadata частично смягчает эту проблему)
  3. В случае, если запрос использует большое число таблиц, связей, колонок, становится необходимым распаковывать и связывать большое количество объектов, что тоже влияет на производительность

Поэтому возникает проблема – с одной стороны колоночное хранение и обработка в некоторых случаях дает серьезное ускорение выполнение запросов, но с другой стороны на других запросах это наоборот может работать в минус.

Анонсированная Ларри Эллисоном опция по сути позволяет совместить оба подхода. Администратор системы может объявить таблицу или отдельную партицию как хранимую в памяти через \”ALTER TABLE … INMEMORY\” и для этой таблицы будет создаваться в памяти ее колоночная копия. То есть таблица будет находиться в памяти как в традиционном строчном виде, так и в колоночном. (Я не совсем понял, правда, сжимается ли при этом этом колоночная версия. Видимо нет.) Какие при этом появляются преимущества?

  1. Аналитические SQL запросы смогут серьезно ускорятся в тех случаях, когда оптимизатор запросов поймет, что лучше использовать колоночную копию данных.
  2. При этом переписывать приложение по сути не нужно, так как это не какая-то новая база данных, а все тот же Oracle. Возможно какой-то тюнинг и при