SQL is a powerful query language that has expressive powers for exploring and querying data. SQL combined with the flexibility, scale, availability and performance of NoSQL is a powerful combination. This presentation details the SQL language extensions required for adapting SQL to document model based NoSQL databases such as Couchbase Server.

1. SQL Gene in NoSQL
How SQL Extensions are making flexible data structures Query-able
Cihan Biyikoglu
cihanb@live.com - @cihangirb
NoSQL Now – Aug 2015 – San Jose

2. Agenda
 Nature of Data
 Relational vs NoSQL DatabaseApproach
 Extending SQL for JSON
1. Ingest JSON and Return JSON
2. Accessing JSON Hierarchies – the dot notation
3. Bring full syntax – including JOINs and Sub-Queries
4. Handle missing values – MISSING , UNSET
5. Fold & Unfold JSON Hierarchies
6. Native Set/Collection Handling
7. Adapt Indexing to JSON

3. Nature of Real-World Data
 Rich structure
 Attributes, Sub-structure
 Relationships
 To other data
 Value evolution
 Data is updated
 Structure evolution
 Data is reshaped

4. Models for Real-World Data
Data Concern Tabular Model Document Model
Rich Structure
 Multiple flat tables
 Constant assembly / disassembly
 Documents
 No assembly required!
Relationships
 Represented
 Queried (SQL)
 Represented
 Queried with limitations
Value Evolution  Data can be updated  Data can be updated
Structure Evolution
 Uniform and rigid
 Manual change (disruptive)
 Flexible
 Dynamic change

5. Models for Real World Data
Data Concern Tabular Model Document Model JSON + SQL
Rich Structure
 Multiple flat tables
 Constant assembly /
disassembly
 Documents
 No assembly
required!
 Document
Relationships
 Represented
 Queried (SQL)
 Represented
 Queried with
limitations
 SQL
Value Evolution  Data can be updated  Data can be updated  Data can be updated
Structure
Evolution
 Uniform and rigid
 Manual change
(disruptive)
 Flexible
 Dynamic change
 Flexible & Dynamic

6. For the Best of Both, Bring SQL to NoSQL
 From JSON
 Rich structure, no assembly
 Schema flexibility
 From SQL
 General, proven, and pervasive query capabilities
 Querying across relationships
SQL + JSON

7. For the Best of Both, Bring SQL to NoSQL
 SQL + JSON isn’t new and many are doing it already
 Couchbase Server, SQL++ , DocumentDB,
 Apache Spark, Datastax, RelationalGuys – SQL Server, Postgress,
MySQL, Memsql And so on…
However these implementation are very different!

8. SQL Extensions
Requirements for the Best SQL+JSON Implementation

9. Bring SQL to JSON
 Requirements for Full SQL + JSON Solution
1. Ingest JSON and Return JSON
2. Accessing JSON Hierarchies – the dot notation
3. Bring full syntax – including JOINs and Sub-Queries
4. Handle missing values – MISSING , UNSET
5. Fold & Unfold JSON Hierarchies
6. Native Set/Collection Handling

10. #1
 Ingest JSON and Return JSON
 Tables and Rows require constant assembly and disassembly…
VS

12. "default": {
"Company": "Some Company",
"Organization": {
"Research": {
"Robotics": {
"AI": {
"People": [
{
"manager": true,
"name": "p2"
},
{
"manager": false,
"name": "p3"
},
{
"manager": false,
"name": "p4"
}
]
#2
 Access the JSON Hierarchies - Dot Notation
<>.Company
<>.Organization.Research
<>.Organization.Research.Robotics.AI.People[0]

13. #3
 Bring full syntax – including JOINs and Sub-Queries
…You don’t need JOINs & Subqueries
in Document Models…

14. #3
Embedded vs. Referenced
{
“Name”: “Pike Brewing”,
…
“City”:”Seattle”,
“Country”:”USA”
}
“Beers”: [
{“Name”: “Blond”,
…
},
{“Name”:”Dark”,
…
}
],
Key: Brewery_Pike_Brewing
{
“Name”: “Pike Brewing”,
“Beers”:[“Pike_Brewing_Blond”,
“Pike_Brewing_Dark”],
…
“City”:”Seattle”,
“Country”:”USA”
}
Key: Brewery_Pike_Brewing
{
“Name”:”Pike Brewing Blond”,
“Type”:”Blond Beer”
…
}
Key: Pike_Brewing_Blond

15. #4
 Handling MissingValues
 Schema evolves fast and SQL should accommodate
SELECT * FROM …
WHERE (trips IS MISSING AND departing_code = …)
OR (trips IS NOT MISSING AND trips[0].departing_code = …)
v1 v2
{
“flight_plan_id”:…,
“departing_code”…,
“arriving_code”:…,
…
}
{
“flight_plan_id”:…,
“trips”:[
{“departing_code”…,
“arriving_code”:…},
{“departing_code”…,
“arriving_code”:…},
]
…
}

16. #5
 Fold and Unfold JSON Hierarchies
{
“flight_plan_id”:…,
“trips”:[
{“departing_code”:…,
“arriving_code”:…},
{“departing_code”:…,
“arriving_code”:…},
]
…
}

18. #6
 Native Set/Collection Handling
 Search a Level or Sub-Hierarchy
SELECT * FROM …
WHERE ANY item IN/WITHIN Robotics
SATISFY item.name=“P3”
Research
Robotics
AI
P1 P2
Speech
Listen
P3 P4
Speak
Group 1
P5
Group 2
P6
P3

20. Conclusion

21. Models for Real World Data
Data Concern Tabular Model Document Model JSON + SQL
Rich Structure
 Multiple flat tables
 Constant assembly /
disassembly
 Documents
 No assembly
required!
 Document
Relationships
 Represented
 Queried (SQL)
 Represented
 Queried with
limitations
 SQL
Value Evolution  Data can be updated  Data can be updated  Data can be updated
Structure
Evolution
 Uniform and rigid
 Manual change
(disruptive)
 Flexible
 Dynamic change
 Flexible & Dynamic

22. ThankYou
@cihangirb
cihanb@live.com
Cihan Biyikoglu