1 of 26

CSE 344: Section 7

NoSQL, SQL++

August 21st, 2025

2 of 26

Announcements

  • Homework 7:
    • Due at 10:00pm on Sunday, June 8th (NO LATE DAYS!)
  • Final Exam
    • Releasing: 10:20 am June 9th
    • Due: 10:20 am June 11th
  • All regular OH will be canceled during finals week
  • Questions?

3 of 26

Course Evals

4 of 26

Data Models

  • Key-value stores
    • Opaque value
    • e.g., Memcached, Redis
  • Document stores
    • “key-object”
    • e.g., SimpleDB, CouchDB, MongoDB, AsterixDB
  • Column-oriented
    • “column groups”
    • e.g., HBase, Cassandra, ClickHouse
  • Graph
    • E.g. Neo4j

5 of 26

Structured Data

6 of 26

Unstructured Data

7 of 26

Semi-structured Data

8 of 26

JSON

9 of 26

JSON and Semi-Structured Data

JSON, XML, Protobuf (also an IDL)

Familiar - as your HTTP request/response

  • Good for data exchange
  • Maps to OOP paradigm

Also - as a database file

  • Flexible tree-structured model
  • Query langs: XQuery, XPath, etc.

10 of 26

AsterixDB, SQL++

  • A semistructured NoSQL style data model (ADM)
  • Extends JSON with object database ideas

Know the following:

  • DDL: type (open vs. closed), data types (e.g. multiset), creating an index.
  • DML: Joins, Nesting / Unnesting.
  • (Asterix stores data as flattened tables behind the scenes)

11 of 26

What is SQL++?

Just like SQL but parsed for processing JSON data

SQL++ has keywords to handle collections of data (i.e. non-flat data)

Why design SQL++ like SQL? Why not some other query language?

People are used to/like specifying data through SQL syntax

SQL-like language enforces idea of physical data independence

12 of 26

SQL++

13 of 26

Output with Structure

If we wanted the name and a list of orders:

SELECT P.name, P.orders

FROM Person P;

{“name”: “Dan”, “orders”: [ { “date”: 1997, “product”: “Furby”} ]}

{“name”: “Alvin”, “orders”: [ {date”: 2000, “product”: “Furby”},

{date”: 2012, “product”: “Magic8”} ]}

14 of 26

Unnesting

If we wanted the name and each product separately:

SELECT P.name, O.product as product

FROM Person P, P.orders O;

{“name”: “Dan”, “product”: “Furby”}

{“name”: “Alvin”, “product”: “Furby”}

{“name”: “Alvin”, “product”: “Magic8”}

15 of 26

Nesting

If we wanted the name and all products as a list:

SELECT P.name, products

FROM Person P

LET products = (SELECT O.product FROM P.order O);

{“name”: “Dan”, “products”: [“Furby”] }

{“name”: “Alvin”, “products”: [“Furby”, “Magic8”]}

16 of 26

Nesting (Same)

If we wanted the name and all products as a list:

SELECT P.name, (SELECT O.product FROM P.order O)� AS products

FROM Person P;

{“name”: “Dan”, “products”: [“Furby”] }

{“name”: “Alvin”, “products”: [“Furby”, “Magic8”]}

17 of 26

Compare

If we wanted the name and all products as a list:

SELECT P.name, products

FROM Person P

LET products = (SELECT O.product

FROM P.order O);

{“name”: “Dan”, “product”: [“Furby”] }

{“name”: “Alvin”, “product”: [“Furby”, “Magic8”]}

If we wanted the name and each product separately:

SELECT P.name, O.product as product

FROM Person P, P.orders O;

{“name”: “Dan”, “product”: “Furby”}

{“name”: “Alvin”, “product”: “Furby”}

{“name”: “Alvin”, “product”: “Magic8”}

18 of 26

SQL++ Example

SELECT y.`-car_code` as code,

y.name as name

FROM geo.world x, x.mondial.country y

ORDER BY y.name;

19 of 26

Casing

“Find the encompassing continents for each country”

SELECT y.name, z.`-continent` as continent

FROM geo.world x, x.mondial.country y,

case when is_array(y.encompassed)

then y.encompassed

else [y.encompassed] end z

ORDER BY y.name;

20 of 26

Useful Keywords/Syntax

is_array( … ) -----> checks if value is an array

split(s, d) -----> splits string s on delimiter d

[ … ] -----> explicitly construct array

(CASE WHEN … THEN … ELSE … END) -----> combine with “is_array(…)

MISSING -----> reserved keyword like “NULL

` … ` -----> backtick needed for accessing keys with names containing “-

21 of 26

y)

22 of 26

23 of 26

NoSQL

  • No clear definition :\
    • Non-relational
    • + scalability, + availability, + flexibility
    • - consistency, - OLAP performance
    • Open source implementations
  • Motivation
    • The need to scale
    • Lots of web apps mostly OLTP queries
      • Read/write intensive
      • but fewer joins & aggregates

24 of 26

SQL vs NoSQL

Structure

Language

Scaling

Convergence

25 of 26

K/V Store Example

26 of 26

Worksheet