• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
NoSQL overview #phptostart turin 11.07.2011
 

NoSQL overview #phptostart turin 11.07.2011

on

  • 4,200 views

overview of noslq database

overview of noslq database

Statistics

Views

Total Views
4,200
Views on SlideShare
1,859
Embed Views
2,341

Actions

Likes
3
Downloads
39
Comments
0

11 Embeds 2,341

http://davidfunaro.com 2239
http://dev.dnsee.com 65
http://ac4-intsqmcls-002.adx.pool.ac4.yahoo.com 13
http://flavors.me 8
http://lilly-dev 5
http://translate.googleusercontent.com 4
http://abtasty.com 3
http://twitter.com 1
http://ac4-intsqmcls-001.adx.pool.ac4.yahoo.com 1
http://webcache.googleusercontent.com 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    NoSQL overview #phptostart turin 11.07.2011 NoSQL overview #phptostart turin 11.07.2011 Presentation Transcript

    • Torino, 11 luglio 2011NoSQLPHP.TO.START David Funaro
    • What about me ?• sw engineer• PHP developer (2002)• Symfony Framework developer (2009)• Mobile developer ( iOs / Symbian )• Senior developer @ dnsee• PHP user group Rome Founder• Open Source contributor
    • Database - logical model Other RDBMS NOSQL
    • Relational DB• In the *70’s• SQL ,relational algebra & set theory• excellent for applications such as management ( accounting, reservations, management staff)
    • ACIDTransactions work in the right mode if thedatabase can satisfy this four properties: • Atomic • Consistency • Isolation • Durability
    • Database - logical model Other RDBMS NOSQL
    • Database - logical model
    • Database - logical model Document Oriented Column Key Oriented Value Graph DB NOSql
    • NOSql !=
    • NOSql !=One Size fits allNot Only Sql
    • Historical IntroThe concept of “non relational database” isolder than the “relational model” but has beenresumed and improved technology comes back
    • New Requirements
    • New Requirementshalf *90’s
    • New Requirementshalf *90’swith the new internet-based systems theConsistency and the Security of data are nolonger enough
    • New Requirementshalf *90’swith the new internet-based systems theConsistency and the Security of data are nolonger enoughthe new need is the Hight availability
    • Google• distributed storage system• scale file dimension up to Petabyte Wide applicability Scalability High performance High availability
    • Google BigTable column - Oriented DB• Web indexing• Google Earth• Google Finance• Orkut• Custom Search• Google Docs
    • Amazon• Relational model doesn’t fit requirements• 10 of thousand of server around the world• 10 Millions customers High Reliability High scale
    • Amazon Dynamo Key-Value Store Database• High Reliability• High Scale
    • New Trends
    • Web Company• Startup with explosive growth: • DBMS open source • v 1.0 - 1 node , becomes soon inadequate • next version: • Horizontal Partitioning (sharding) • implement the node routing inside the application logic
    • Web Company• Re-implement inter-node query• Handle inter-node transaction• Node failure increasingly likely - less reliability - less availability• “Hot” Data restructuring and data redistribuition becomes hard
    • Solution• Scalability, very simple operations, } but on many nodes• Performance, low latency web• Productivity Application• Flexibility (data structure) needs• Skill to distribute data on many nodes
    • Compromise• SQL Renounce• less strict transactions
    • Query LanguageLeave a standard query language like SQL, andembrace a different kind of query language basedon the selected product• SQL like• map-reduce• SparQL• ...
    • CAP Theorem(2009) • Consistency • Availability • Partition Tollerance Eric BrewerIt’s impossibile to have all of them at the sametime in a distributed system.You have to chooseonly two.
    • Consistency• Strong: After the update completes any subsequent access will return the updated N1 value.• Weak: The system does not guarantee that subsequent accesses will return the updated N2 value. tk tk• Eventually: The storage system guarantees that N6 if no new updates are made to the object tk eventually (after the inconsistency window tk closes) all accesses will return the last N5 updated value. N4
    • Consistency• Strong: After the update completes any subsequent access will return the updated N1 value.• Weak: The system does not guarantee that subsequent accesses will return the updated N2 value. tk tk• Eventually: The storage system guarantees that N6 if no new updates are made to the object tk eventually (after the inconsistency window tk closes) all accesses will return the last N5 updated value. N4
    • Facebook Cassandra• Key-Value store• data model: BigTable• infrastructure: Amazon-Dynamo• Eventual Consistency• High Availability
    • Search Best Solution Just find the right way to manage your data-set
    • contextpurpose Technology FocusCost of implementation
    • choose bike => (climb the mountain)
    • choose bike => (climb the mountain)
    • choose bike => (climb the mountain)
    • choose bike => (climb the mountain)
    • choose bike => (climb the mountain) Know available tools
    • NOSql Families
    • Key Value StoreOne Key -> One Valueit’s like an HASHdb knows information about “key” type(integer, float, ...), nothing about the valuevery fast ‘name’ => ‘david’ key value
    • Key Value Storeperformance high Scalability high • redis • memcached Flexibility high • dynamoComplexity none • voldemortFunctionality variabile(none)
    • Document Oriented• key -> document• structured document• schema-less { name: ‘david’, surname: ‘funaro’, age: ’18’, user_13 => mail: { home : ‘ing.davidino@gmail.com’, key office: ‘d.funaro@dnsee.com‘ } } document
    • Document Orientedperformance high Scalability variable (high) Flexibility highComplexity lowFunctionality variabile(low)
    • Graph DB• composed by Vertices and Edges• Vertices connected by Edges• Edge has a Label and Direction• Edges and Vertices have Properties
    • Graph DB Funaro surname David na User_2 me friend User_1dnsee work friend User_3 fri en d User_3
    • Graph DBperformance variable Scalability variable • neo4J Flexibility high • OrientDBComplexity high • infogrid • VertexDBFunctionality graph theory
    • Why NOSql some case example
    • A Graph RDBMS Users Followeeid name salary id_1 id_2 2 41 ale 200 3 12 marco 230 3 43 david 340 3 2 1 54 sergio 349 5 35 andre 200 5 2
    • A Graph RDBMS Users Followeeid name salary id_1 id_2 2 4 handled as BTree1011 ale 200 3 12 marco 230 3 43 david 340 3 2 1 54 sergio 349 5 35 andre 200 5 2
    • A Graph RDBMS Lookup david’s id [Log(N)] N = # users Look K Followees [Log(N)] Get their names [K*Log(N)]
    • Graph DB MarcoSergio Lookup David Log(N) David Lookup for Followees O(K) Andrea Ale
    • BenchmarkDeph RDBMS Graph 1 100ms 30ms • 1 Million Vertex 2 1000ms 500ms • 4 Million Edge 3 10000ms 3000ms • Scale Free Tolopogy 4 100000ms 50000ms • Postgres VS Neo4J 5 N/A 100000ms • Both Hash and BTree http://markorodriguez.com/2011/02/18/mysql-vs-neo4j-on-a-large-scale-graph-traversal/
    • Schema RDBMS NOSql - DocumentaleCREATE TABLE `pma_bookmark` ( `id` int(11) NOT NULL auto_increment, `name` varchar(255) NOT NULL default , `surname` varchar(255) NOT NULL default , `mobile` varchar(255) NOT NULL default , `url` text NOT NULL,... `name` varchar(255) NOT NULL default ,... Schema Less `telex` varchar(255) NOT NULL default , `fax` varchar(255) NOT NULL default , `office` text NOT NULL, PRIMARY KEY (`id`));
    • Schema 2id name surname mobile url ... telex office telex ...1 david funaro 3548 davidfunaro.com null null 3548631 null null2 alessandro nadalin 3257 null null null 32458 5456 null3 marco rossi 3548 null null null null 515648 null too value set to NULL user :{ user :{ user :{ name: david, name: alessandro, name: marco, surname: funaro, surname: nadalin, surname: rossi, mobile : 3454, mobile : 6262, telex: 3434 url: davidfunaro.com, office: 342343, } office: 3423423, telex: 3434 } }Each Document has only the required fields
    • Schema less• flexibility to handle the data model fields• the model can grow easily
    • Performance ====== SET ====== 100007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 ====== GET ====== 100000 requests completed in 1.23 seconds 50 parallel clients 3 bytes payload keep alive: 1 http://redis.io/topics/benchmarkshttp://research.yahoo.com/files/ycsb-v4.pdf
    • NOSql for PHP✓Redis✓MongoDB✓CouchDB✓Cassandra✓Memcached✴OrientDB
    • OrientDB library forPHP https://github.com/congow/Orient A Set of tools to use and manage any OrientDB instance from PHP. Orient includes: •the HTTP protocol binding •the query builder •the data mapper ( Object Graph Mapper )
    • Thanks• David Funaro• http://davidfunaro.com• @ingdavidino• ing.davidino@gmail.com
    • creditshttp://www.slideshare.net/ClaudioMartella/presentation-7398682?from=ss_embed http://www.slideshare.net/harrikauhanen/nosql-3376398 http://www.slideshare.net/ingdavidino/cmf-a-pain-in-the-f-phpday-05142011 http://it.wikipedia.org/wiki/Modello_relazionale http://www.slideshare.net/gabriele.lana/nosql-7405964 http://blog.indigenidigitali.com/l-ecosistema-nosql/ http://www.dia.uniroma3.it/~torlone/bd2/noSQL-1.pdf http://nosql-database.org/