Oracle DB In-Memory technologie v kombinaci s procesorem M7

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DB12c on SPARC M7
In-Memory and Oracle SPARC M7
Patrik Plachý
Senior Consultant
CoreTech Competency Center
Oracle Confidential – Internal 1

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Why is Oracle doing
this

In-Memory Accelerates Key Business Processes
Deep Analysis requires many passes through >10TBs of Data
• In-memory transforms key business processes
– Payroll processing (HCM)
– Demand processing & demand sensing (SCM)
– Material planning (ERP)
– Financial close & virtual close (Financial)
– Campaign management (CX)
• Simultaneous Analytics & OLTP
– Minimizes scheduled shutdowns for reports
– Up-to-the-minute accurate analysis
3
Business Processes Transformed
In-Memory 30x FASTER than flash storage!
Dual-format: On-disk & In-memory consistent
Column format
SPARC
In-memory
on-disk
Row format
Typical fast IO only 40GB/s
1200‘s
GB/s
SPARC
M7-8

Real-Time Enterprise
100‘s
GB/s ETL (GB/s)
Data Warehouse
Server
Real-Time Enterprise – Up-to-the-minute Analytics
Analytics at memory speed – 1000’s GB/s is much greater old 1-40 GB/s bottlenecks
• Key business processes radically transformed by orders magnitude
– Costs also dramatically reduced
on-disk
Row format
Millions IOPs
on-disk
Data Warehouse
on-disk
Typical fast IO
40GB/s
Column format
In-memory
SPARC

Lower Cardinality Data can be Most Interesting Data
More compression with lower cardinality(fewer bits needed), performance also increases
• Analytics often distills data by grouping according to combinations of features
– Again most interesting features have few dictionary Bits
5
Unique or
Random
Data
Gender
Season
5-point
Scale
Marital
Status
Top10
10 ranking
Month
Hour
State
Weeks
Minutes
Age
Test Score
Country
US City >100k
Days
Top 500 Job
Classification
Area code
Nasdaq NYSE
Top 5,000
School
districts zipcode
DOB last
150 years
Temperature
RainfallWind direction
Region
Price
Delivery
status
Most Interesting data has
fewer dictionary bitsMake
Model
2-bit 3-bit 4-bit 5-bit 6-bit 7-bit 8-bi t 9-bit 10-bit 11-bit 12-bit 13-bit 14-bit 15-bit 16-bit 17-bit 18-bit 19-bit...
Cardinality n-bits (calculated as 2^n-bits)

Data Cardinality and Number of Bits to Encode
# of unique column entries is cardinality, dictionary bits needed is log2(cardinality)
• Sample of Common
attributes:
– Analytics distills
interesting data into
classes of features
• Which means low
Dictionary Bits are
most interesting and
most common
Oracle Confidential – Highly Restricted 6
Attribute Cardinality Bits Attribute Cardinality Bits
gender 2 1.0 Temparatue 200 7.6
Seasons 4 2.0 US cities >100,000 295 8.2
5-point scale 5 2.3 Wind direction 360 8.5
marital status 5 2.3 days 365 8.5
day of week 7 2.8 top 500 500 9.0
top 10 10 3.3 US Job Classifications 840 9.7
ranking 10 3.3 area code 999 10.0
months 12 3.6 Rainfall (tenths) 1,000 10.0
GPA levels 14 3.8 top 1,000 1,000 10.0
hours 24 4.6 #NYSE listings 1,867 10.9
US states 50 5.6 #NASDAQ listings 3,400 11.7
weeks 52 5.7 top 5,000 5,000 12.3
minutes spent 60 5.9 top 10,000 10,000 13.3
60 month 60 5.9 school districts 14,000 13.8
test score 100 6.6 top 50,000 50,000 15.6
age 150 7.2 DOB last 150 years 54,750 15.7
countries 195 7.6 zip codes 99,999 16.6

Lower Cardinality Data is Important to Most Analysis
Online Retail Company
• Lower cardinality tables
common
– Attributes of transactions often
have fewer values (cardinality)
– ex: part color, state, ratings,
demographic data, etc.
• Nearly unique data is 18 to
19-bits
– Ex: index, customer ID,
transaction ID, etc.
SPARC M7 fast across spectrum
Low
Cardinality
Medium
Cardinality
High
Cardinality
1-4 5-8 9-12 13-16 17-19

How does it work

Row Format Databases vs. Column Format Databases
Rows Stored
Contiguously
 Transactions run faster on row format
– Example: Query or Insert a sales order
– Fast processing few rows, many columns
Columns
Stored
Contiguously
 Analytics run faster on column format
– Example : Report on sales totals by region
– Fast accessing few columns, many rows
SALES
SALES
9
Until Now Must Choose One Format and Suffer Tradeoffs

SPARC
Oracle Database In-Memory Dual Format Database
• BOTH row and column
formats for same table
• Simultaneously active and
transactionally consistent
• Analytics & reporting use new
in-memory Column format
• New Analytics Compression means
huge amounts of database can now fit
in-memory
• OLTP uses proven row format
10
Memory Memory
SALES SALES
Row
Format
Column
Format

Oracle In-Memory Columnar Technology
• 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
• 2x to 20x compression typical
• Available on all hardware
platforms
11
SALES
Pure In-Memory Columnar

Why is an In-Memory scan faster than the buffer cache?
SELECT COL4 FROM MYTABLE;
12
X
X
X
X
X
RESULT
Row Format
Buffer Cache

Why is an In-Memory scan faster than the buffer cache?
SELECT COL4 FROM MYTABLE;
13
RESULT
Column Format
IM Column Store
RESULT
X
X
X
X
X

In-Memory Compression Unit (IMCU)
• Contiguous storage per column in an IMCU
• CUs store Min/Max for some operations
• Multiple formats:
– For example, Dictionary Compression: CU stores
(smaller) dictionary IDs instead of full values
– Additional compression also possible
• Dictionary encoding uses cardinality of
Column to construct dictionary
– 50 US are stored in only 6 bits (<1 byte)
– Spelling out the state name is much longer
• The name “South Dakota” needs 12 characters or
24 unicode bytes (192 bits vs 6 bits)
14
0
1
3
2
0
2
3
Column CU
Min: South Dakota
Max: Utah
Dictionary
Query
Low
(Dict)
Column value list
South Dakota
Tennessee
Utah
Texas
South Dakota
Texas
Utah
Dictionary
VALUE ID
South Dakota 0
Tennessee 1
Texas 2
Utah 3

Column Format Enables Hardware Acceleration
• Oracle 12c only scans needed columns
• Processing values simultaneously
– SPARC DAX Software in Silicon
• SPARC M7 up to 220 Billion rows/sec
• Scans offloaded from cores
• M7 DAX scans data directly from memory
– Intel AVX instructions: 256-bit registers
• X86 E5 v3 up to 40 Billion rows/sec
• Scans consumes cores (4-8 threads max BW)
• Scanned data comes into caches
• Memory bandwidth is critical factor
– Single-thread performance does not
predict in-memory performance
SPARC M7 designed to accelerate in-memory scans & other in-memory
DAXorx86SIMD
Load
Multiple
Values
At same
time
Simultaneously
compare
multiple values
CPU
Memory
CA
CA
CA
CA
Example:
Find all sales
in state of CA
STATE

How does it impact
to environments

Complex System is Slowed by Analytic Indexes
• Most Indexes in complex OLTP
(e.g. ERP) databases are only
used for analytic queries
• Inserting one row into a table
requires updating 10-20 analytic
indexes: Slow!
• Indexes only speed up predictable
queries & reports
Table
1 – 3
OLTP
Indexes
10 – 20
Analytic
Indexes
17

Column Store Replaces Analytic Indexes
• Fast analytics on any columns
• Better for unpredictable analytics
• Less tuning & administration
• Column Store not persistent so
update cost is much lower
• OLTP & batch run faster
Table
1 – 3
OLTP
Indexes
In-Memory
Column Store
18

Test Case
(Load&Storage Data Scenario)
Have we tested

Proof of Concept – what is the concept to proof
20
• Thanks to new SPARC dedicated acceleration engines built on chip scalability
and performance of processing data with InMemory option should give much
better results than compared to other CPU platform (in this case Intel®)

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 21
Servers

Proof of Concept – what is the concept to proof
PoC
DB In-Memory
Acceleration
Decompression
Engines
Application
Data Integrity
Sub-microsecond
Cluster Messages
Software
in Silicon
Performance Reliability
Capacity Communication

Software in Silicon: Improving Performance
Reduce processing time by off-loading simple tasks to special purpose hardware
23
Software
processing
Hardware
processing
Software
processing
Processing
time
Hardware
processing
Application performance improves because software
processing supported by Software in Silicon is processed
by hardware
Without Software in Silicon With Software in Silicon

Decompress at memory speed >120 GB/sec
Software in Silicon: Accelerating Oracle Database 12c
One
step faster
Decompress
More than Doubles data size
Read
Software
scan
Read
Write
Write
Read
DAX
Write
Multiple
steps
SQL:
SELECT count(*)
…WHERE lo_orderdate = d_datekey
…AND lo_partkey = 1059538
AND d_year_monthnum BETWEEN 201311 AND 201312;
t

Database In-Memory Acceleration Engines
• New SPARC chip uses dedicated acceleration
engines built on chip
– Independently process streams of unaligned database
column elements of any size
• E.g. find all values that match ‘penguins’
• Frees CPU cores to run higher level SQL functions
• Reads data directly from memory and places
results in cache for core consumption
– Shared cache provides ultra-fast communication
Core
Shared Cache
SPARC CPU
Core Core Core
DB
Accel
DB
Accel
DB
Accel
DB
Accel

• SQL made up from few basic ops:
Filter/Search/Sort or
Join/Group/Aggregate
• First generation DAX (Query pipe)
accelerates
• Translate: HASH JOINs
• Scan: search (“WHERE” clause)
• Select: filter to reduce a column
• Decompression more important than
compression
• Reading outweighs writing
• Accelerate RLE, N gram, OZIP
DAX DB Acceleration in High Performance Kernel
Decompression and Query (Query Pipeline of DAX)
DAX Engine(s)
Core
Core CPU

Test Case
What was in
a methodology?

Methodology
28
• Throughput tests inspired on: ESG Lab Review
• Tests were issued with following criteria:
• Identical schemas with the same size were generated on both platforms within a single database
instance
•Data generated with SSB (https://github.com/electrum) - SCALEFACTOR=100
• Instance Caging used to reference to 6 oracle db cpu licenses
(resource_manager_plan=DEFAULT_PLAN):
• M7 cpu_count = 96 -> 12 cores
• Intel® Xeon® X5670 Processors (2.93 GHz): cpu_count = 24 -> 12 cores
• Intel® Xeon® E5-2699 v3 Processors (2.3 GHz) cpu_count = 24 -> 12 cores
• All data populated for in-memory
• Tables compressed with MEMCOMPRESS FOR QUERY HIGH for in-memory
• DOP used with DEGREE 8 on LINEORDER table
TABLE_NAME INMEMORY INMEMORY_COMPRESS NUM_ROWS
------------------------------ -------- ----------------- ----------
CUSTOMER ENABLED FOR QUERY HIGH 3000000
DATE_DIM ENABLED FOR QUERY HIGH 2556
LINEORDER ENABLED FOR QUERY HIGH 600037902
PART ENABLED FOR QUERY HIGH 1400000
SUPPLIER ENABLED FOR QUERY HIGH 200000

Methodology
29
• JMeter used to simulate users traffic with following settings:
• simulation iterations for simultaneous users 10,20,30,40,50,60,70,80,90,100
• following query was used:
select count(distinct(lo_custkey))
from( select lo_custkey
from lineorder,date_dim
where lo_orderdate = d_datekey
and d_weeknuminyear = :1
and d_year = :2
and lo_orderpriority <> :3
and lo_ordtotalprice between 7000 and 150000
group by lo_orderkey, lo_custkey
having count(lo_linenumber) =1);
• Bind variables values randomly picked from external .csv file
• Performance of InMemory processing analyzed with two metrics:
Query Throughput (tps) and Query Response Time (ms)

Test Case
Did we achieve
good results

SPARC M7:
Throughput and Response Time for 10,20,30,40,50,60,70,80,90,100 users

SPARC M7:
Response Time (ms) for 10,20,30,40,50,60,70,80,90,100 users

Intel® Xeon® X5670 :
Throughput and Response Time for 10,20,30,40,50 users

Intel® Xeon® X5670 :
Response Time(ms) for 10,20,30,40,50 users

Intel® Xeon® E5-2699 v3 :
Throughput and Response Time for 10,20,30,40,50,60,70,80,90,100 users

SPARC M7:
How to be sure that DAX is being used
Because:
• there are no DAX-specific wait events on database level to verify DAX usage
• there are no DAX-specific statistics on database level to verify DAX usage
Dtrace is the answer:
• one can trace libdax_query.so.1 libdax.so.1 usage
• use system level fbt provider (provides probes associated with the entry to and return from most
functions in the Solaris kernel) it provides modules and functions for DAX
Another way to trace DAX usage is busstat:
-physical CPU counters that can be used to determine the performance of DAX pipelines.
More details:
http://blog.ora-600.pl/2016/01/27/oracle-sparc-m7-tracing-dax-with-dtrace-and-busstat/

How to make it even
faster ?

Data Warehouse
Traditional OTLP & Analytics
• Key business processes slowed by traditional design
– Often working on “old” business data
ETL (GB/s)
Data Warehouse
Server
Many operations bottlenecked on IO & delays in updates between separate serversMany operations bottlenecked on IO & delays in updates between separate servers
on-disk
Row format
Millions IOPs
on-diskon-disk
Typical fast IO
40GB/s
OLTP
Server

• Avoid evaluating predicates against every
column value
– Check range predicate against min/max values
• As before, skip IMCUs where min/max disqualifies
predicate
– If min/max indicates all rows will qualify, no need
to evaluate predicates on column values
Min $4000
Max $7000
Min $8000
Max
$13000
Min $13000
Max $15000
Example: Find stores with sales between
$8000 and $14000
NO ROWS
Skip IMCU
SOME ROWS
Needs evaluation
ALL ROWS
Skip Evaluation
Predicate Optimization: Reduce Predicate Evaluations
?
40

SPARC M7 Decompression+Scan & Range Scan
Dcompress & Scan tasks occur in a single operation on SPARC M7
• SPARC M7 DAX offloaded acceleration
frees cores & common ops in one step
– Decompress & scan in one step
• Both RLE & Ozip decompression
– Range comparisons in one step
• “How many between start-date and end-date?”
41
Decompress
More than Doubles data size
One step in SPARC hardware
MemoryCompute
Read
MemoryCompute
Read
Software
scan
SQL:
SELECT count(*)
…WHERE lo_orderdate = d_datekey
…AND lo_partkey = 1059538
AND d_year_monthnum BETWEEN 201311 AND 201312;
time
Multiple steps in Software
DAX
10X
Faster
Read Write

SPARC M7 In-memory Advantages
SPARC M7 DAX is 1% of chip that can do the work of tens of cores
• DAX offloads the cores
– DAX avoids cache pollution by not scanning with cores
• DAX decompresses data at same rate as scan-only
• DAX performs one-step range scans
• SPARC M7 2x to 3x memory bandwidth for In-memory
42
SQL:
select sum(lo_extendedprice*lo_discount) as revenue
from lineorder, date_dim
where lo_orderdate = d_datekey and
d_year = 2012 and
lo_quantity between 6 and 25 and lo_discount between 1 and 3
Processes:
Decode values (DAX) & Sum aggregation (cores)
Hash Joins (cores)
Bloom Filter Joins (DAX & cores)
Scans (DAX)
Range Scans (DAX)
Analytics
M7 cores freed
for OLTP
DAX DAX
DAX: Database
Accelerator

Scan via software(including SIMD) consumes all of the cores
43
SALES (COMPRESSED)

DAX scan processing in DAX frees most of the cores for transactional processing
44
SALES (COMPRESSED)

Summary
45
SPARC M7 shows significantly better results in terms of Throughput and Response Time for
InMemory operations.
Thanks to Data Analytics Accelerators (DAX), which are in-memory query acceleration
engines performance is many times faster when compared to other processors .
It is noticeable for InMemory operations also in compressed format (DAX is able to operate
directly upon compressed IMCUs).
This makes SPARC M7 possible to perform real time analysis and fulfill business demands.

Oracle DB In-Memory technologie v kombinaci s procesorem M7

Oracle DB In-Memory technologie v kombinaci s procesorem M7

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Oracle DB In-Memory technologie v kombinaci s procesorem M7

Similar to Oracle DB In-Memory technologie v kombinaci s procesorem M7 (20)

More from MarketingArrowECS_CZ

More from MarketingArrowECS_CZ (20)

Recently uploaded

Recently uploaded (20)

Oracle DB In-Memory technologie v kombinaci s procesorem M7