NoSQL overview #phptostart turin 11.07.2011
3 likes2,111 views
This document discusses NoSQL databases as an alternative to relational databases. It provides background on new requirements from web companies that led to the rise of NoSQL, such as high availability, scalability, and flexibility in data structures. Various NoSQL database models are presented, including key-value stores, document databases, and graph databases. The document highlights tradeoffs between consistency, availability, and partition tolerance based on Brewer's CAP theorem. Examples of popular NoSQL databases like Dynamo, Cassandra, and Neo4J are also mentioned.
![A Graph RDBMS
Lookup david’s id [Log(N)]
N = # users
Look K Followees [Log(N)]
Get their names [K*Log(N)]](https://image.slidesharecdn.com/php4biz-110714071556-phpapp02/85/NoSQL-overview-phptostart-turin-11-07-2011-48-320.jpg)
NoSQL overview #phptostart turin 11.07.2011
- 1. Torino, 11 luglio 2011 NoSQL PHP.TO.START David Funaro
- 2. 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
- 3. Database - logical model Other RDBMS NOSQL
- 4. Relational DB • In the *70’s • SQL ,relational algebra & set theory • excellent for applications such as management ( accounting, reservations, management staff)
- 5. ACID Transactions work in the right mode if the database can satisfy this four properties: • Atomic • Consistency • Isolation • Durability
- 6. Database - logical model Other RDBMS NOSQL
- 7. Database - logical model
- 8. Database - logical model Document Oriented Column Key Oriented Value Graph DB NOSql
- 9. NOSql !=
- 10. NOSql != One Size fits all Not Only Sql
- 11. Historical Intro The concept of “non relational database” is older than the “relational model” but has been resumed and improved technology comes back
- 12. New Requirements
- 14. New Requirements half *90’s with the new internet-based systems the Consistency and the Security of data are no longer enough
- 15. New Requirements half *90’s with the new internet-based systems the Consistency and the Security of data are no longer enough the new need is the Hight availability
- 16. Google • distributed storage system • scale file dimension up to Petabyte Wide applicability Scalability High performance High availability
- 17. Google BigTable column - Oriented DB • Web indexing • Google Earth • Google Finance • Orkut • Custom Search • Google Docs
- 18. Amazon • Relational model doesn’t fit requirements • 10 of thousand of server around the world • 10 Millions customers High Reliability High scale
- 19. Amazon Dynamo Key-Value Store Database • High Reliability • High Scale
- 20. New Trends
- 21. 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
- 22. 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
- 23. 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
- 24. Compromise • SQL Renounce • less strict transactions
- 25. Query Language Leave a standard query language like SQL, and embrace a different kind of query language based on the selected product • SQL like • map-reduce • SparQL • ...
- 26. CAP Theorem(2009) • Consistency • Availability • Partition Tollerance Eric Brewer It’s impossibile to have all of them at the same time in a distributed system.You have to choose only two.
- 27. 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
- 28. 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
- 29. Facebook Cassandra • Key-Value store • data model: BigTable • infrastructure: Amazon-Dynamo • Eventual Consistency • High Availability
- 30. Search Best Solution Just find the right way to manage your data-set
- 31. context purpose Technology Focus Cost of implementation
- 32. choose bike => (climb the mountain)
- 33. choose bike => (climb the mountain)
- 34. choose bike => (climb the mountain)
- 35. choose bike => (climb the mountain)
- 36. choose bike => (climb the mountain) Know available tools
- 37. NOSql Families
- 38. Key Value Store One Key -> One Value it’s like an HASH db knows information about “key” type (integer, float, ...), nothing about the value very fast ‘name’ => ‘david’ key value
- 39. Key Value Store performance high Scalability high • redis • memcached Flexibility high • dynamo Complexity none • voldemort Functionality variabile(none)
- 40. Document Oriented • key -> document • structured document • schema-less { name: ‘david’, surname: ‘funaro’, age: ’18’, user_13 => mail: { home : ‘[email protected]’, key office: ‘[email protected]‘ } } document
- 41. Document Oriented performance high Scalability variable (high) Flexibility high Complexity low Functionality variabile(low)
- 42. Graph DB • composed by Vertices and Edges • Vertices connected by Edges • Edge has a Label and Direction • Edges and Vertices have Properties
- 43. Graph DB Funaro surname David na User_2 me friend User_1 dnsee work friend User_3 fri en d User_3
- 44. Graph DB performance variable Scalability variable • neo4J Flexibility high • OrientDB Complexity high • infogrid • VertexDB Functionality graph theory
- 45. Why NOSql some case example
- 46. A Graph RDBMS Users Followee id name salary id_1 id_2 2 4 1 ale 200 3 1 2 marco 230 3 4 3 david 340 3 2 1 5 4 sergio 349 5 3 5 andre 200 5 2
- 47. A Graph RDBMS Users Followee id name salary id_1 id_2 2 4 handled as BTree101 1 ale 200 3 1 2 marco 230 3 4 3 david 340 3 2 1 5 4 sergio 349 5 3 5 andre 200 5 2
- 48. A Graph RDBMS Lookup david’s id [Log(N)] N = # users Look K Followees [Log(N)] Get their names [K*Log(N)]
- 49. Graph DB Marco Sergio Lookup David Log(N) David Lookup for Followees O(K) Andrea Ale
- 50. Benchmark Deph 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/
- 51. Schema RDBMS NOSql - Documentale CREATE 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`) );
- 52. Schema 2 id name surname mobile url ... telex office telex ... 1 david funaro 3548 davidfunaro.com null null 3548631 null null 2 alessandro nadalin 3257 null null null 32458 5456 null 3 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
- 53. Schema less • flexibility to handle the data model fields • the model can grow easily
- 54. 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/benchmarks http://research.yahoo.com/files/ycsb-v4.pdf
- 56. OrientDB library for PHP 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 )
- 57. Thanks • David Funaro • http://davidfunaro.com • @ingdavidino • [email protected]
- 58. credits http://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/