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

Presenter

Presentation Notes

Title slide Add customer logo if applicable


• 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

Presenter

Presentation Notes

This is the roadmap for content of the meeting Adjust as necessary based on previous discussions on objectives and areas of interest Goal is to set expectations for content to be discussed Agree on specific meeting objectives/outcomes up front Inquire about any specific areas of interest or current needs that should be emphasized


POSTGRESinnovation

ENTERPRISEreliability

24/7 support

Services & training

Enterprise-class features & tools

Indemnification

Productroad-map

Control

Thousands of developers

Fast development

cycles

Low cost

No vendor lock-in

Advanced features

Enabling commercial adoption of Postgres

Presenter

Presentation Notes

KEY TAKEAWAY: EDB blends the best of open source PostgreSQL with the requirements of commercial Enterprises in our products and services


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

Presenter

Presentation Notes

KEY TAKEAWAY: EDB customers span government and commercial, worldwide and local companies, as well as all major business verticals.


Postgres Plus Advanced Server Postgres Plus

Cloud Database

High AvailabilityPerformanceManagement

REMOTEDBA 24x7

SUPPORTPROFESSIONAL

SERVICES

TRAINING

EDB Serves All Your Postgres Needs

PostgreSQL

Security

Presenter

Presentation Notes

KEY TAKEAWAY: EDB provides everything you need related to adopting Postgres. Overview of EDB products & Services NOTE: THIS SLIDE HAS BUILT-IN “JUMPING” SO YOU CAN CLICK ON ANY ICON TO DRILL DOWN THEN RETURN TO THE OVERVIEW; here’s how: Click on each icon (DBs and services) to drill down to details Once on detail page, click on the icon to move directly to the next icon detail, or Click on the area outside of the drill down detail to return back to the main product & services overview Main message: EDB is the BEST source for all your Postgres needs: EDB is a database internals product development company EDB creates add-on features, tools and cloud capabilities designed for enterprise-class workloads EDB’s deep technical expertise makes it your best source for support and professional services Sample script: “Just as you’d expect from any enterprise software company, EDB provides various products and services to ensure our customers make the most out of their Postgres deployments. From our standard edition which includes support for the open source PostgreSQL to PPAS and PPCD, we have the right database for your application. We back that up with global follow the sun support, packaged services and training along with RDBA services. Many of customers run PostgreSQL and come to us for support and to take advantage of our add-on functionality, such as PEM and xDB replication server. For lots of workloads this is a fine solution. The majority of our customers do run PPAS, though. The combination of its low cost--$6,900 per year per socket, along with a ton of additional features and functionality above the Standard Edition, it’s a great fit for workloads with lots of concurrent users and lots of transactions. Of course, PPCD gives customers the ability to run either PostgreSQL or PPAS, but in a cloud environment.”


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

Presenter

Presentation Notes

DBENGINES.COM – they use search engine data & web traffic information to make these rankings. This is more a measure of relevancy based on current-day interest levels rather than a market share report Postgres has a very well established foundation Postgres is consistently in the top 5 on DB-Engines rankings Postgres was second fastest growing database in 2013 Sample script: “DB engines ranks database popularity using a number of different formulas. While we know that Postgres is one of the most deployed database’s in the world—it’s included with virtually every linux distribution in the world, and is downloaded several million times a year, it’s also popular in terms of searches, jobs requiring the database skill set, and other factors. What’s more, Postgres was the second fastest growing database in 2013. Proof that enterprises are moving to the open source alternative. It’s also fascinating that the other two databases in the top 3 were NoSQL databases—mongo and cassandra. More proof that companies are looking at new ways to work”


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’ NoSQLCapabilities


• JSON is the most popular data-interchange format on the web

• Derived from the ECMAScriptProgramming 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

Presenter

Presentation Notes

Bruce


• Creating a table with a JSONB fieldCREATE 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_dataINSERT 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 productsON (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 JSONSimple ANSI SQL Table Definition

CREATE TABLE products (id integer, product_name text );

Select query returning standard data setSELECT * FROM products;

id | product_name ----+--------------1 | iPhone2 | Samsung3 | Nokia

Select query returning the same result as a JSON data setSELECT 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 TypesJSON is defined per RFC – 7159For more detail please refer http://tools.ietf.org/html/rfc7159

Presenter

Presentation Notes

Note: 1. JSON generally ignores any whitespace around or between syntactic elements (values and punctuation, but not within a string value). 2. JSON only recognizes four specific whitespace characters: i. the space ii. horizontal tab, iii. line feed, and carriage return. 3. JSON does not provide or allow any sort of comment syntax.


{"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

MarketingMarketing

Customer

Customer

Order

OrderOrder

Order

Customer

Order

Source Systems Landing Staging Integrated Data Model

CustomerCustomer


Customer Information

The NoSQL Only Approach


CRM

Order Management

Marketing

Billing

eCommerce

CRM

Order Management

MarketingMarketing

Customer

Customer

Customer

Customer

Order Information

OrderOrder

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

MarketingMarketing

Source Systems

Order

Order

Order

Order Information

Order

CustomerCustomer

Customer Information

CustomerCustomer

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!