Про Oracle Business Intelligence

В этому году не случилось поприсутствовать лично на 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. Возможно какой-то тюнинг и придется делать, но это как и всегда.
3. Одна из потенциальных возможностей – это удалить часть индексов, используемых только для аналитических запросов. Это дает во-первых экономию дискового пространства, так как индексы зачастую занимают больше места, чем сами данные, а во-вторых, меньше индексов – быстрее работают и операции, такие как вставка, обновление, удаление, так как они вызывают изменение в индексах. Таким образом, использование этой опции может дать ускорение и обычной транзакционной системы. При этом, в случае изменений в строчной версии данных, колоночная копия тоже будет меняться.

Интересная возможность, про которую говорили – использование т.н. SIMD (single instruction, multiple data), то есть возможность современных процессоров за одну команду обрабатывать целый массив данных. Отдельная колонка, по сути является таким массивом. И для тех запросов, которые могут использовать эту возможность, это позволит достичь ускорения в тысячи раз. Утверждалось даже, что это даст возможности обрабатывать миллиарды записей в секунду на одном процессорном ядре.

В целом, это опция использования оперативной памяти продолжает то, что было объявлено в прошлом году и о чем я тогда писал, что стратегия Oracle все больше использовать дешевеющую полупроводниковую память и меньше полагаться на медленные диски. Многоуровневое кеширование с использованием флеш-карт и оперативной памяти позволяет ускорять множество операций. При этом диски все больше становятся только средством долговременного хранения данных.

Пока остаются вопросы как эта технология реализована в деталях и какие у нее ограничения, а также когда она будет доступна. Ясно только, что доступна она будет в Oracle Database 12c. (не в 11g)

Продолжение следует.

__________________________________

Читайте также:

• Sun Oracle Database Machine и Exadata версии 2
• Oracle Exalytics – Business Intelligence Machine
• Oracle OpenWorld 2012. Дни 2 и 3
• Oracle OpenWorld 2012. День 1.
• Oracle OpenWorld 2012. День 4

А еще можно почитать мой твиттер @apivovarov

Trackback This Post | Subscribe to the comments through RSS Feed