postgres advances on nosql

© 2014 EnterpriseDB Corporation. All rights reserved. 1

You (probably) don’t need NoSQL (with Postgres) May 2014


•  Marc Linster −  Senior Vice President, Products and

Services, EDB

EDB Presenters

•  Bruce Momjian −  EDB Senior Database Architect −  Core contributor to PostgreSQL −  Co-founder of the PostgreSQL Global

Development Group


•  Address NoSQL technologies & associated workloads •  Explore Postgres NoSQL capabilities •  Help you understand your needs

Objectives


NoSQL Lessons from the ‘Asphalt Jungle’


•  Where did the Humvee come from? −  Where cool stuff always comes

from – the US military

•  Why did they make Humvees? −  The military needed “Jeeps on

Steroids”

Let’s Ask Ourselves …

•  What does the Humvee accomplish? −  It carries troops safely, reliably and (arguably) comfortably (beats

walking)

•  Why did they have to build it? −  The old Army Jeeps couldn’t cut it


•  Where did NoSQL come from? −  Where all cool tech stuff comes from – Internet companies

•  Why did they make NoSQL? −  To support larger data loads and evolving demands for ways

to work with new data types

•  What does NoSQL accomplish? −  Enables you to work with bigger loads and new data types:

email, mobile interactions, machine data, social connections

•  Why did they have to build something new? −  There were limitations to most relational databases

Let’s Ask Ourselves, Why NoSQL?


I Need One! (You Want One)


•  There are four major NoSQL technologies −  Key-value stores, e.g. Redis −  Document databases, e.g. MongoDB (JSON) −  Columnar stores: Cassandra −  Graph databases: Neo4j

•  They all take different approaches and have different features and drawbacks

Now You Too Can Have One of Your Own!


•  Massive write scaling is required, more than what a single server can provide

•  Only simple data access pattern is required

•  It’s acceptable to allocate additional resources •  Strong data retention or transactional guarantees are

not required

•  Unstructured duplicate data is acceptable −  Application handles duplicate data issues −  Compression can also help

You Might Need a Hummer When …


•  Ferry around a whole soccer team −  Manage huge data dumps of log files

•  Tell your neighbors (and maybe an ex) something about yourself −  Analyze customer transactions

•  Ride out a snowstorm −  Web session data where scaling is an

issue

Because Your Hummer Can …

•  Power up when you need to Drive Big and you just don’t care −  Massive amounts of data and lots of concurrency (and little need

for durability)


A Place for Hummer - Real-world Apps

•  Emergency Management System −  High variability among data sources required high schema

flexibility

•  Massively Open Online Course −  Massive read scalability, content integration, low latency

•  Patient Data and Prescription Records −  Efficient write scalability

•  Social Marketing Analytics −  Map reduce analytical approaches

Source: Gartner, A Tour of NoSQL in 8 Use Cases, by Nick Heudecker and Merv Adrian, February 28, 2014


•  Features and functions of relational databases were confining, so NoSQL sacrifices: −  A powerful query language −  A sophisticated query optimizer −  Data normalization −  Joins −  Referential integrity −  Durability

But, You Give Up a Few Things


•  Reporting is Difficult −  Data must be brought to the client

for analysis, e.g. no aggregates or data analysis functions

−  Schema-less data requires complex client-side knowledge for processing

So, Try Parking One


•  Application design is more complex −  Without powerful query language and query optimizer, the

client software is responsible for efficiently accessing data and for data consistency

−  The application is in charge of managing data duplication and referential integrity

How About Finding a Good Mechanic?

−  Core logic in the application introduces maintenance and consistency headaches


•  Durability is not part of the database −  No ACID compliance means administrators are responsible for

data retention

And, Take Nothing for Granted


Oh, And the Gas Mileage Was an Issue


Here is What You Do Need


Reliable, Stylish–And Has a Few Tricks


Postgres has many NoSQL features without the drawbacks: •  Do some off-road riding

−  Schema-less data types, with sophisticated indexing support

•  Switch to four-wheel drive on the fly −  Transactional schema changes with rapid additional and

removal of columns

Postgres: The Best of Both Worlds

•  Great options packages −  Durable by default, but

controllable per-table or per-transaction


•  Postgres was originally architected to be an object-relational database

•  Extensible (e.g. PostGIS extension for geospatial)

•  Supports objects and classes in the schemas and

Key Qualities Give Postgres NoSQL Powers

query language •  Supports custom

data types and methods


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

•  Supported by virtually every programming language

•  New supporting technologies (also supported by Postgres) continue to expand JSON’s utility −  PL/V8 JavaScript extension −  PL/Coffee V8 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


•  Supported since 2006, the HStore contrib module enables storing key/value pairs within a single column

•  Allows you to create a schema-less, ACID compliant key value store within Postgres

Postgres: Key-value Store

•  Combines flexibility with ACID compliance

•  Create single HStore column and include, for each row, only those keys which pertain to the record

•  Add attributes to a table and query without advance planning


•  The spirit of open source community has led to the development of Foreign Data Wrappers

•  Foreign Data Wrappers (SQL MED) allow queries to read and write data to foreign data sources.

•  Foreign database support includes: −  CouchD, Informix, MongoDB, MySQL −  Neo4j, Oracle, Postgres, Redis

Database Federation with Postgres


•  NoSQL = Non-durable tables •  Postgres = Unlogged tables •  With v9.1, Postgres introduced the capacity to prioritize

data for recovery should the system fail in exchange for better application performance

Durability and Performance Trade-offs in Postgres


Ask yourself if you need the following: •  ACID compliance •  Relationships among data

•  Reporting demands •  The ability to interface with other data sources

Do YOU Need NoSQL?


•  Postgres is Not Only SQL (NoSQL is No SQL) •  Fully ACID compliant •  Proven track record

•  Fully capable of handling the variety, velocity and volume requirements of most applications

•  Tackle NoSQL projects without leaving the capabilities of the relational model behind you

Postgres is the best of both worlds, and it’s open source!

Say ‘Yes’ to ‘Not Only SQL’


•  Document store with ACID and relational capabilities

•  Decades-long track record of quality and stability

•  TCO cost avoidance from new systems: −  Operational support −  Duplicated storage −  Software upgrades −  Monitoring & management −  Hardware −  Training −  Additional staffing

Expand the role of your workhorse relational DBMS to include many NoSQL use cases. Use specialized technologies for edge cases when required.

Why Choose When You Can Have Both?


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