Why SmartDB?

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Why SmartDB?
Toon Koppelaars
Real-World Performance
Oracle Server Technologies
Winter 2018

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.

SmartDB Definition
• SmartDB is about how you use, or fail to use, the database
• Do you use the database just as a persistence layer?
or
• Do you use the database as a processing engine?
3

Context of This Presentation
• DB: processing engine, or persistence layer?
Our scope is:
• Transactional (oltp) enterprise applications
– Data store as foundation  for which we use Oracle’s DBMS
– Much/complex CRUD functionality on top
– User interfaces, workflows, batches, reports, API's to other applications
– Potentially many users
• Not: data-warehouse, business-intelligence, big-data, ...
4
Retrieval Manipulation
Data store
Preliminaries

Transactional Enterprise Applications
• A big component of these applications is “Business Logic”
• What is “Business Logic”?
• And where do you position it to run?
– Inside application servers?
– Inside a “processing engine” database?
5
Preliminaries

Transactional Business Applications
• Conceptually three tiers
– Functionality exposed via interfaces
• GUI's for human interaction
• REST, Soap or otherwise, for software interaction
– Business logic
– Data store, relational database
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store
6
Preliminaries

Wiki
7
Business
Logic
SQL
SQLSQL
SQL
SQL
SQL
“If-then-else-loop” code with embedded data
access statements (= SQL) in it
The way the business requires this to be done
Preliminaries

We See Two Mutually Distinct Approaches
8
DBMS = Persistence Layer
"NoPlsql" Approach
DBMS = Processing Engine
"SmartDB" Approach
Preliminaries

Why SmartDB?
1. Requirements
2. Reasoning
3. Recommendations
9

Requirements
• We need to develop OLTP Enterprise Application
• It needs to be:
– Maintainable
– Good performance
– State of the art (user) interfaces
10

Reasoning
• It’s the data, stupid!
• Business logic, you say?
• I have to write SQL?
• Where is the volatility?
• Database is always 1st bottleneck, didn’t you know?
11

Reasoning: It’s the Data, Stupid!
12
– Business logic
– Data store: heart of the application, crown jewels
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store

• The heart of these applications, the crown jewels  data
• The way it’s organized = blueprint/foundation on which all else rests
• Different ways to structure this foundation
• History of different models of organizing data:
– Hierarchical data model
– Network data model
– Relational data model (what E.F. Codd gave us)
13

• Object oriented divagation to model data + behavior as one
– Hierarchical domain models have failed in maintainability aspect (déja-vu)
• In relational database design: every table is 1st class citizen
• For maintainability, it’s best to base your application on a sound relational
database design
– One that is genuinely designed relationally
– Not one that is derived from a OO domain model
14

Reasoning
15

Reasoning: Business Logic You Say?
16
– Business logic: guts of the application
– Data store, relational database
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store

• Viewed abstractly, core essence of business logic is this:
Two types of use-cases, code that
– Composes and executes transactions against data store
– Composes and executes queries on data store
Both in the way business requires this to be done
• Lets look at an example
17
Business
Logic
SQL
SQLSQL
SQL
SQL
SQL
“If-then-else-loop” code with
embedded data access statements in it

18
Single-row data access
Business logic
Row fetching (data access)
Business logic
Row-by-row updating (data access)
“if-then-else-loop” code
Primitive data access
(single table, row-by-row)
Business
logic

Point to be made  business logic can appear:
– As code-lines in some programming language that issues simple (poor) SQL
– As part of (rich) SQL
– Or a mix of both
19
Set-based data processing, aka “rich”SQL
Multiple tables referenced
Multiple rows processed
You declare what needs to be done.
Optimizer will translate this into code
equivalent with code on previous page

20
• Is there an impact on:
– Maintainability?
– Performance?

Reasoning
21

Reasoning: I Have to Write SQL?
• There are nearly always opportunities for your
business logic to be pushed into set-based SQL
• Why is this the case?
• There’s a fundamental reason for this...
22

23
The Real World
Us, living in the real
world, using natural
language to reason
with each other
about the real world
We reason in this
model using rich,
set-based, SQL
Application: model of a
small part of the real world
about which we want to
reason using computers
SQL is based on logic and set theory
Logic and set theory are based on
natural language, particularly the
parts of it that deal with reasoning

24
The Real World
Us, living in the real
world, using natural
language to reason
with each other
about the real world
We reason in this
model using rich,
set-based, SQL
Application: model of a
small part of the real world
about which we want to
reason using computers
SQL is based on logic and set theory
Logic and set theory are based on
natural language, particularly the
parts of it that deal with reasoning
So we reason in the model using
language that was based on how
we reason in the real-world
Ergo, SQL fundamentally fits what
we want to achieve

25
• Yes you do...
– TX’s and Q’s simply need to be hand-written
– The essence of them is always very business specific
• And preferably write SQL with business logic in it  set-based SQL
• It is natural fit for requirement at hand, being:
– Manipulating and retrieving data from database design

Reasoning
26

Reasoning: Where Is the Volatility?
27
 Here it is, the volatility…
– New hip tech-stacks every 1-2 years
– Paradigm-shifts every 6-7 years
– Never upwards compatible
• Lots of if-then-else-loop languages
 Stable technology SQL
– Upwards compatible since three decades
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store

• We want state-of-the-art user interfaces
– Since that layer is most volatile
– This is the layer where you want to be agile to the extreme
– We should architect such that we can easily swap out, swap in new tooling
• So *only* do UI in these tools
– If other stuff done in it (e.g. business logic), will make swap more expensive
• Question arises: how to interact between UI  business logic layer?
28

• Well, currently REST and JSON are in-swung
• Web server acts as proxy
• And using tools such as ORDS or node.js
 just translate REST request to DB-API call
29
DB-API’s
Web server
REST
ORDS

30
• Agility here with respect to tech tooling
• Agility here with respect to functional
changes (maintainability)
– What do we do here?
• Java, JavaScript, C#, PHP, Python, PL/SQL
• Agility here with respect to functional
changes (maintainability)
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store
Since we’re already
handwriting our SQL,
PL/SQL seems obvious
choice
Will provide easiest
impact-analysis

Reasoning
31

Reasoning: Database Is Always 1st Bottleneck
• Everybody knows this, right?
• This “common sense knowledge” has driven business logic out of the DBMS
– Away from PL/SQL, into other “outside” programming languages
• Flash news!
– The common sense knowledge, was a misconception
– SQL from outside is more expensive (2X) than SQL from inside (PL/SQL)
– The added expenses are higher than the gains of moving business logic out
– If-then-else-loop business logic is 20X more expensive in Java
32

33
Youtube: “toon koppelaars”
https://www.youtube.com/watch?v=8jiJDflpw4Y

• Four ways of doing SQL:
– Row-by-row from NoPlsql (ubiquitous)
– Row-by-row from Plsql (sometimes necessary)
– Set-based from NoPlsql (hardly ever seen, as ORM’s don’t work this way)
– Set-based from Plsql (very natural, successful 90’s approach)
34
Row-by-row SQL Set-based SQL
SQL from NoPLSQL Slow Not tested
SQL from PL/SQL Faster (2X) Superfast (20X)
You wanted
performance?

35
App
server
Database is always
first bottleneck100 TX/Sec
N
O
P
L
S
Q
L

36
App
server
App
server
Database is always
first bottleneck100 TX/Sec200 TX/Sec
N
O
P
L
S
Q
L

37
App
server
App
server
App
server
Database is always
first bottleneck100 TX/Sec200 TX/Sec300 TX/Sec
N
O
P
L
S
Q
L

38
App
server
App
server
App
server
App
server
Database is always
first bottleneck100 TX/Sec200 TX/Sec300 TX/Sec400 TX/Sec
N
O
P
L
S
Q
L

39
App
server
App
server
App
server
App
server
App
server
Database is always
first bottleneck100 TX/Sec200 TX/Sec300 TX/Sec400 TX/Sec500 TX/Sec
N
O
P
L
S
Q
L

40
App
server
App
server
App
server
App
server
App
server
Database is always
SmartDB will outscale
other approaches
N
O
P
L
S
Q
L
S
M
A
R
T
D
B
500 TX/Sec500 TX/Sec

41
App
server
App
server
App
server
App
server
App
server
Database is always
SmartDB will outscale
other approaches
N
O
P
L
S
Q
L
S
M
A
R
T
D
B
500 TX/Sec
Set-based SQL…
500 TX/Sec

Conclusions
• Requirements for our OLTP Enterprise Application:
– Maintainable
– Good performance
– State of the art (user) interfaces
• Lots of reasoning
• Recommendations
42

Recommendations
• Have relational database design as blueprint/foundation
•  Maintainability
– “Refactoring”: database design easiest in relational model
•  Performance
– Follow sound relational database design principles
– Don’t be scared to introduce yet-another-table
• “More tables = bad” myth
• Employ people who are educated and experienced in designing databases
43

Recommendations
• Use database as processing engine instead of persistence-layer only
•  Performance
– SmartDB architecture will outscale any other architecture
•  Maintainability
– Easiest when business logic in PL/SQL with set-based SQL
•  State of the art (user) interfaces
– Proper demarcation enables agility in top-layer
• Employ people who are experienced in (set-based) SQL and PL/SQL
44

Recommendations
45
"SmartDB" Approach
DBMS = Processing Engine

#SmartDB
• You’re doing #SmartDB project: SQL and PL/SQL are your main tools
– And use [insert-some-tech-here] to generate UI
– And use [insert-some-tech-here] to handle workflows
– And use [insert-some-tech-here] to handle event-processing
– And use [insert-some-tech-here] to handle batches
• All those [some-tech]’s just call database API’s
46

Why SmartDB?

Recomendados

Recomendados

Más contenido relacionado

Último

Último (20)

Destacado

Destacado (20)

Why SmartDB?