Oracle Database In-Memory

Editor's Notes

• #8: Row format is optimized for OLTP workloads. OLTP operations tend to access only a few rows but touch all of the columns.A row format allows quick access to all of the columns in a record since all the datafor a given record are kept together in-memory and on-storage. Since all data for a row is kepttogether, much of the row data will be brought into the CPU with a single memory reference. Row format is also much more efficient for row updates and inserts. Analytical workloads access few columns but scan the entire data set. They also typically require some sort of aggregation. A columnar format allows for much faster data retrieval when only a few columns in a table are selected because all the data for a column is kepttogether in-memory and a single memory access will load many column values into the CPU.It also lends itself to faster filtering and aggregation, making it the most optimzed format for analytics. Up until now you have been force to pick just one format and suffer the tradeoff of either sub-optimal OLTP or sub-optimal Analytics.
• #10: With the introduction of the Oracle Database In-Memory Option it is now possible to run real-time, ad-hoc, analytic queries on your business data as it exists right at this moment and receive the results in sub-seconds. True real real-time analytics. Imagine being able to know the total sales you have made in the state of California as of right now. Not last week, or even last night but right now and have that query return in sub-second time.
• #12: Other databases have row and column formats but you must choose ONE format for a given table. Therefore you get either fast OLTP or fast Analytics on that table but not both. Oracle’s unique dual format architecture allows data to be stored in both row and column format simultaneously. This eliminates the tradeoffs required by others. Up until now, this could only be achieved by having a second copy of the table (Data Mart, Reporting DB, Operational Data Store), which adds cost and complexity to the environment, requires additional ETL processing and incurs time delays. With Oracle’s unique approach, there is a single copy of the table on storage. So there are no additional storage costs, synchronization issues, etc. The Oracle optimizer is In-Memory aware. It has been optimized to automatically route analytic queries to the column store, and OLTP queries to the row store.
• #20: The Oracle in-memory column format is designed to enable very fast SIMD processing (single instruction processing multiple data values). You can imagine SIMD or vector processing as array processing. SIMD was originally designed for accelerating computer generated animation and High Performance Scientific computing. Lets assume we are looking for the total number of sales we have had in the state of California this year. The sales table is stored in the In-Memory Column Store so we simple have to scan the state column and count the numberof occurrence of the state of California. With SIMD processing we can check 16 values or entries in the state column in a single CPU cycle. Columnar speed comes from Scanning only needed columns SIMD optimized format Column specific compression algorithms
• #22: We have shown that we can scan and filter in-memory data extremely quickly. But with any new data format we need to be able to join and aggregate the data as well as scan it. With Vector joins, the join between the stores and sales table can be converted into a scan of the sales table with the ‘where’ clause predicate on the store table being converted into a filter on the sales table. This allows us to take full advantage of what In-memory is best for, fast scans and filters.
• #24: Analytic style queries require more than simple filters and joins. They often require aggregations and summaries. And this is where the Oracle Optimizer comes in. The optimizer recognizesthese aggregation queries and transforms or rewrites them to take advantage of vector joins and vector group-bys. This allow the joins and group by (or aggregation) to occur simultaneously with the scan of the sales table,rather than waiting for the table scans and join operations to complete before beginning the aggregation. Aggregation normally has to dynamically determine the format of the result and the contents of the result at the same time. Any new row can cause the format of the result to change. By precomputing the report outline, the aggregation can run much faster since the report format is known ahead of the fact table scan and fact rows can just be added into the known format.
• #32: Up until now, the only way to run analytic queries with an acceptable response on an OLTP environment was to create specific indexes for these queries. The good thing about indexes is that they are extremely scalable. They work well in-memory and also are extremely efficient on-disk since they minimize disk IO needed to find the requested data. All of these additional indexes need to be maintained as the data changes, which increase the elapse time for each of these changes.
• #41: Because the In-Memory Column Store is embedded in the Oracle Database it is fully compatible with ALL existing features, And requires absolutely no changes in the application layer. This means you can start taking full advantage of it on day one,regardless of what applications you run in your environment. Any application that runs against the Oracle database will transparently benefit from the in-memory column store.