Back to Basics, webinar 1: Introduzione a NoSQL
•Download as PPTX, PDF•
4 likes•2,573 views
Di Massimo Brignoli, Principal Solutions Architect presso MongoDB.
Recommended
Recommended
More Related Content
What's hot
What's hot (13)
Viewers also liked
Viewers also liked (16)
Similar to Back to Basics, webinar 1: Introduzione a NoSQL
Similar to Back to Basics, webinar 1: Introduzione a NoSQL (20)
More from MongoDB
More from MongoDB (20)
Back to Basics, webinar 1: Introduzione a NoSQL
- 2. Code MassimoB gets you a 25% discount off the list price Early Bird Registration Ended May 13, 2016
- 3. Back to Basics 2016 : Webinar 1 Introduzione a NoSQL Massimo Brignoli Principal Solution Architect, EMEA MongoDB @massimobrignoli V1.0
- 4. Benvenuti!
- 5. 5 Agenda Del Corso Date Time Webinar 24 Maggio 2016 11:00 CET Introduzione a NoSQL 07 Giugno 2016 11:00 CET La tua prima applicazione MongoDB 21 Giugno 2016 11:00 CET Schema Design – Pensare a Documenti 05 Luglio 2016 11:00 CET Indicizzazione avanzata: Indici Testuali e Geografici 19 Luglio 2016 11:00 CET Introduzione all’ Aggregation Framework 28 Luglio 2016 11:00 CET Messa in Esercizio
- 6. 6 Agenda di Oggi • Perché NoSQL • I vari tipi di database NoSQL • Vista dettagliata di MongoDB • MongoDB: Durabilità dei dati – Replica Set • MongoDB: Scalabilità – Sharding • Q&A
- 7. 7 Relazionale Linguaggio di Query espressivo & Indici Secondari Consistenza Forte Strumenti di Gestione Enterprise & Integrazioni
- 8. 8 Il Mondo è Cambiato Dati Rischio Tempo Costo
- 9. 9 NoSQL Scalabilità & Performance 24x7, Installazioni Globali FlessibilitàLinguaggio di Query espressivo & Indici Secondari Consistenza Forte Strumenti di Gestione Enterprise & Integrazioni
- 10. 10 Architettura Nexus Scalabilità & Performance 24x7, Installazioni Global FlessibilitàLinguaggio di Query espressivo & Indici Secondari Consistenza Forte Strumenti di Gestione Enterprise & Integrazioni
- 11. 11 Tipi di Database NoSQL • Key/Value • Column • Graph • Multi-model • Document
- 12. 12 Key Value • Sono un array associativo • Lookup per singola chiave • Velocissimo per ricerche su chiave singola • Pessimo per “reverse lookups” Key Value 12345 4567.3456787 12346 { addr1 : “The Grange”, addr2: “Dublin” } 12347 “top secret password” 12358 “Shopping basket value : 24560” 12787 12345
- 13. 13 Row Stores (RDBMS) • Memorizza I dati allineati per righe (RDBMS tradizionali, come MySQL) • Le letture restituiscono una riga completa • Le letture che richiedono solo uno o due campi sono uno spreco ID Name Salary Start Date 1 Joe D $24000 1/Jun/1970 2 Peter J $28000 1/Feb/1972 3 Phil G $23000 1/Jan/1973 1 Joe D $24000 1/Jun/1970 2 Peter J $28000 1/Feb/1972 3 Phil G $23000 1/Jan/1973
- 14. 14 Come memorizza i Dati un Column Store 1 2 3 ID Name Salary Start Date 1 Joe D $24000 1/Jun/1970 2 Peter J $28000 1/Feb/1972 3 Phil G $23000 1/Jan/1973 Joe D Peter J Phil G $24000 $28000 $23000 1/Jun/1970 1/Feb/1972 1/Jan/1973
- 15. 15 Perché è attraente? • Una serie di ricerche consecutive può restituire una colonna un modo efficiente • Comprimere dati simili è molto efficiente • Quindi le letture possono prendere dal disco più dati in un singola lettura • Le righe sono allineate in ordine o per rowID • Se avete bisogno di un piccolo sottinsieme di colonne non bisogna leggere tutta la riga. • Ma: – aggiornare e cancellare righe è molto costoso. • Modalità append-only • Meglio per l’OLAP che per l’OLTP
- 16. 16 Database a Grafo • Memorizza Grafi (archi e vertici) • Ad esempio Social Network • Disegnati per permettere un attraversamento efficiente • Ottimizzati per rappresentazione connessioni • Possono essere implmentati come database key-value con l’abilità di memorizzare links • Se il vostro caso d’uso non è un grafo, non avete bisogno di un database a grafi!
- 17. 17 Database Multi-Model • Combina storage diversi e modelli di accesso diversi • Spesso sono grafi più “qualcosa altro” • Risolve il problema del “polyglot persistence” mantenendo diversi database consistenti • E’ “the new new thing” nell’arena NoSQL • Ci si apetta che questi tipi di database abbiano maggiore risonanza.
- 18. 18 Database a Documenti • Non PDF, Microsoft Word o HTML • I Documenti sono strutture nidificate create usando Javascript Object Notation (JSON) { name : “Massimo Brignoli”, title : “Principal Solution Architect”, address : { address1 : “Piazzale Biancamano”, cap : “20010”, citta: “Milano” } expertise: [ “MongoDB”, “Python”, “Javascript” ], employee_number : 350 }
- 19. 19 I Documenti sono Tipizzati { name : “Massimo Brignoli”, title : “Principal Solution Architect”, Address : { address1 : “Piazzale Biancamano”, cap: ”20010” } expertise: [ “MongoDB”, “Python”, “Javascript” ], employee_number : 350, location : [ 53.34, -6.26 ] } Stringhe Documento Nidificato Array Intero Coordinate Geografiche
- 20. 20 MongoDB Capisce I Documenti JSON • Fin dalla primissima versione era un database nativo JSON • Interpreta e può indicizzare le sotto-strutture • Memorizza I JSON in un formato binario chiamato BSON • Efficiente per codifica e decodifica e per la trasmissione su rete • MongoDB può creare indici su qualunque campo • (Copriremo questi punti più avanti durante il corso)
- 21. 21 Perché I Documenti? • Schema Dinamico • Eliminazione del Layer di mappatura tra Oggetti/Relazionale • Denomalizzazione implicita dei dati per massimizzare le performance
- 22. 22 Perché I Documenti? • Schema Dinamico • Eliminazione del Layer di mappatura tra Oggetti/Relazionale • Denomalizzazione implicita dei dati per massimizzare le performance
- 23. 23 MongoDB è Ricco di Funzionalità Query Sofisticate • Find Paul’s cars • Find everybody in London with a car between 1970 and 1980 Grografiche • Find all of the car owners within 5km of Trafalgar Sq. Ricerca Testuale • Find all the cars described as having leather seats Aggregazio ni • Calculate the average value of Paul’s car collection Map Reduce • What is the ownership pattern of colors by geography over time (is purple trending in China?)
- 24. 24 AltaAffidabilità e Durabilità dei Dati – Replica Set SecondarySecondary Primary
- 25. 25 Creazione di un Replica Set SecondarySecondary Primary Heartbeat
- 26. 26 Replica Set: Caduta di un Nodo SecondarySecondary Primary No Heartbeat
- 27. 27 Replica Set: Recupero SecondarySecondary Heartbeat And Election Primary
- 28. 28 New Replica Set – 2 Nodi SecondaryPrimary Heartbeat And New Primary Primary
- 29. 29 Replica Set: Ripazione del Nodo SecondaryPrimary Secondary Rejoin and resync
- 31. 31 Scalabilità con lo Sharding Shard 1 Shard 2 Shard N
- 32. 32 Scalabilità con lo Sharding • La chiave di Shard partiziona il contenuto • MongoDB bilancia automaticamente il cluster • Gli shard possono essere aggiunti dinamicamente al sistema vivo • Il ribilanciamento avviene in sottofondo • La Shard key è immutabile • La Shard key può direzionare le query su uno shard specifico • Le query senza una shard key vengono mandati a tutti gli shard
- 33. 33 Scalabilità con lo Sharding MongoS MongoS Shard 1 Shard 2 Shard N Shard Key
- 34. 34 Indirizzamento delle Query • In un cluster partizionato usiamo uno strato di routing per guidare le query sugli shard corretti • Usiamo un demone chiamato MongoS (Mongo Shard Router) • Il Demone è stateless • Possono essere eseguiti tanti MongoS quanti sono richiesti • Normalmente un MongoS per ogni app server
- 35. 35 Sommario • Perché esistono I NoSQL • I tipi di database NoSQL • Le funzionalità principali di MongoDB • Durabilità dei Dati in MongoDB • Scalabilità in MongoDB
- 36. 36 Prossimo Webinar – La Tua Prima Applicazione MongoDB • 7 Giugno May 2016 – 11:00 CET. • Registratevi se non l’avete già fatto • Imparerete come realizzare la vostra prima applicazione di MongoDB • Creare database e collezioni • Uno sguardo alle queries • Costruire Indici • Iniziare a capire le performance • Registratevi su: http://bit.ly/1UA4BGM • Mandate feedback a back-to-basics@mongodb.com
- 37. Q&A
Editor's Notes
- Who I am, how long have I been at MongoDB.
- Delighted to have you here. Hope you can make it to all the sessions. Sessions will be recorded so we can send them out afterwards so don’t worry if you miss one. If you have questions please pop them in the sidebar.
- A lot of people expect us to come in and bash relational database or say we don’t think they’re good. And that’s simply not true. Relational databases has laid the foundation for what you’d want out of a database, and we absolutely think there are capabilities that remain critical today Expressive query language & secondary Indexes. Users should be able to access and manipulate their data in sophisticated ways – and you need a query language that let’s you do all that out of the box. Indexes are a critical part of providing efficient access to data. We believe these are table stakes for a database. Strong consistency. Strong consistency has become second nature for how we think about building applications, and for good reason. The database should always provide access to the most up-to-date copy of the data. Strong consistency is the right way to design a database. Enterprise Management and Integrations. Finally, databases are just one piece of the puzzle, and they need to fit into the enterprise IT stack. Organizations need a database that can be secured, monitored, automated, and integrated with their existing IT infrastructure and staff, such as operations teams, DBAs, and data analysts.
- But of course the world has changed a lot since the 1980s when the relational database first came about. First of all, data and risk are significantly up. In terms of data 90% data created in last 2 years - think about that for a moment, of all the data ever created, 90% of it was in the last 2 years 80% of enterprise data is unstructured - this is data that doesn’t fit into the neat tables of a relational database Unstructured data is growing 2X rate of structured data At the same time, risks of running a database are higher than ever before. You are now faced with: More users - Apps have shifted from small internal departmental system with thousands of users to large external audiences with millions of users No downtime - It’s no longer the case that apps only need to be available during standard business hours. They must be up 24/7. All across the globe - your users are everywhere, and they are always connected On the other hand, time and costs are way down. There’s less time to build apps than ever before. You’re being asked to: Ship apps in a few months not years - Development methods have shifted from a waterfall process to an iterative process that ships new functionality in weeks and in some cases multiple times per day at companies like Facebook and Amazon. And costs are way down too. Companies want to: Pay for value over time - Companies have shifted to open-source business and SaaS models that allow them to pay for value over time Use cloud and commodity resources - to reduce the time to provision their infrastructure, and to lower their total cost of ownership
- Because the relational database was not designed for modern applications, starting about 10 years ago a number of companies began to build their own databases that are fundamentally different. The market calls these NoSQL. NoSQL databases were designed for this new world… Flexibility. All of them have some kind of flexible data model to allow for faster iteration and to accommodate the data we see dominating modern applications. While they all have different approaches, what they have in common is they want to be more flexible. Scalability + Performance. Similarly, they were all built with a focus on scalability, so they all include some form of sharding or partitioning. And they're all designed to deliver great performance. Some are better at reads, some are better at writes, but more or less they all strive to have better performance than a relational database. Always-On Global Deployments. Lastly, NoSQL databases are designed for highly available systems that provide a consistent, high quality experience for users all over the world. They are designed to run on many computers, and they include replication to automatically synchronize the data across servers, racks, and data centers. However, when you take a closer look at these NoSQL systems, it turns out they have thrown out the baby with the bathwater. They have sacrificed the core database capabilities you’ve come to expect and rely on in order to build fully functional apps, like rich querying and secondary indexes, strong consistency, and enterprise management.
- MongoDB was built to address the way the world has changed while preserving the core database capabilities required to build modern applications. Our vision is to leverage the work that Oracle and others have done over the last 40 years to make relational databases what they are today, and to take the reins from here. We pick up where they left off, incorporating the work that internet pioneers like Google and Amazon did to address the requirements of modern applications. MongoDB is the only database that harnesses the innovations of NoSQL and maintains the foundation of relational databases – and we call this our Nexus Architecture.
- Think redis, memcached or Couchbase.
- Column stores you know and love, HP Vertica, Cassandra.
- Rich queries, text search, geospatial, aggregation, mapreduce are types of things you can build based on the richness of the query model.