Building on Multi-Model Databases

© COPYRIGHT 2017 MARKLOGIC CORPORATION. ALL RIGHTS RESERVED.
Building on Multi-Model Databases
John Biedebach
Solution Director, MarkLogic
john.biedebach@marklogic.com
972-841-6060

SLIDE: 2 © COPYRIGHT 2017 MARKLOGIC CORPORATION. ALL RIGHTS RESERVED.
Agenda
 How to get unified views across disparate data models and formats within a single database
 The benefits of a single product vs multi-product Multi-Model approach to data integration
 The importance of agility in data access and delivery through APIs, interfaces, and indexes
 How to scale a multi-model database while still providing ACID capabilities and security
 How to determine where a multi-model database fits in your existing architecture

http://www.oreilly.com/data/free/building-
on-multi-model-databases.csp
MORE INFO

Hollerith Tabulator - 1890

IBM Punch Card

Mainframes

EF Codd

Relational Databases
 Relational Databases earn the name because prior to using them, you must define how the data
is “related”

The Problem With the Relational Approach
The Business Changes,
The Requirements Change,
The Source Data Changes
1
Take a Current
State Snapshot
Design the New
Data Model
Perform ETL
Create the
Indexes
2
3
4
Build the
Application
5
Restart Process
6

Simple Transaction

Simple Transaction
Transaction
Detail
Transaction
Header
StoreProduct

Hierarchical Data Model
 Document-centric database
- Supports any-structured data via hierarchical data model
- Stores compressed binary trees
Document
Title
Author Section
Section
Section
Section
Section
First Last
Metadata
Transaction
Detail
Customer
Store
Product
NamePrice Phone
Address

Transaction
<root>
<header>
<date>2017-01-05</date>
<store>321</store>
</header>
<detail>
<item>Spaghetti Sauce</item>
<qty>1</qty>
<price unit=”usd”>8.00</price>
<item>Garlic</item>
...
</detail>
</root>

The Document Model
 More natural and human-readable
 Heterogeneous data is okay (schema-
agnostic)
 Query across data harmoniously (e.g., search
for zip code, “94111”, returns both records)
 Group documents into collections (e.g., create
a collection for each source system)
 Insert/update/delete documents in a single
transaction – even if it changes the schema
{
"Customer_ID": 1001,
"Fname": "Paul",
"Lname": "Jackson",
"Phone": "415-555-1212",
"SSN": "123-45-6789",
"Addr": "123 Avenue ",
"City": "Someville",
"State": "CA",
"Zip": 94111
}
{ "Cust_ID" : 2001 ,
"Given_Name" : "Karen" ,
"Family_Name" : "Bender" ,
"Shipping_Address" : {
"Street" : "324 Some Road" ,
"City" : "San Francisco" ,
"State" : "CA" ,
"Postal" : "94111" ,
"Country" : "USA" } ,
"Billing_Address" : {
"Street" : "847 Another Ave" ,
"City" : "San Carlos" ,
"State" : "CA" ,
"Postal" : "94070" ,
"Country" : "USA" }
}
JSON
DOCUMENTS

2
3
1
4
1
Ingest Data As-Is
2
Access the Data
4
Operationalize
3
Harmonize & Enrich the Data

Data
Lineage

Harmonization

Multi-Model
 Document (XML or JSON)

Multi-Model
 Geospatial

Joins

RDF Triples
Subject Predicate Object
John IsMember PreSales
John IsSub Field_Org
John Field_OrgInfer:

RDF Triples
Subject Predicate Object
John IsMember PreSales
Derek IsMember PreSales
Derek IsManager PreSales

Multi-Model
 Geospatial
 RDF Triples

Multi-Model
 Geospatial
 RDF Triples (Semantic Data)
 Other Data:
- Social Media
- Videos, Photos
- Binary Documents
OTHER METHODS
REST APIs, Java Client API, Node.js Client API, Java / .NET XCC
JSON
XML
SEMANTIC
DATA
GEOSPATIAL
DATA
BINARY
Multi-Model

Agenda

JAVASCRIPT
XQUERY
SPARQL
SQL
TRANSACTIONAL
APPS
ANALYTICAL
APPS
Reference Architecture
JSON
XML
RDF
GEO
Ingest
BINARY
DATA INGESTION DATA STORAGE, MANAGEMENT, AND SEARCH APPLICATIONS
EVALUATION LAYER
(E-NODES)
DATA LAYER
(D-NODES)
INDEXES, SECURITY, MONITORING, MANAGEMENT
DATA ACCESS
DOWNSTREAM
SYSTEMS
REST API
JAVA API
NODE.JS API

Flexible Deployment
 Write the application once, run it anywhere
 Operate in the cloud
 Operate on-premises
CLOUD
PHYSICAL / VIRTUAL
DEPLOY

ACID Transactions
 100% ACID Transactions, not eventually or
strongly consistent
 Enables transactional/operational apps (e.g.
e-commerce solutions)
 Implemented using Multi-Version Concurrency
Control (MVCC)

Certified, Granular Security
 RBAC at the sub-document level
 Automatic security indexing enforced at the
database level for ALL data access
 Common Criteria Security Certification
PROVENANCEAVAILABILITY
CERTIFIED
AUTHENTICITYINTEGRITY
CONFIDENTIALITY
Common Criteria

BITEMPORAL CERTIFIED
SECURITY
ACID
TRANSACTIONS
FLEXIBLE
DEPLOYMENT
SCALABILITY
& ELASTICITY
HA/DR TIERED
STORAGE
Enterprise Requirements for Operational Systems
Capabilities Required
Must Never Lose Data
Must Deploy in Any Environment
Must Be Cost Effective
Must Be Secure
Must Address Industry Compliance Requirements
Must Scale Up & Down

Agenda

Is Multi-Model Right For You?
Good Fits
 Disparate Data
 Changing Schema
 Multiple Data Types
 Hard to Model
 Multiple Targets
 Master Data Mgmt
Poor Fits
 Great Fit for Relational
 Heavy Reliance on
Traditional BI Tools
 Lack of Institutional
Willingness

Mythbusters
 Multi-Model is not secure
 Multi-Model is not good for transactions
 Multi-Model is hard
 Multi-Model does not run in the cloud

http://www.oreilly.com/data/free/building-
on-multi-model-databases.csp
MORE INFO

Building on Multi-Model Databases

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Building on Multi-Model Databases

Similar to Building on Multi-Model Databases (20)

More from DATAVERSITY

More from DATAVERSITY (20)

Recently uploaded

Recently uploaded (20)

Building on Multi-Model Databases