Post on 29-Jun-2015
description
© 2014 EnterpriseDB Corporation. All rights reserved. 1
Postgres: The NoSQL Cake You Can Eat
Visit www.enterprisedb.com > resources to listen to the recording
© 2014 EnterpriseDB Corporation. All rights reserved. 2
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 3
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
© 2014 EnterpriseDB Corporation. All rights reserved. 4
EDB Customers EDB currently has over 2,500 total customers including 50 of the Fortune 500 and 98 of the Forbes Global 2000
© 2014 EnterpriseDB Corporation. All rights reserved. 5
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
© 2014 EnterpriseDB Corporation. All rights reserved. 6
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
© 2014 EnterpriseDB Corporation. All rights reserved. 7
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.
© 2014 EnterpriseDB Corporation. All rights reserved. 9
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
© 2014 EnterpriseDB Corporation. All rights reserved. 10
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
© 2014 EnterpriseDB Corporation. All rights reserved. 11
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
© 2014 EnterpriseDB Corporation. All rights reserved. 12
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?
© 2014 EnterpriseDB Corporation. All rights reserved. 13
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.
© 2014 EnterpriseDB Corporation. All rights reserved. 14
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
© 2014 EnterpriseDB Corporation. All rights reserved. 15
Not Only SQL - Technology Innovation on a Robust Platform
© 2014 EnterpriseDB Corporation. All rights reserved. 16
Best possible “Not Only SQL” solution
Postgres + Documents (JSON) + KVP (HSTORE)
© 2014 EnterpriseDB Corporation. All rights reserved. 17
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 18
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 19
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 20
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
© 2014 EnterpriseDB Corporation. All rights reserved. 21
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 22
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
© 2014 EnterpriseDB Corporation. All rights reserved. 23
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”}
© 2014 EnterpriseDB Corporation. All rights reserved. 24
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 25
{ "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
© 2014 EnterpriseDB Corporation. All rights reserved. 26
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
© 2014 EnterpriseDB Corporation. All rights reserved. 27
The traditional approach
360° view of the customer
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
© 2014 EnterpriseDB Corporation. All rights reserved. 28
Customer Information
The NoSQL Only Approach
360° view of the customer
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!
© 2014 EnterpriseDB Corporation. All rights reserved. 29
The Not Only SQL Approach
360° view of the customer
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
© 2014 EnterpriseDB Corporation. All rights reserved. 30
• 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
© 2014 EnterpriseDB Corporation. All rights reserved. 31
• 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!