NoSQL Now: Postgres - The NoSQL Cake You Can Eat

© 2014 EnterpriseDB Corporation. All rights reserved. 1
Postgres: The NoSQL Cake You
Can Eat
October 30, 2014

• 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!
Agenda

POSTGRES
innovation
ENTERPRISE
reliability
24/7
support
Services
& training
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
Cloud Database
High Availability
PerformanceManagement
REMOTE
DBA 24x7
SUPPORT
PROFESSIONAL
SERVICES
TRAINING
EDB Serves
All Your Postgres Needs
PostgreSQL
Security

Postgres’ Growth
“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.”
Postgres is widely recognized
for its long history of proven
success and future promise

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

Why do developers like NoSQL only solutions?
The NoSQL Conundrum
• 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

Problems and fallacies of NoSQL (only)
The NoSQL Conundrum
• 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

Data Standards
The NoSQL Conundrum
• 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?

Data Islands
The NoSQL Conundrum
• 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.

NoSQL data models include data access paths
The NoSQL Conundrum
• 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

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

• 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’ NoSQL
Capabilities

• 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)
Postgres: Document Store

• 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
} ')
JSON Examples

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

• 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 –
A Natural Fit

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
JSON and ANSI SQL Example
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”}

• 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 Data Types
JSON is defined per RFC – 7159
For more detail please refer
http://tools.ietf.org/html/rfc7159

{
"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
}
JSON Data Type Example

A Customer and Order Example
360° view of the customer
• 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
Order
Management
Marketing
Billing
eCommerce
CRM
Order
Management
Marketing
Marketing
Customer
Customer
Order
Order
Order
Order
Customer
Order
Source Systems Landing Staging
Integrated
Data Model
Customer
Custo
mer

Customer Information
The NoSQL Only Approach
CRM
Order
Management
Marketing
Billing
eCommerce
CRM
Order
Management
Marketing
Marketing
Customer
Customer
Customer
Custo
mer
Order Information
Order
Order
Order
Order
Customer Collection • Document-oriented
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
Order
Management
Marketing
Billing
eCommerce
CRM
Order
Management
Marketing
Marketing
Source Systems
Order
Order
Order
Order Information
Order
Customer
Custo
mer
Customer
Information
Customer
Customer
N:M
• No hard coded relationships
• Multiple access methods
• Reuse for multiple use cases
• Two types of documents (Customers and Orders)
• Very fast implementation
• Differences in source data can be maintained

• 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
Data Integration –
The Not Only SQL Way

• 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!
Not Only SQL Rules!

NoSQL Now: Postgres - The NoSQL Cake You Can Eat

More Related Content

What's hot (20)

Similar to NoSQL Now: Postgres - The NoSQL Cake You Can Eat (20)

More from DATAVERSITY (20)

Recently uploaded (20)

NoSQL Now: Postgres - The NoSQL Cake You Can Eat