prof. dr.-ing. wolfgang lehner 200. datenbankstammtisch · - nosql systems hard to program, e.g....
TRANSCRIPT
2
Data Growth
Von 2000 bis 2002 sind mehr Daten generiert worden als in den 40.000 Jahren davor
Von 2004-2005 hat sich diese Datenmenge wiederum vervierfacht
Datenvolumen 2012: 2,5 Zetabytes, d.h. 10x das Datenvolumen von 2006!
Datenvolumen 2020: 100 Zettabytes
Nicht nur Datenvolumen, sondern insbesondere auch Datenvielfalt wächst.
BitKom (2012)
One Minute of Internet
3
Data, data, everywhere…
Unstructured, coming from sources that haven’t been mined before
Compounded by internet, social media, cloud computing, mobile devices, digital images…
Exponential. Every 2 days we create as much data as from the Dawn of Civilisation to 2003*
Hard to keep up. Communication Operators managing petabyte scale expect 10-100 x times data growth in next 5 years**
5
Smart Everything
- Smart „things“
- Smart places
- Smart networks
- Smart services
- Smart solutions
„Smart-*“ infrastructure
need to make things Smart…!
Requirements for “Smart Everything”
- Interactive (“tangible”) low latency
- High volume high throughput
6
…from smart phone to smart lenses
http://ngm.nationalgeographic.com
novel Big Data Analytics apps with ms-response time
incorporating local context as well as global state
your personal coupon arrived!!!
Buy x get y free
7
Big Computing
First Phase of the next generation HRSK - 7.000 cores
Second Phase (by end of March 2015) - >40.000 cores in total
8
Observation 1: Infrastructure
Massive computing power in cloud/cluster environments
Huge variety of „mobile/distributed“ devices - Significant computing power
in “mobile” devices
Significant communication and computing capabilities
5G Lab Germany
9
Observation 2: Computing Hardware
(1) Main Memory and non-volatile memory as the main driver
Main-Memory is KING, disk is DEAD
(2) Non-Uniform Memory Access requires data-centric database system architectures
Shared Everything (within a box)
(3) Dark Silicon Effect allows for highly-specific chip sets
Application support on chip-level (“DB on a chip”)
10
Observation 3: Data Production Process
Different steps with quality gates - from raw data to knowlegde extraction
Data
integration/
annotation
Data
extraction /
cleaning
Data
aquisition
Data
analysis and
visualization
Inter-
pretation
13
…a plea for specialized DB systems
They are selling “one size fits all“
Which is 30 year old legacy technology that good at nothing Is/Was he right?
(almost 10 years ago!)
14
The Extremes
strict consistency
internal data format (data lock-in)
sophisticated access method
defined schema (semantics known to the system/optimizer)
semantics of the operators known to the system (closed set of operators)
only read access, focus on scalability
use (CSV) files as data container
scan and shuffle methods
schema defined during query time (schema on the fly)
2nd order functions; semantics of the operator is totally unknown to the system, only a contract exists between operators and infrastructure
? ?
operators
schema
data
DBMS
data
operators
schema
MR Infrastructure
Application
15
Limits of classical DB systems
perserving consistency in a distributed encironment is costly…
ensure serializability even if the application can ensure no conflicting writes
necessity to put data completely into control of the system (effort to load data into a database system, perform runstats, …)
no native support for regular CSV files
-> optimize time to query
need to follow the „data comes first, schema comes second principle
… with the data model – the tabular model is still very popular (with flexibility)
… with the query model – SQL is just fine (everybody knows SQL)
- NoSQL systems hard to program, e.g. Cassandra 1.0 did not ensure consistency within a row!
- responsibility is left to the application programmer (e.g. store redundant hash codes to compare versions at the application level)
R1 recovery for queries/statements, no easy compensation of loosing a node
16
Impact on Database Systems
Extreme data
Extreme performance
Dynamo
“Three things are important in the database world: performance, performance and performance.“ Bruce Lindsey
25
A Look at Hardware Trends - 2015
25
Extreme NUMA Effects
Sys
tem
Le
vel
Application-Specific Instruction Sets
Co
mp
on
en
t Le
vel
Storage-Class Memory
1
2 3
27
TA versus Data-oriented Architecture (DORA)
…
Data
…
Data
Indirection
Transactions
Transaction-Oriented Architecture shared-everything
Data-Oriented Architecture mixed shared-everything & shared-
nothing
Lack of scalability
No load balancing & indirection required
Scales on massive parallel systems
Load Balancing and indirection required
Energy proportional by design Not energy proportional by design
Pros & Cons
Challenges
(1) Speed up load balancing indirection to work efficiently for in-memory systems
(2) How to make the data-oriented architecture energy proportional
Well investigated and widely deployed
Which Architecture
? …
Transactions
28
ERIS Data Management Core
data-oriented architecture (via message passing)
NUMA awareness
heterogeneous hardware
aggressive elasticity strategies
dynamic data placement policies
dynamic loading
… an academic playground for modern DB techniques
30
What‘s Next? Wireless Interconnects!
Optical interconnects, …
High-speed, short-range wireless links
Antennas and Wave Propagation for Adaptive Wireless Backplane Communication
31
A Look at Hardware Trends - 2015
31
Extreme NUMA Effects
Sys
tem
Le
vel
Application-Specific Instruction Sets
Co
mp
on
en
t Le
vel
Storage-Class Memory
32
xPU Developments and Consequences
32
http://upload.wikimedia.org/wikipedia/en/c/ce/Clock_CPU_Scaling.jpg
http://www.extremetech.com/wp-content/uploads/2012/02/CPU-Scaling.jpg
33
Motivation of „DB Processor“
HW/SW Co-design based on customizable processor
Application-specific ISA extensions
Tool flow & short HW development cycles
35
Selectivity: Intersection
35
0
200
400
600
800
1000
1200
1400
1600
1800
0 10 20 30 40 50 60 70 80 90 100
DBA_2LSU_EIS w/ partial loading DBA_1LSU_EIS w/ partial loading
DBA_2LSU_EIS w/o partial loading DBA_1LSU_EIS w/o partial loading
DBA_1LSU 108MiniFinal processor
+1 Load-Store unit
Data bus: 32->128 bit
+ Partial loading
+ Extended ISA
𝑏
38
A Look at Hardware Trends - 2015
38
Extreme NUMA Effects
Sys
tem
Le
vel
Application-Specific Instruction Sets
Co
mp
on
en
t Le
vel
Storage-Class Memory
39
Storage Class Memory / Non-Volatile RAM
Examples: MRAM(IBM), FRAM (Ramtron), PCM(Samsung)
Merging Point between storage and memory
39
Adapted from: M. K. Qureshi, V. Srinivasan, and J. A. Rivers. Scalable high performance main memory system using phase-change memory technology. In ISCA 2009
~4x denser than DRAM
SCM does not consume energy if not used
SCM is cheaper, persistent, byte-addressable
Number of writes is limited (life expectancy 2-10 years)
SCM has higher latency than DRAM
- Read latency ~2x slower than DRAM
- Write latency ~10x slower than DRAM
40
SCM Access // File Level
Application may distinguish between - Traditional memory
- Persistent memory blocks
Files names are used as identification handle
40
Shows how to get persistent memory to the application level
Requires a persistent memory-aware file system
Direct access to regions of persistent memory inside the application
41
Hybrid Storage Architecture for Column Stores
Write optimized store (WOS)
Read optimized (compressed) store (ROS)
41
update/insert/delete
REDO log
savepoint data area
merge/ tuple mover
• Dictionary compressed • Unsorted dictionary • Efficient B-tree structures
• Compression schemes according to existing data distribution
• Sorted dictionary • Optimized for HW-scans
42
NVRAM for ROS-Structure
With prefetching: average penalty for using SCM instead of DRAM is only 8%.
Without prefetching: average penalty for using SCM instead of DRAM is 41%.
For operators with sequential memory access patterns, SCM performs almost as good as DRAM
42
43
NVRAM for WOS-Structure
Skip List read/write performance on DRAM and SCM
47% penalty for reads, and 43-47% penalty for writes for using SCM instead of DRAM.
Writing persistent and concurrent data structures is NOT trivial
43
44
Experiment: Recovery Performance
Different recovery schemes. TATP scale factor 500, 4 users. The database is crashed at second 15.
Scenario 1: rebuild all secondary data structures before starting answering queries.
Scenario 2: rebuild secondary data structures in the background and start immediately answering queries using primary, persistent data. Recovery area decreased by 16%.
Scenario 3: similar to scenario 2, with 40% persistent secondary data structures. Recovery area decreased by 82%. Throughput decreased by 14%.
Scenario 4: all secondary data structures are persistent. Recovery area decreased by 99.8%. Throughput decreased by 30%.
44
46
Summary and Conclusion
In General – Big Data is an enabler! – NOT a final product
Let‘s head for new frontiers!
Significant developments on infrastructure level
Significant developments in the hardware sector - HTM, SCM, etc.
- Heterogenous systems (speclialized cores)
… Big Data is MUCH more than just a lot of data, it‘s all about orchestration, quality control, and interpretation