Postgres: The NoSQL Cake You Can Eat

Postgres: The NoSQL Cake You
Can Eat
Visit www.enterprisedb.com > resources to listen to the recording
© 2014 EnterpriseDB Corporation. All rights reserved. 1

Agenda
• About EDB
• Do more with Postgres
• The NoSQL conundrum
• Not only SQL – technology innovation on a
robust platform
• An example: 360° view of the
customer
• Not only SQL rules!

POSTGRES
innovation
Services
& training
ENTERPRISE
reliability
24/7
support
Enterprise-class
features & tools
Indemnification
Product
road-map
Control
Thousands
of developers
Fast
development
cycles
Low cost
No vendor
lock-in
Advanced
features
Enabling commercial
adoption of Postgres

EDB Customers
EDB currently has over 2,500 total customers including 50 of the Fortune
500 and 98 of the Forbes Global 2000

Postgres Plus
Advanced Server Postgres Plus
Management Performance
Cloud Database
High Availability
REMOTE
DBA 24x7
SUPPORT
PROFESSIONAL
SERVICES
TRAINING
EDB Serves
All Your Postgres Needs
PostgreSQL
Security

Postgres’ Growth
Postgres is widely recognized
for its long history of proven
success and future promise
“We congratulate MongoDB, PostgreSQL and Cassandra for their extraordinary
achievements in 2013….The fact that we have three open source tools and two NoSQL
systems amongst the winners may be an indication of what 2014 has in store for us.”

Gartner 2014 ODBMS Magic Quadrant
• EnterpriseDB is the primary
contributor to the
PostgreSQL Community
• EnterpriseDB's … is now
more than sufficient to run
both mission-critical and
nonmission-critical
applications.
• Infor, a major application
platform independent
software vendor, added
EnterpriseDB as a DBMS
platform choice.
• Reference customers
continue to identify the
compatibility with Oracle,
the stability of the DBMS
and the product support as
strengths.

Do more with Postgres

Do more with Postgres
How to do more
with Postgres
Open source alternative to
commercial RDBMS
• Reduce cost
• Leverage in-house talent
• Flexible license model
RDBMS platform for
new developments
• Proven RDBMS
• SQL compliant
• Extremely stable
Innovative DBMS Platform
• Not only SQL (SQL + JSON/KVP)
• Web 2.0 friendly
• Foreign Data Wrappers
• PostGIS

The NoSQL Conundrum
Why do developers like NoSQL-only solutions?
• Easy integration with Web 2.0 development style
− JSON is mapped all the way from the web page to the database
• Little/no knowledge of SQL required
• Who needs data normalization?
• “I don’t need no DBA”
• The data model is developed as the application matures
– schema-less works well with Agile and Sprints
• Get up and running really quickly

The NoSQL Conundrum
Problems and fallacies of NoSQL (only)
• Data silos
− Data standards
− Data islands
− Data access
• Technology silos
− New database technology
− Backup, recovery, replication, tuning, maintenance
• Lack of integration with corporate data standards
• Data models include data access paths
− Customers > Orders or Orders > Customers

The NoSQL Conundrum
Data Standards
• Structures and standards emerge!
• Data has references (products link to catalogs;
products have bills of material; components appear in
multiple products; storage locations link to ISO country
tables)
• When the database has duplicate data entries, the
application has to manage updates in multiple places –
what happens when there is no ACID transactional
model?

The NoSQL Conundrum
Data Islands
• Solutions exist in context
• Applications must be integrated
− Orders flow to the warehouse
− Invoices go to AP
− Customer data must tie into the CRM
• Data must be managed
“By 2017, 50% of data stored in NoSQL DBMSs will be damaging
to the business due to a lack of applied information governance
policies and programs.”
Dec. 3, 2013 Research Note “Does Your NoSQL DMBS Result in Information
Governance Debt?” by Nick Heudecker and Ted Friedman.

The NoSQL Conundrum
Data models include data access paths
• Document-based models
encourage hierarchical
data models
• Fast and easy access for
the intended use case
− What did this customer order?
− When did they order?
− How much did they order?
• Really problematic when the use case
changes
− Which customers ordered
Widget A in January?
Customer
Document
Order
Sub-document
Order Line
Sub-document
Product
Sub-document

Not Only SQL - Technology
Innovation on a Robust Platform

Postgres + Documents (JSON) + KVP
(HSTORE)
Best possible “Not Only SQL” solution

Postgres’ NoSQL
Capabilities
• HSTORE
− Key-value pair
− Simple, fast and easy
− Postgres v 8.2 – pre-dates many NoSQL-only solutions
− Ideal for flat data structures that are sparsely populated
• JSON
− Hierarchical document model
− Introduced in Postgres 9.2, perfected in 9.3
• JSONB
− Binary version of JSON
− Faster, more operators and even more robust
− Postgres 9.4

Postgres: Document Store
• JSON is the most popular
data-interchange format on the web
• Derived from the ECMAScript
Programming Language Standard
(European Computer Manufacturers
Association).
• Supported by virtually every
programming language
• New supporting technologies
continue to expand JSON’s utility
− PL/V8 JavaScript extension
− Node.js
• Postgres has a native JSON data type (v9.2) and a JSON parser and a
variety of JSON functions (v9.3)
• Postgres will have a JSONB data type with binary storage and indexing
(coming – v9.4)

JSON Examples
• Creating a table with a JSONB field
CREATE TABLE json_data (data JSONB);!
• Simple JSON data element:
{"name": "Apple Phone", "type": "phone", "brand":
"ACME", "price": 200, "available": true,
"warranty_years": 1}!
• Inserting this data element into the table json_data
INSERT INTO json_data (data) VALUES !
!(’ { !"name": "Apple Phone", !
! !"type": "phone", !
! !"brand": "ACME", !
! !"price": 200, !
! !"available": true, !
! !"warranty_years": 1 ! !!
!} ')!

A query that returns JSON data
SELECT data FROM json_data;!
data !
------------------------------------------!
{"name": "Apple Phone", "type": "phone",
"brand": "ACME", "price": 200,
"available": true, "warranty_years": 1}!
This query returns the JSON data in its
original format

JSON and ANSI SQL –
A Natural Fit
• JSON is naturally integrated
with ANSI SQL in Postgres
• JSON and SQL queries use
the same language, the same
planner, and the same ACID compliant transaction
framework
• JSON and HSTORE are elegant and easy to use
extensions of the underlying object-relational model

JSON and ANSI SQL Example
SELECT DISTINCT
product_type,
data->>'brand' as Brand,
data->>'available' as Availability
FROM json_data
JOIN products
ON (products.product_type=json_data.data->>'name')
WHERE json_data.data->>'available'=true;
product_type | brand | availability
---------------------------+-----------+--------------
AC3 Phone | ACME | true
ANSI SQL
JSON
No need for programmatic logic to combine SQL and
NoSQL in the application – Postgres does it all

Bridging between SQL and JSON
Simple ANSI SQL Table Definition
CREATE TABLE products (id integer, product_name text );!
Select query returning standard data set
SELECT * FROM products;
!
id | product_name !
----+--------------!
1 | iPhone!
2 | Samsung!
3 | Nokia!
Select query returning the same result as a JSON data set
SELECT ROW_TO_JSON(products) FROM products;
{"id":1,"product_name":"iPhone"}
{"id":2,"product_name":"Samsung"}
{"id":3,"product_name":"Nokia”}

JSON Data Types
• 1. Number:
− Signed decimal number that may contain a fractional part and may use exponential
notation.
− No distinction between integer and floating-point
• 2. String
− A sequence of zero or more Unicode characters.
− Strings are delimited with double-quotation mark
− Supports a backslash escaping syntax.
• 3. Boolean
− Either of the values true or false.
• 4. Array
− An ordered list of zero or more values,
− Each values may be of any type.
− Arrays use square bracket notation with elements being comma-separated.
• 5. Object
− An unordered associative array (name/value pairs).
− Objects are delimited with curly brackets
− Commas to separate each pair
− Each pair the colon ':' character separates the key or name from its value.
− All keys must be strings and should be distinct from each other within that object.
• 6. null
− An empty value, using the word null
JSON is defined per RFC – 7159
For more detail please refer http://tools.ietf.org/
html/rfc7159

JSON Data Type Example
{
"firstName": "John", -- String Type
"lastName": "Smith", -- String Type
"isAlive": true, -- Boolean Type
"age": 25, -- Number Type
"height_cm": 167.6, -- Number Type
"address": { -- Object Type
"streetAddress": "21 2nd Street”,
"city": "New York”,
"state": "NY”,
"postalCode": "10021-3100”
},
"phoneNumbers": [ // Object Array
{ // Object
"type": "home”,
"number": "212 555-1234”
},
{
"type": "office”,
"number": "646 555-4567”
}
],
"children": [],
"spouse": null // Null
}

360° view of the customer
A Customer and Order Example
• The traditional way:
− Landing, Staging, Normalizing
• The NoSQL Way:
− Use the schema-less data model to maintain the original data
formats for customers and orders
− Align orders with customers in one large collection of customer
order documents
• The Not Only SQL Way:
− Use the schema-less data model to maintain the original data
formats for customers and orders
− Link customers and orders with a flexible N:M relationship

The traditional approach
CRM
CRM
Order
Order
Management
Management
Billing
eCommerce
Marketing
Marketing
Marketing
Customer
Customer
Order
Order
Order
Order
Customer
Order
Source Systems Landing Staging Integrated
Data Model
Customer
Custo
mer

The NoSQL Only Approach
Customer Collection • Document-oriented
Customer Information
CRM
CRM
Order
Order
Management
Management
Billing
eCommerce
Marketing
Marketing
Marketing
Customer
Customer
Customer
Custo
mer
Order Information
Order
Order Order
Order
approach
• Very fast
implementation
• Differences in
source data can be
maintained
• Orders belong to
customers (sub
documents) or
vice-versa
• Hard codes the
data access
model!
• Limited reuse!

The Not Only SQL Approach
CRM
CRM
Order
Order
Management
Management
Billing
eCommerce
Marketing
Marketing
Marketing
Source Systems
• Two types of documents (Customers and Orders)
• Very fast implementation
• Differences in source data can be maintained
Order Information
Order
Order
Order
Order
Customer
Custo
mer
Customer
Information
Customer
Customer
N:M
• No hard coded relationships
• Multiple access methods
• Reuse for multiple use cases

Data Integration –
The Not Only SQL Way
• Use JSON schema-less data where
appropriate (customers and orders)
• Leverage SQL structures and
relationships where possible (who bought what when)
• Design for reuse – do not encode the initial use case
into the data model
• Create highly reusable data models
• Build on well-established technology platforms that
integrate with your IT environment and that support
your data strategy

Not Only SQL Rules!
• Use structures and relationships where appropriate, be flexible
everywhere else
− Use JSON for data with high degrees of variability
− Use the flexibility of JSON to bridge multiple formats and data
elements
− Use SQL to make relationships explicit – don’t hard code them
• Leverage a single tech platform to avoid tech silos, skills silos and
data silos
• Focus on creating value-add, not on setting up yet another
infrastructure
• Build on the most advanced open source DBMS’s Capabilities
Do more with Postgres!

Postgres: The NoSQL Cake You Can Eat

More Related Content

What's hot

Similar to Postgres: The NoSQL Cake You Can Eat

More from EDB

Recently uploaded

Postgres: The NoSQL Cake You Can Eat