SQL for JSON: Rich, Declarative Querying for NoSQL Databases and Applications

©2015 Couchbase Inc. 2
Agenda
Why NoSQL?
 JSON Data Modeling
 SQL for JSON
 Java APIs
 Ecosystem

Major Enterprises Across Industries are Adopting NoSQL
3
CommunicationsTechnology
Travel & Hospitality Media &
Entertainment
E-Commerce &
Digital Advertising
Retail & Apparel
Games & GamingFinance &
Business Services

Why NoSQL?
Agility
Scalability
Performance
Availability

Why NoSQL? Agility
 Schema flexibility
 Easier management of change
 In the business requirements
 In the structure of the data
 Change is inevitable

Why NoSQL? Scalability
 Elastic scaling
 Size your cluster for today
 Scale out on demand
 Cost effective scaling
 Commodity hardware
 On premise or on cloud
 Scale OUT instead of Scale UP

Why NoSQL? Performance
 NoSQL systems are optimized for specific access patterns
 Low response time for web & mobile user experience
 Millisecond latency
 Consistently high throughput to handle growth

Why NoSQL? Availability
 Built-in replication and fail-over
 No application downtime when hardware fails
 Online maintenance & upgrade
 No application downtime

NoSQL Landscape
Document
• Couchbase
• MongoDB
• DynamoDB
• DocumentDB
Graph
• OrientDB
• Neo4J
• DEX
• GraphBase
Key-Value
• Couchbase
• Riak
• BerkeleyDB
• Redis
• … Wide Column
• Hbase
• Cassandra
• Hypertable

Properties of Real-World Data
 Rich structure
– Attributes, Sub-structure
 Relationships
– To other data
 Value evolution
– Data is updated
 Structure evolution
– Data is reshaped
Customer
Name
DOB
Billing
Connections
Purchases

Modeling Data in RelationalWorld
Billing
ConnectionsPurchases
Contacts
Customer
 Rich structure
 Normalize & JOIN Queries
 Relationships
 JOINS and Constraints
 Value evolution
 INSERT, UPDATE, DELETE
 ALTERTABLE
 Application Downtime
 Application Migration
 ApplicationVersioning

Using JSON For RealWorld Data
CustomerID Name DOB
CBL2015 Jane Smith 1990-01-30
Table: Customer
{
"Name" : "Jane Smith",
"DOB" : "1990-01-30”
}
Customer DocumentKey: CBL2015
 The primary (CustomerID) becomes the
DocumentKey
 Column name-Column value become
KEY-VALUE pair.
{
"Name" : {
"fname": "Jane ",
"lname": "Smith”
}
"DOB" : "1990-01-30”
}
OR

Using JSON to Store Data
CustomerID Name DOB
Table: Customer
{
"DOB" : "1990-01-30",
"Billing" : [
{
"type" : "visa",
"cardnum" : "5827-2842-2847-3909",
"expiry" : "2019-03"
}
]
}
CustomerID Type Cardnum Expiry
CBL2015 visa 5827… 2019-03
Table: Billing
 Rich Structure & Relationships
– Billing information is stored as a sub-document
– There could be more than a single credit card. So, use an array.

CustomerID Name DOB
Table: Customer
{
"DOB" : "1990-01-30",
"Billing" : [
{
"type" : "visa",
"cardnum" : "5827-2842-2847-3909",
"expiry" : "2019-03"
},
{
"type" : "master",
"cardnum" : "6274-2542-5847-3949",
"expiry" : "2018-12"
}
]
}
CustomerID Type Cardnum Expiry
CBL2015 visa 5827… 2019-03
CBL2015 master 6274… 2018-12
Table: Billing
 Value evolution
 Simply add additional array element or
update a value.

CustomerID ConnId Name
CBL2015 XYZ987 Joe Smith
CBL2015 SKR007 Sam Smith
Table: Connections
{
"DOB" : "1990-01-30",
"Billing" : [
{
"type" : "visa",
"cardnum" : "5827-2842-2847-3909",
"expiry" : "2019-03"
},
{
"type" : "master",
"cardnum" : "6274-2542-5847-3949",
"expiry" : "2018-12"
}
],
"Connections" : [
{
"ConnId" : "XYZ987",
"Name" : "Joe Smith"
},
{
"ConnId" : ”SKR007",
"Name" : ”Sam Smith"
}
}
 Simply add new key-value pairs
 No downtime to add new KV pairs
 Applications can validate data
 Structure evolution over time.
 Relations via Reference

{
"DOB" : "1990-01-30",
"Billing" : [
{
"type" : "visa",
"cardnum" : "5827-2842-2847-3909",
"expiry" : "2019-03"
},
{
"type" : "master",
"cardnum" : "6274-2842-2847-3909",
"expiry" : "2019-03"
}
],
"Connections" : [
{
"CustId" : "XYZ987",
},
{
"CustId" : "PQR823",
"Name" : "Dylan Smith"
}
{
}
],
"Purchases" : [
{ "id":12, item: "mac", "amt": 2823.52 }
{ "id":19, item: "ipad2", "amt": 623.52 }
]
}
DocumentKey: CBL2015
CustomerID Name DOB
Customer
ID
Type Cardnum Expiry
CBL2015 visa 5827… 2019-03
CBL2015 maste
r
6274… 2018-12
CBL2015 SKR007 Sam Smith
CustomerID item amt
CBL2015 mac 2823.52
CBL2015 ipad2 623.52
CBL2015 SKR007 Sam
Smith
Contacts
Customer
Billing
ConnectionsPurchases

Models for Representing Data
Data Concern Relational Model
JSON Document Model
(NoSQL)
Rich Structure
 Multiple flat tables
 Constant assembly / disassembly
 Documents
 No assembly required!
Relationships
 Represented
 Queried (SQL)
 Represented
 Queried? Not until now…
Value Evolution  Data can be updated  Data can be updated
Structure Evolution
 Uniform and rigid
 Manual change (disruptive)
 Flexible
 Dynamic change

Why SQL for JSON
 NoSQL systems provide specializedAPIs
 Key-Value get and set
 Script based query APIs
 Limited declarative query
 Richer query is needed

Client Side Querying is Inadequate
Find High-Value Customers with Orders > $10000
Query customer
objects from
database
• Complex codes and logic
• Inefficient processing on client side
For each customer
object
Find all the order
objects for the
customer
Calculate the total
amount for each
order
Sum up the grand
total amount for all
orders
If grand total
amount > $10000,
Extract customer
data
Add customer to
the high-value
customer list
Sort the high-value
customer list
LOOPING OVER MILLIONS OF CUSTOMERS IN APPLICATION!!!

Goal of Query for JSON
Give developers and enterprises an expressive,
powerful, and complete language for querying,
transforming, and manipulating JSON data.

SQL for JSON: Rich, Declarative Querying for NoSQL Databases and Applications

Industry Is Choosing SQL to Query JSON
 JSON support in SQL
– IBM Informix
– Oracle
– PostgreSQL
– MySQL
 Microsoft: SQL for DocumentDB
 UC San Diego: SQL++
 Couchbase: N1QL

ResultSet

{
"DOB" : "1990-01-30",
"Billing" : [
{
"type" : "visa",
"cardnum" : "5827-2842-2847-3909",
"expiry" : "2019-03"
},
{
"type" : "master",
"cardnum" : "6274-2842-2847-3909",
"expiry" : "2019-03"
}
],
"Connections" : [
{
"CustId" : "XYZ987",
},
{
}
{
}
],
"Purchases" : [
{ "id":12, item: "mac", "amt": 2823.52 }
{ "id":19, item: "ipad2", "amt": 623.52 }
]
}
LoyaltyInfo ResultDocuments
Orders
CUSTOMER

N1QL examples
SELECT d.C_ZIP, SUM(ORDLINE.OL_QUANTITY) AS TOTALQTY
FROM CUSTOMER d
UNNEST ORDERS as CUSTORDERS
UNNEST CUSTORDERS.ORDER_LINE AS ORDLINE
WHERE d.C_STATE = ”NY”
GROUP BY d.C_ZIP
ORDER BY TOTALQTY DESC;
INSERT INTO CUSTOMER("PQR847", {"C_ID":4723, "Name":"Joe"});
UPDATE CUSTOMER c SET c.STATE=“CA”, c.C_ZIP = 94501
WHERE c.ID = 4723;

SELECT Statement
SELECT customers.id,
customers.NAME.lastname,
customers.NAME.firstname
Sum(orderline.amount)
FROM orders UNNEST orders.lineitems AS orderline
JOIN customers ON KEYS orders.custid
WHERE customers.state = 'NY'
GROUP BY customers.id,
customers.NAME.lastname
HAVING sum(orderline.amount) > 10000
ORDER BY sum(orderline.amount) DESC
• Dotted sub-document reference
• Names are CASE-SENSITIVE
• UNNEST to flatten the arrays
JOINS with Document KEY of
customers

Composable SELECT statement
SELECT *
FROM
( SELECT a, b, c
FROM us_cust
WHERE x = 1
ORDER BY x LIMIT 100 OFFSET 0
UNION ALL
SELECT a, b, c
FROM canada_cust
WHERE y = 2
ORDER BY x LIMIT 100 OFFSET 0) AS newtab
LEFT OUTER JOIN contacts
ON KEYS newtab.c.contactid
ORDER BY a, b, c
LIMIT 10 OFFSET 0

SELECT Statement Highlights
 Querying across relationships
– JOINs
– Subqueries
 Aggregation
– MIN, MAX
– SUM, COUNT, AVG,ARRAY_AGG [ DISTINCT ]
 Combining result sets using set operators
– UNION, UNIONALL, INTERSECT, EXCEPT

N1QL Query Operators [ 1 of 2 ]
 USE KEYS …
– Direct primary key lookup bypassing index scans
– Ideal for hash-distributed datastore
– Available in SELECT, UPDATE, DELETE
 JOIN … ON KEYS …
– Nested loop JOIN using key relationships
– Ideal for hash-distributed datastore
– Current implementation supports INNER and LEFT OUTER joins

N1QL Query Operators [ 2 of 2 ]
 NEST
– Special JOIN that embeds external child documents under their parent
– Ideal for JSON encapsulation
 UNNEST
– Flattening JOIN that surfaces nested objects as top-level documents
– Ideal for decomposing JSON hierarchies
JOIN, NEST, and UNNEST can be chained in any combination

N1QL Expressions for JSON
©2014 Couchbase, Inc. 34
Ranging over collections
• WHERE ANY c IN children SATISFIES c.age > 10 END
• WHERE EVERY r IN ratings SATISFIES r > 3 END
Mapping with filtering • ARRAY c.name FOR c IN children WHEN c.age > 10 END
Deep traversal, SET, and
UNSET
• WHERE ANY node WITHIN request SATISFIES node.type = “xyz” END
• UPDATE doc UNSET c.field1 FOR c WITHIN doc END
DynamicConstruction
• SELECT { “a”: expr1, “b”: expr2 } AS obj1, name FROM … // Dynamic object
• SELECT [ a, b ] FROM … // Dynamic array
Nested traversal • SELECT x.y.z, a[0] FROM a.b.c …
IS [ NOT ] MISSING • WHERE name IS MISSING

N1QL DataTypes from JSON
N1QL supports all JSON data types
 Numbers
 Strings
 Booleans
 Null
 Arrays
 Objects

N1QL DataType Handling
Non-JSON data types
– MISSING
– Binary
Data type handling
 Date functions for string and numeric encodings
 Total ordering across all data types
– Well defined semantics for ORDER BY and comparison operators
 Defined expression semantics for all input data types
– No type mismatch errors

Data Modification Statements
 UPDATE … SET … WHERE …
 DELETE FROM … WHERE …
 INSERT INTO … ( KEY,VALUE ) VALUES …
 INSERT INTO … ( KEY …,VALUE … ) SELECT …
 MERGE INTO … USING … ON …
WHEN [ NOT ] MATCHEDTHEN …
Note: Couchbase provides per-document atomicity.

Data Modification Statements
INSERT INTO ORDERS (KEY, VALUE)
VALUES ("1.ABC.X382", {"O_ID":482, "O_D_ID":3, "O_W_ID":4});
UPDATE ORDERS
SET O_CARRIER_ID = ”ABC987”
WHERE O_ID = 482 AND O_D_ID = 3 AND O_W_ID = 4
DELETE FROM NEW_ORDER
WHERE NO_D_ID = 291 AND
NO_W_ID = 3482 AND
NO_O_ID = 2483
JSON literals can be used in any
expression

Index Statements
 CREATE INDEX ON …
 DROP INDEX …
 EXPLAIN …
Highlights
 Functional indexes
– on any data expression
 Partial indexes

Index Overview: Secondary Index
 Secondary Index can be created on any
combination of attribute names.
 CREATE INDEX idx_cust_cardnum
customer(ccInfo.cardNumber, postalcode)
 Useful in speeding up the queries.
 Need to have matching indices with right key-
ordering
 (ccInfo.cardExpiry, postalCode)
 (type, state, lastName firstName)
"customer": {
"ccInfo": {
"cardExpiry": "2015-11-11",
"cardNumber”:"1212-232-1234",
"cardType": "americanexpress”
},
"customerId": "customer534",
"dateAdded": "2014-04-06",
"dateLastActive”:"2014-05-02”,
"emailAddress”:”iles@kertz.name",
"firstName": "Mckayla",
"lastName": "Brown",
"phoneNumber": "1-533-290-6403",
"postalCode": "92341",
"state": "VT",
"type": "customer"
}
Document key: “customer534”

Find High-Value Customers with Orders > $10000
SQL for JSON
API QUERY
VS.
Query customer
objects from
database
• Proven and
expressive query
language
• Leverage SQL
skills and
ecosystem
• Extended for
JSON
• Complex codes
and logic
• Inefficient
processing on
client side
For each customer
object
Find all the order
objects for the
customer
Calculate the total
amount for each
order
Sum up the grand
total amount for all
orders
If grand total
amount > $10000,
Extract customer
data
Add customer to
the high-value
customer list
Sort the high-value
customer list
SELECT Customers.ID, Customers.Name, SUM(OrderLine.Amount)
FROM Orders UNNEST Orders.LineItems AS OrderLine
JOIN Customers ON KEYS Orders.CustID
GROUP BY Customers.ID, Customers.Name
HAVING SUM(OrderLine.Amount) > 10000
ORDER BY SUM(OrderLine.Amount) DESC
LOOPING OVER MILLIONS OF CUSTOMERS IN APPLICATION!!!

Summary: SQL & N1QL
Query Features SQL N1QL
Statements
 SELECT, INSERT, UPDATE, DELETE,
MERGE
 SELECT, INSERT, UPDATE, DELETE,
MERGE
Query Operations
 Select, Join, Project, Subqueries
 Strict Schema
 StrictType checking
 Select, Join, Project, Subqueries
 Nest & Unnest
 Look Ma! NoType Mismatch Errors!
 JSON keys act as columns
Schema  Predetermined Columns
 Fully addressable JSON
 Flexible document structure
DataTypes
 SQL Data types
 Conversion Functions
 JSON Data types
 Conversion Functions
Query Processing
 INPUT: Sets ofTuples
 OUPUT: Set ofTuples
 INPUT: Sets of JSON
 OUTPUT: Set of JSON

Java APIs
Standard JDBC driver (JDBC 4.0 and 4.1)
– Also, standard ODBC Driver
JDBC/JSON driver
–Extends JDBC for JSON
SDKs with Custom Query APIs

JDBC Driver
– JDBC 4.0 and 4.1
– Build an application which
can query using SQL or
N1QL
– Allow easy access to NoSQL
data from BI and ETL tools,
as well as your own
applications
JDBC Interface

Conversion between ANSI SQL and N1QL/JSON
Simba Couchbase JDBC Driver
 Allows users to infer or define
schemas on schema-less JSON data
 Converts JSON data to relational
data
 Based on JDBC 4.0 and 4.1 Standard
 Full 64-bit and 32-bit support
 Full SQL & N1QL support
 Comprehensive unicode support
JDBC Driver
JDBCInterface
DriverImplementation
SQL-92 N1QL

import java.sql.*;
import java.util.*;
public class Demo {
public static void main(String[] args) {
String url = "jdbc:couchbase://localhost:8093";
try {
Connection conn = DriverManager.getConnection(url);
try {
System.out.println("Connection successful.");
} finally { conn.close(); }
} catch (SQLException e) { e.printStackTrace(); } }
}
JDBC: Connecting

private static void doQuery(Connection conn) {
try {
String query = "select SELECT d.C_ZIP, "
+ "SUM(ORDLINE.OL_QUANTITY) AS TOTALQTY "
+ "FROM CUSTOMER d "
+ "GROUP BY d.C_ZIP ";
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(query);
}
catch (SQLException e) {
System.out.println("Error: " +
e.getLocalizedMessage());
}
}
JDBC: Executing Queries

Can change the driver to execute in N1QL mode by appending the following to the
connection URL:
;UseN1QLMode=1
Try the following N1QL query:
SELECT beer.name as beer_name, beer.abv, brewery.name as
brewery_name FROM `beer-sample` beer JOIN `beer-sample`
brewery ON KEYS [ beer.brewery_id ] WHERE beer.abv > 5 and
beer.style != "Lager" and beer.type = "beer" and
brewery.type = "brewery" ORDER BY beer.abv DESC LIMIT 5;
JDBC: Executing in N1QL Mode

Java JSR-374
 https://www.jcp.org/en/jsr/detail?id=374
This JSR is to provide an update for the Java API for JSON Processing Specification (JSON-P)
There are 3 goals for this JSR.
• Support for JSON Pointer and JSON Patch
• Add editing/transformation operations to JSON object model
• Update the API to work with Java SE 8
 JDBC will need to add enhanced JSON support.
– Couchbase has engaged with JDBC Committee

SDKs with Custom Query APIs
// raw string query
N1qlQueryResult queryResult =
bucket.query(N1qlQuery.simple("SELECT * FROM beer-sample LIMIT 10"));
// using the DSL
N1qlQueryResult query = bucket.query(select("*").from("beer-sample").limit(10));
bucket
.query(N1qlQuery.simple(select("*").from(i("beer-sample")).limit(10)))
.flatMap(AsyncN1qlQueryResult::rows)
.toBlocking()
.forEach(row -> System.out.println(row.value()));
• Fluent APIs for N1QL
• Use Domain Specific Language extensions
• Works well with query builders to provide features like auto completion
• Provides help with complex expressions like CASE,ANY, EVERY, etc.
• Supports parameter Passing
• Supports querying asynchronously

Ecosystem Integration

Try SQL for JSON
N1QL is available in Couchbase 4.0
–http://query.couchbase.com
–Online Interactive Tutorial
Ask us questions
– Couchbase forums, Stack Overflow, @N1QL

SQL for JSON: Rich, Declarative Querying for NoSQL Databases and Applications

Recommended

More Related Content

What's hot (20)

Similar to SQL for JSON: Rich, Declarative Querying for NoSQL Databases and Applications (20)

More from Keshav Murthy (20)

Recently uploaded (20)

SQL for JSON: Rich, Declarative Querying for NoSQL Databases and Applications

Editor's Notes