Oracle Database In-Memory What s New and What s Coming Andy Rivenes Product Manager for Database In-Memory Oracle Database Systems DOAG - May 10, 2016 #DBIM12c
Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 4
Who is Database In-Memory 5
Oracle Database In-Memory Development Oracle headquarters 400 Building 14 th Floor 6
Oracle Database In-Memory Product Management Team Maria Colgan, DBIM Product Manager Andy Rivenes, DBIM Product Manager Vineet Marwah, DBIM Product Manager Mary Beth Pierantoni, DBIM Product Manager Mat Steinberg, ISV Development Product Manager Bud Endress, Director of Product Management, OLAP 7
Oracle Database In-Memory Developers 8
What is Database In-Memory 9
Oracle DatabaseIn-Memory Goals Real-Time Analytics 100X Accelerate Mixed Workload Risk-Free Trivial to Implement Transactions Analytics Enable Real-Time Business Decisions Run analytics on Operational Systems Proven Scale-Out, Availability, Security No Application Changes Not Limited by Memory 10
Row Format Databases vs. Column Format Databases Rows Stored Contiguously Query SALES Transactions run faster on row format Example: Query or Insert a sales order Fast processing few rows, many columns Columns Stored Contiguously SALES Query Analytics run faster on column format Example : Report on sales totals by region Fast accessing few columns, many rows Until Now Must Choose One Format and Suffer Tradeoffs 11
Breakthrough: Dual Format Database Normal Buffer Cache SALES Row Format New In-Memory Format SALES Column Format BOTH row and column formats for same table Simultaneously active and transactionally consistent Analytics & reporting use new in-memory Column format SALES OLTP uses proven row format 12
Oracle In-Memory Columnar Technology Pure In-Memory Columnar Pure in-memory column format - Not persistent, and no logging - Quick to change data: fast OLTP Enabled at table or partition - Only active data in-memory SALES 2x to 20x compression typical Available on all hardware platforms 13
Orders of Magnitude Faster Analytic Data Scans Memory CPU Load multiple region values REGION Vector Register CA CA CA CA Example: Find sales in California region Vector Compare all values an 1 cycle > 100x Faster Each CPU core scans local in-memory columns Scans use super fast SIMD vector instructions - Originally designed for graphics & science Billions of rows/sec scan rate per CPU core - Row format is millions/sec 14
Improvements to All Aspects of Analytic Query Data Scans SALES CPU STATE = CA Vector Register CA CA CA CA Table A Joins HASH JOIN Table B In-Memory Aggregation Speed of memory Scan and filter only needed columns Vector instructions Convert Star Joins into 10X faster column scans Search large table for values that match small table Create In-Memory Report Outline that is populated during Fast Scan Runs reports instantly 15
Database In-Memory Accelerates Mixed Workloads Complex OLTP is Slowed by Analytic Indexes Column Store Replaces Analytic Indexes Table 1 3 OLTP Indexes 10 20 Analytic Indexes REPLACE Inserting one row into a table requires updating 10-20 analytic indexes: Slow! Fast analytics on any columns Column Store not persistent so update cost is much lower 16
Database In-Memory Scales to Any Size Scale-Out Scale-Up Combine with Flash and Disk Hottest Data Active Data Cold Data DRAM PCI FLASH DISK Scale-Out Across Servers to Grow Memory and CPUs In-Memory Queries Parallelized Across Servers Scale-Up on large SMPs NUMA Optimized Easily place data on most cost effective tier Simultaneously Achieve: - Speed of DRAM - I/Os of Flash - Cost of Disk 17
Database In-Memory: Industrial Strength Availability Data Guard & GoldenGate RAC ASM RMAN Pure In-Memory format does not change Oracle s storage format, logging, backup, recovery, etc. All Oracle s proven availability technologies work transparently Protection from all failures - Node, site, corruption, human error, etc. 18
Database In-Memory: Unique Fault Tolerance Similar to storage mirroring Duplicate in-memory columns on another node - Enabled per table/partition (e.g. only recent data) - Application transparent Only Available on Engineered Systems Downtime eliminated by using duplicate after failure 19
Database In-Memory: Trivial to Implement Easy to Deploy 100% Compatible Full Functionality Easy to Use No data migration No application changes No SQL restrictions No complex setup 1. Set column store size 2. Declare In-Memory tables 20
What s Coming 21
SPARC M7 Software in Silicon Traditional DB algorithms too complex for chips Software in Silicon Big Change: In-memory algorithms are much simpler 5 years ago Oracle initiated a revolutionary project Build fastest ever microprocessor Most processing cores (32) and concurrent threads (256) Fastest Memory Bandwidth (160 GB/sec) Add In-Memory DB operations directly on chip Only high-volume CPU with native SQL optimizations 22
In-Memory Algorithms Natively Implemented in Silicon SQL in Silicon DB Acceleration SPARC M7 Software in Silicon Capacity in Silicon Decompression Engines Silicon Secured Memory Fine-Grained Memory Protection Database Software Support Shipping Since Mid-Year 23
SQL in Silicon: Database In-Memory Acceleration Engines Core DB Accel SPARC M7 Core Core Core Shared Cache DB Accel DB Accel DB Accel SIMD Vectors instructions are fast, but were designed for graphics, not database New SPARC M7 chip has 32 optimized database acceleration engines (DAX) built on chip Independently process streams of columns E.g. find all values that match California Up to 170 Billion rows per second! Like adding 32 additional specialized cores to chip Using less than 1% of chip space 24
Capacity in Silicon: Decompression Engines Compression is key to putting more data in-memory Decompression is far more import for databases than compression Data is loaded once, queried many times Bit pattern decompression in normal cores is slow 64 CPU cores needed to decompress at full memory speed Doubles Memory Capacity SPARC M7 adds 32 optimized decompress engines Run bit-pattern decompress at memory speed 25
Silicon Secured Memory: Fine Grained Memory Protection Database In-memory places terabytes of data in memory More vulnerable to corruption by bugs/attacks than storage SPARC M7 locks memory as it is allocated so only the owner can access it Hidden color bits added to pointers (key), and content (lock) Pointer color (key) must match content color or program is aborted Hardware support eliminates performance impact Helps prevent access off end of structure, stale pointer access, malicious attacks, etc. plus improves developer productivity Memory Pointers STOP Memory Content 26
Preview: In-Memory with Oracle Database 12c Release 2 Real-Time Analytics On OLTP or DW Massive Capacity Trivial to Implement Row Column Column 3XFaster Joins 10XFaster Expressions 60XFaster JSON Active Data Guard Support In-Memory on Exadata Flash Dynamic Data Movement Between Storage & Memory 27
Real-Time Analytics: Faster In-Memory Joins Example: Find total sales in outlet stores Stores Type Store ID Type= Outlet Store ID is join column Store ID Sales Amount Join Group specifies columns used to join tables Columns share compression dictionary Joins occur on compressed dictionary values rather than data Enables 3x faster join processing Create Join Group store_sales_jg (STORES (STORE_ID),SALES (STORE_ID); 28
Real-Time Analytics: In-Memory Expressions Example: Compute total sales price Net = Price + Price * Tax In-Memory Column Store Sales Price Tax Price + Price X Tax Analytic queries contain complex expressions Originally evaluated for every row Expressions pre-computed and cached in-memory User defined via virtual columns Or expressions automatically detected All In-Memory optimizations apply 5x faster complex queries 29
Real-Time Multi-Model Analytics: In-Memory JSON Pure In-Memory Columnar Relational In-Memory Virtual Columns Relational Virtual JSON In-Memory JSON Format { "Theater":"AMC 15", "Movie":"Jurrasic World 3D", "Time :2015-11-26T18:45:00", "Tickets":{ "Adults":2 } } Full JSON documents loaded using a highly optimized In-Memory binary format Additional expressions can be created on JSON columns (e.g. JSON_VALUE) and stored in column store Queries on JSON content or expressions automatically directed to In-Memory format (e.g. Find movies where movie.name contains Jurassic ) 60x performance gains observed 30
On OLTP or DW: In-Memory on Active Data Guard 1 Month In-Memory Production 1 Year In-Memory Standby Real-time analytics with no impact on production database Make productive use of standby database resources Can populate with different data than production database Uses database services to determine where to populate a table Increases total columnar capacity 31
Ultra-High Availability: In-Memory Fast-Start DBFILE1 Index Table Index Buffer Cache Table Table SALES TABLESPACE FAST START TABLESPACE In-Memory Column Store DBFILE2 Fast Start Data IM column format persisted to storage - In-Memory column store contents checkpointed to secure file lob on populate - When DB restarts population is faster as population process reads the column format directly from storage - Faster restore (2-5x) of column store since no need to reformat data 32
Massive Capacity: IMC Format in Columnar Flash Cache In-Memory format now used in Smart Columnar Flash Cache Enables in-memory optimizations on data in Exadata flash (e.g. multiple column values evaluated in single vector instruction) In-memory performance seamlessly extended from DB node DRAM memory to 10x larger flash in storage Huge advantage over all-flash arrays and other in-memory DBs In-Memory Columnar scans In-Flash Columnar scans 33
Automation: In-Memory Data Auto Population Policies In-Memory Column Store Sales _Q1 Sales_Q2 Sales_Q3 Heat map tracks data access frequency Policies can be defined to Bring data into the IM column store Increase compression levels as data cools Evict cold data from IM column store Sales_Q4 34
When and How Should I Use In-Memory 35
Getting The Most From In-Memory Understand Where it Helps Fast cars speed up travel, not meetings In-Memory speeds up analytic data access, not: Network round trips, logon/logoff Parsing, PL/SQL, complex functions Data processing (as opposed to access) Complex joins or aggregations where not much data is filtered before processing Load and select once Staging tables, ETL, temp tables Know your bottleneck! 36
Getting The Most From In-Memory The Driver Matters Avoid stop and go traffic Process data in sets of rows in the Database Not one row at a time in the application Plan ahead, take shortest route Help the optimizer help you: Gather representative statistics using DBMS_STATS Use all your cylinders Enable parallel execution In-Memory removes storage bottlenecks allowing parallelism to increase 37
In-Memory Use Cases OLTP Real-time reporting directly on OLTP source data Removes need for separate ODS Speeds data extraction Data Warehouse Staging/ETL/Temp not a candidate - Write once, read once All or a subset of Foundation Layer - For time sensitive analytics Potential to replace Access Layer 38
Where can I get more information 39
Additional Resources Related White Papers Oracle Database In-Memory White Paper Oracle Database In-Memory Aggregation Paper When to use Oracle Database In-Memory Oracle Database In-Memory Advisor Join the Conversation https://twitter.com/db_inmemory https://blogs.oracle.com/in-memory/ https://www.facebook.com/oracledatabase http://www.oracle.com/goto/dbim.html Related Videos In-Memory YouTube Channel Managing Oracle Database In-Memory Database In-Memory and Oracle Multitenant Industry Experts Discuss Oracle Database In-Memory Software on Silicon Any Additional Questions Oracle Database In-Memory Blog 40
Q & A If you have more questions later, feel free to ask 41