Ditching the Middleware
-
Upload
dataversity -
Category
Technology
-
view
269 -
download
2
description
Transcript of Ditching the Middleware
#nosql, like organic food, is defined by what it doesn't contain.
Comparing noSQL solutions is like comparing organic apples and
oranges...
Eric van der Vlist@evlist
25 July 2011
Agenda
• An architecture for communal, horizontal scaling
• Efficiency improvements over other architectures
• Multi-party participation
Three Tier Architecturel Separable tiers; easy to replace
l Separation allows for load balancing of tiers
l Secure database independently
Data Access Business Logic Presentation Logic
Data model changes effect all tiers:• your presentation• your processing model• your data schema.
Scaling OptionsVertical
Horizontal
Vertical Scaling Limits
• July 2011 (changes constantly):
• Amazon EC2: 68 GB RAM
• Rackspace Cloud: 16 GB RAM
• Custom build: M5000 with 512GB RAM
(CPU and disk harder to quantify/compare)
Horizontal Scaling Limits
vs.
Data throughput Optimistic reads?
ChoicesData Access
Business Logic
Presentation Logic
View Model
Controller
Choices
View Model
Controller
< >Objects
l Open Source community project to build a Linked Data Management System
l Visit callimachusproject.org
Callimachus
HTTP GETrequest
Class
Viewable
XMLtemplate apply.xsl
HTML
SPAR
QL
quer
y
RD
F re
spon
se
HTTPresponse
Web serverRDF Store
Resource
Controller
TemplateEngine
Data-View-Controller
ModelView
Controller
< >
View Templates
• Written in XHTML+RDFa (declarative pattern);
• Parsed to create SPARQL queries;
• Query results are filled into the same template.
RDFa queries
Results fill into template
Some (Single System) Advantages
• Minimal abstraction between interface and data (speed, fewer points of failure)
• Minimized queries per page: O(1), not O(n)
• Maximize caching opportunities due to small data elements
• Native optimistic reads
Some (Multi System) Advantages
• Each node has its own store (reduced contention)
• Mirroring of data segmentations for write control
• Theoretical ability to combine data from multiple writes; eventual consistency (RDF as fifth normal form with sufficient provenance information; currently unimplemented)
Case Study:Persistent URLs
Persistent URLs
• Redirection service via HTTP 3xx redirects
• purl.org operated by OCLC since 1995
• Supposed to be “persistent”PURL
Service
WebService
HTTP GET
302 (Found)
HTTP GET
200 (OK)
client
e.g.
Persistent URLs at US GPO
Data Master
Data Slave
DynamicDNS
Normal Ops
Failover /Spillover
PURL Federation
DynamicDNS
Normal Opsfor A.org
e.g. Failover /Spilloverfor A.org
Write-Segmenteddata source
PURL Servicesby different parties
A.org
B.com
C.net
PURL Federation
DynamicDNS
Normal Opsfor C.net
to any host
PURL Servicesby different parties
A.org
B.com
C.net
Callimachuscallimachusproject.org
Persistent URLspurlz.org
Thanks to:
• http://www.flickr.com/photos/vialetter/254383430/
• Callimachus and PURL contributors and sponsors, especially James Leigh
This work is Copyright © 2011 3 Round Stones Inc.It is licensed under the Creative Commons Attribution 3.0 Unported LicenseFull details at: http://creativecommons.org/licenses/by/3.0/
You are free:
to Share — to copy, distribute and transmit the work
to Remix — to adapt the work
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).
• For any reuse or distribution, you must make clear to others the license terms of this work.
• Any of the above conditions can be waived if you get permission from the copyright holder.
• Nothing in this license impairs or restricts the author's moral rights.
• Some Content in the work may be licensed under different terms, this is noted separately.