MongoDB - Back to Basics 2017 - Introduzione a NoSQL
•Download as PPTX, PDF•
0 likes•203 views
Questa è la prima puntata della serie Back to Basics edizione 2017. Vedremo un'introduzione ai NoSQL: che cosa sono e come si differenziano tra di loro.
Recommended
Recommended
More Related Content
Similar to MongoDB - Back to Basics 2017 - Introduzione a NoSQL
Similar to MongoDB - Back to Basics 2017 - Introduzione a NoSQL (20)
MongoDB - Back to Basics 2017 - Introduzione a NoSQL
- 2. Back to Basics 2017 : Webinar 1 Introduzione a NoSQL Massimo Brignoli Principal Solutions Architect MongoDB @massimobrignoli V1.1
- 3. Benvenuti!
- 4. 4 Agenda del Corso Date Time Webinar 06 Giugno 2017 11:00 Introduzione ai NoSQL 13 Giugno 2017 11:00 La Vostra Prima Applicazione 20 Giugno 2017 11:00 Introduzione ai Replica Set 27 Giugno 2017 11:00 Introduzione allo Sharding
- 5. 5 Agenda di Oggi • Perché NoSQL • I diversi tipi di database NoSQL • Overview dettagliata di MongoDB • Durabilità dei dati in MongoDB – Replica Sets • Scalabilità in MongoDB – Sharding • Q&A
- 6. 6 Relazionali Linguaggio di Query espressivo & Indici Secondari Consistenza Forte Gestione e Integrazioni Enterprise
- 7. 7 Il Mondo è Cambiato Dati Rischi Tempo Costi
- 8. 8 NoSQL Scalabilità e Performance Always On, Installazioni Globali FlessibilitàExpressive Query Language & Secondary Indexes Strong Consistency Enterprise Management & Integrations
- 9. 9 Architettura Nexus Scalabilità e Performance Always On, Installazioni Globali FlessibilitàLinguaggio di Query espressivo & Indici Secondari Consistenza Forte Gestione e Integrazioni Enterprise
- 10. 10 Tipi di Database NoSQL • Key/Value Store • Column Store • Graph Store • Multi-model Databases • Document Store
- 11. 11 Key Value Stores • Array associativo • Lookup per chiave singola • Lookup estremamente veloce • Non così rapido per le “reverse lookups” Key Value 12345 4567.3456787 12346 { addr1 : “The Grange”, addr2: “Dublin” } 12347 “top secret password” 12358 “Shopping basket value : 24560” 12787 12345
- 12. 12 Ripasso: Row Stores (RDBMS) • Memorizza i allineati per righe (RDBMS tradizionali, e.g MySQL) • Le letture ritornano sempre una riga completa • Le letture che richiedono 1 o 2 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
- 13. 13 Come lo fa 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
- 14. 14 Perché è cosi attrattivo? • Una serie di seek consecutive può restituire una colonna in modo efficiente • Comprimere dati similie è super efficiente • Le letture, quindi, possono leggere più dati dai dischi in un singolo passaggio • Come allineo le mie righe? In ordine o aggiungendo un row ID • Se c’è bisogno di un piccolo numero di colonne non è necessario leggere le righe per intero • Ma: – Aggiornare e cancellare le righe è molto costoso • Append only è preferito. • Meglio per OLAP che per OLTP
- 15. 15 Graph Store • Memorizzano grafi (archi e vertici) • Esempio: social networks • Disegnato per permettere attraversamenti efficienti • Ottimizzato per rappresentare connessioni • Può essere implementato come un key-value store con l’abilità di memorizzare link • MongoDB 3.4 supporta query sui grafi
- 16. 16 Database Multi-Model • Combinano i modelli di multipli storage • Spesso sono Gtrafi più “qualcos’altro” • Cerca di sistemare il problema del “polyglot persistence” tipico dell’installazione di molteplici database indipendenti • E’ “The new new thing” nel mondo NoSQL • MongoDB è un document store multi-modale – Grafi – Geo-Spaziale – B-tree – Full Text
- 17. 17 Document Store • Non server per PDF, Microsoft Word oppure HTML • I Documenti sono strutture nidificate create usando Javascript Object Notation (JSON) { name : “Massimo Brignoli”, title : “Principal Solutions Architect”, Address : { address1 : “Via Paleocapa 7”, address2 : “presso Regus”, zipcode : “20121”, } expertise: [ “MongoDB”, “Python”, “Javascript” ], employee_number : 334, location : [ 53.34, -6.26 ] }
- 18. 18 I Documenti di MongoDB Sono Tipizzati { name : “Massimo Brignoli”, title : “Principal Solutions Architect”, Address : { address1 : “Via Paleocapa 7”, address2 : “c/o Regus”, zipcode: “20121”, } expertise: [ “MongoDB”, “Python”, “Javascript” ], employee_number : 320, location : [ 53.34, -6.26 ] } Stringhe Documenti Nidificati Array Intero Coordinate Geografiche
- 19. 19 MongoDB Capisce i Documenti JSON • Fin dalla prima versione è sempre stato un database JSON nativo • Capisce e può indicizzare le sotto strutture • Memorizza i JSON in un formato binario chiamato BSON (www.bson-spec.org) • Efficiente per encoding edecoding per la trasmissione di rete • MongoDB può creare indici su qualsiasi campo del documento • (Questi punti verranno approfonditi durante il corso)
- 20. 20 Perché I Documenti? • Schema dinamico • Eliminazione del Layer di mapping Object/Relational • Denormalizzazione implicita dei dati per maggiori performance
- 21. 21 Perché I Documenti? • Schema dinamico • Eliminazione del Layer di mapping Object/Relational • Denormalizzazione implicita dei dati per maggiori performance
- 23. 23 Operatori della Pipeline • $match Filtra i documenti • $project Formatta i documenti • $group Raggruppa i documenti • $out Crea una collezione • $sort Ordina i documenti • $limit/$skip Pagina i documenti • $lookup Join tra 2 collezioni • $unwind Espande un array
- 24. 24 Partite a Razzo con Compass e Atlas Compass Atlas
- 25. 25 Prossimo Webinar – La Vostra Prima Applicazione • 13 Giugno 2017 – ore 11:00 • Impara come costruire la tua prima applicazione MongoDB – Creare database e collection – Uno sguardo alle query – Costruisre gli indici – Iniziare a capire le performance • Registratevi su https://www.mongodb.com/webinar/back-to- basics-webinar-series • Send feedback to back-to-basics@mongodb.com
- 26. 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.
- No copies of data for multi-modal