Postgres: The NoSQL Cake You Can Eat

© 2014 EnterpriseDB Corporation. All rights reserved. 1

Postgres: The NoSQL Cake You Can Eat

Visit www.enterprisedb.com > resources to listen to the recording


•  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 Performance Management

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.


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 Customer


Customer Information

The NoSQL Only Approach


CRM

Order Management

Marketing

Billing

eCommerce

CRM

Order Management

Marketing Marketing

Customer

Customer

Customer

Customer

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 Customer

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!
