1 00:00:03,710 --> 00:00:08,700 Lascia che ti dia una rapida panoramica di MongoDB. 2 00:00:08,700 --> 00:00:10,875 Perché MongoDB è interessante? 3 00:00:10,875 --> 00:00:13,165 Come è utile per la nostra applicazione? 4 00:00:13,165 --> 00:00:16,290 E quali sono alcune delle caratteristiche salienti di MongoDB in 5 00:00:16,290 --> 00:00:19,845 contrasto con i tradizionali database SQL? 6 00:00:19,845 --> 00:00:23,190 Quindi questo non sarà un intero trattato o banche dati. 7 00:00:23,190 --> 00:00:25,890 Presumo che abbiate una conoscenza sufficiente delle banche dati. 8 00:00:25,890 --> 00:00:31,050 Quindi cosa introdurrei ciò che MongoDB sarebbe facile da seguire per te. 9 00:00:31,050 --> 00:00:34,695 Dalla tua conoscenza preliminare dei database, 10 00:00:34,695 --> 00:00:40,235 suppongo che tu abbia già capito che i database vengono utilizzati per memorizzare dati strutturati 11 00:00:40,235 --> 00:00:42,515 e consentono anche di eseguire 12 00:00:42,515 --> 00:00:46,455 varie operazioni dei dati, tra cui interrogare i dati, 13 00:00:46,455 --> 00:00:48,740 inserire record nel database, 14 00:00:48,740 --> 00:00:53,870 aggiornare un record esistente nel database o l'eliminazione di un record dal database. 15 00:00:53,870 --> 00:00:58,795 Le tipiche operazioni crud supportate nei database. 16 00:00:58,795 --> 00:01:02,870 Structured Query Language o database basati su SQL sono stati 17 00:01:02,870 --> 00:01:07,330 molto popolari per molto tempo come mezzo di memorizzazione dei dati. 18 00:01:07,330 --> 00:01:13,760 MySQL è un esempio di database basato su SQL. 19 00:01:13,760 --> 00:01:16,850 Sono stati molto efficaci nella memorizzazione 20 00:01:16,850 --> 00:01:20,230 dei dati e quindi nell'affrontare molte delle esigenze delle applicazioni. 21 00:01:20,230 --> 00:01:27,650 Infatti, molti siti Web utilizzano già database SQL come back-end per la memorizzazione dei dati dato 22 00:01:27,650 --> 00:01:30,630 che il motivo per cui non è 23 00:01:30,630 --> 00:01:35,610 importante database SQL con nuovi tipi di applicazioni che sono in arrivo online. 24 00:01:35,610 --> 00:01:37,850 C' è una crescente domanda di 25 00:01:37,850 --> 00:01:43,170 nuove funzionalità che non tutti i database basati su SQL possono affrontare. 26 00:01:43,170 --> 00:01:46,400 Quindi questo è dove il database basato su NoSQL non solo 27 00:01:46,400 --> 00:01:51,485 i database basati su SQL stanno guadagnando molte sovvenzioni, 28 00:01:51,485 --> 00:01:54,720 MongoDB ne è un esempio. 29 00:01:54,720 --> 00:01:58,745 Quindi i database NoSQL sono progettati per 30 00:01:58,745 --> 00:02:03,305 affrontare alcune delle carenze dei database basati su SQL. 31 00:02:03,305 --> 00:02:08,935 I database NoSQL stessi possono essere classificati in quattro diverse categorie. 32 00:02:08,935 --> 00:02:13,315 Abbiamo database basati su documenti come MongoDB, 33 00:02:13,315 --> 00:02:17,820 abbiamo i database basati su valori chiave più semplici come Redis, 34 00:02:17,820 --> 00:02:24,710 database basati su colonne come Cassandra e quindi i database grafici più recenti come 35 00:02:24,710 --> 00:02:32,210 Neo4J e in effetti ci sono più ora sul mercato di questi esempi che ho dato. 36 00:02:32,210 --> 00:02:34,370 Ma, naturalmente, in questo corso, 37 00:02:34,370 --> 00:02:40,050 ci concentreremo principalmente su database basati su documenti, MongoDB in particolare. 38 00:02:40,050 --> 00:02:44,855 Quindi esaminerò di più su MongoDB nel resto di questa lezione. 39 00:02:44,855 --> 00:02:48,095 I database dei documenti, come suggerisce il nome, 40 00:02:48,095 --> 00:02:50,200 sono costruiti attorno ai documenti. 41 00:02:50,200 --> 00:02:56,530 Un documento è un'unità di informazioni autonoma e può essere in molti formati diversi, 42 00:02:56,530 --> 00:03:03,425 JSON è uno dei formati più popolari per la memorizzazione di documenti in un database di documenti. 43 00:03:03,425 --> 00:03:07,535 Ad esempio, un documento JSON viene mostrato qui e 44 00:03:07,535 --> 00:03:12,215 questo sarebbe qualcosa che vengono conferiti in un database di documenti tipico. 45 00:03:12,215 --> 00:03:15,730 I documenti stessi possono essere organizzati in collezioni. 46 00:03:15,730 --> 00:03:20,830 Quindi una raccolta è un gruppo di documenti e, a sua volta, 47 00:03:20,830 --> 00:03:26,205 il database stesso può essere considerato come un insieme di collezioni. 48 00:03:26,205 --> 00:03:31,970 Quindi questi termini, «Raccolte di documenti» e «Il database» si verificheranno 49 00:03:31,970 --> 00:03:39,290 frequentemente quando discutiamo di database di documenti e MongoDB in particolare. 50 00:03:39,290 --> 00:03:42,910 Perché i database NoSQL ci interessano? 51 00:03:42,910 --> 00:03:45,890 In particolare, la scalabilità è uno 52 00:03:45,890 --> 00:03:49,560 dei motivi per cui i database NoSQL hanno brillato molto bene. 53 00:03:49,560 --> 00:03:52,015 Ora, in termini di scalabilità, 54 00:03:52,015 --> 00:03:53,630 quando esaminiamo i due requisiti; 55 00:03:53,630 --> 00:03:56,990 disponibilità e coerenza dei database, in genere, 56 00:03:56,990 --> 00:04:02,390 i database SQL trovano molto difficile soddisfare entrambi i requisiti contemporaneamente. 57 00:04:02,390 --> 00:04:05,239 Quindi c'è un compromesso tra disponibilità e coerenza. 58 00:04:05,239 --> 00:04:08,690 Quindi questo è dove i database NoSQL hanno avuto molto 59 00:04:08,690 --> 00:04:12,175 più successo nel soddisfare entrambi i requisiti. 60 00:04:12,175 --> 00:04:14,705 Questo è dove 61 00:04:14,705 --> 00:04:17,465 entra in vigore anche il terzo aspetto evidenziato qui, la tolleranza alle partizioni. 62 00:04:17,465 --> 00:04:23,660 Ora partizionare un database SQL e poi distribuirlo non è così semplice. 63 00:04:23,660 --> 00:04:29,239 Mentre un database NoSQL è molto più suscettibile 64 00:04:29,239 --> 00:04:34,755 di essere suddiviso e quindi distribuito su più server. 65 00:04:34,755 --> 00:04:40,990 Il secondo aspetto del motivo per cui i database NoSQL sono stati popolari è la facilità di distribuzione. 66 00:04:40,990 --> 00:04:43,165 Quando si utilizza un database SQL, 67 00:04:43,165 --> 00:04:48,200 è necessario abbinare i record nel database SQL 68 00:04:48,200 --> 00:04:53,410 agli oggetti nella lingua nativa come Java o Javascript e così via. 69 00:04:53,410 --> 00:04:56,810 Quindi c'è la necessità di mappatura relazionale degli oggetti e questo è 70 00:04:56,810 --> 00:05:00,920 dove un gateway intermedio deve riempire questo requisito. 71 00:05:00,920 --> 00:05:07,950 Con un database NoSQL come un database basato su documenti che memorizza i dati sotto forma di JSON, 72 00:05:07,950 --> 00:05:12,200 la mappatura diventa abbastanza semplice e questo è uno dei motivi per cui 73 00:05:12,200 --> 00:05:17,900 i database NoSQL sono stati molto popolari nell'area di sviluppo web. 74 00:05:17,900 --> 00:05:20,680 Venendo su MongoDB in particolare, 75 00:05:20,680 --> 00:05:23,820 MongoDB è un database di documenti. 76 00:05:23,820 --> 00:05:27,150 Il server stesso può supportare più database. 77 00:05:27,150 --> 00:05:31,790 Un database in particolare è un insieme di collezioni 78 00:05:31,790 --> 00:05:36,620 e la raccolta stessa, come abbiamo discusso in precedenza, è un insieme di documenti. 79 00:05:36,620 --> 00:05:41,705 Quindi il documento diventa l'unità di informazione in caso di MongoDB. 80 00:05:41,705 --> 00:05:46,825 Il documento in MongoDB non è altro che un documento JSON. 81 00:05:46,825 --> 00:05:53,470 Infatti, MongoDB memorizza il documento in una forma più compatta chiamata come formato BSON. 82 00:05:53,470 --> 00:05:56,495 Ne parleremo nella prossima diapositiva. 83 00:05:56,495 --> 00:06:00,175 Mentre MongoDB è un database basato su documenti, 84 00:06:00,175 --> 00:06:04,160 memorizza i documenti JSON in una forma compatta 85 00:06:04,160 --> 00:06:09,125 chiamata come il formato BSON o il formato JSON binario. 86 00:06:09,125 --> 00:06:12,920 Ora questo supporta il prefisso di lunghezza su ogni valore in modo 87 00:06:12,920 --> 00:06:16,870 che saltare su un campo diventi molto più facile. 88 00:06:16,870 --> 00:06:23,365 Quindi, come vedi, MongoDB supporta funzionalità aggiuntive rispetto a un semplice database di documenti. 89 00:06:23,365 --> 00:06:27,835 Vengono memorizzate anche le informazioni sul tipo di valore di un campo. 90 00:06:27,835 --> 00:06:31,280 Inoltre, all'interno del documento JSON, 91 00:06:31,280 --> 00:06:35,405 vengono memorizzati tipi primitivi aggiuntivi che sono utili 92 00:06:35,405 --> 00:06:39,860 quando si eseguono operazioni sul database. 93 00:06:39,860 --> 00:06:43,190 Cose come il formato di data UTC, 94 00:06:43,190 --> 00:06:48,920 supporta anche binario raw e utilizza anche un formato ID oggetto 95 00:06:48,920 --> 00:06:54,790 per memorizzare l'ID di ogni documento nel database, se si sceglie di farlo. 96 00:06:54,790 --> 00:06:58,745 Parliamo di questo in modo un po 'più dettagliato nella diapositiva successiva. 97 00:06:58,745 --> 00:07:02,330 Parliamo dell'ID oggetto MongoDB. 98 00:07:02,330 --> 00:07:07,000 Ogni documento nel database MongoDB deve avere un campo ID, 99 00:07:07,000 --> 00:07:08,985 un campo ID di sottolineatura, 100 00:07:08,985 --> 00:07:14,055 che funge da chiave primaria per il documento. 101 00:07:14,055 --> 00:07:17,465 E questo campo è unico per ogni documento. 102 00:07:17,465 --> 00:07:20,810 Il campo ID stesso può essere utilizzato in 103 00:07:20,810 --> 00:07:25,955 molti formati e un particolare formato che MongoDB 104 00:07:25,955 --> 00:07:30,020 assegna automaticamente nel caso in cui non si scelga di utilizzare il proprio campo ID 105 00:07:30,020 --> 00:07:35,350 è l'ID oggetto creato per impostazione predefinita da MongoDB. 106 00:07:35,350 --> 00:07:37,550 Quindi l'ID dell'oggetto stesso è 107 00:07:37,550 --> 00:07:43,660 un pezzo strutturato di informazioni, ma viene memorizzato come ID del documento. 108 00:07:43,660 --> 00:07:47,825 Ad esempio, il campo ID 109 00:07:47,825 --> 00:07:52,390 assegnato automaticamente da Mongo nel caso in cui non si specifichi un campo ID, 110 00:07:52,390 --> 00:07:55,960 contiene l'ID oggetto sotto forma di una stringa lunga. 111 00:07:55,960 --> 00:08:00,605 Ora questa stringa ha un formato specifico 112 00:08:00,605 --> 00:08:06,530 che consente di memorizzare una serie di informazioni all'interno dell'ID oggetto. 113 00:08:06,530 --> 00:08:11,975 Diamo un'occhiata alla struttura dell'ID oggetto stesso nella diapositiva successiva. 114 00:08:11,975 --> 00:08:16,325 Come ho accennato, il campo ID oggetto stesso è 115 00:08:16,325 --> 00:08:22,635 un campo di 12 byte che memorizza le informazioni in un formato specifico. 116 00:08:22,635 --> 00:08:26,445 I primi quattro byte includono un timestamp, 117 00:08:26,445 --> 00:08:31,760 il tipico timestamp Unix nella risoluzione di un secondo. 118 00:08:31,760 --> 00:08:34,340 Quindi questo è detto nei primi quattro byte. 119 00:08:34,340 --> 00:08:37,580 Quindi i tre byte successivi verso l'ID della macchina, 120 00:08:37,580 --> 00:08:40,490 il computer su cui è in esecuzione il server Mongo 121 00:08:40,490 --> 00:08:43,910 e i due byte successivi sono l'ID del processo, 122 00:08:43,910 --> 00:08:47,000 il processo Mongo specifico che ha creato 123 00:08:47,000 --> 00:08:50,674 questo documento e quindi l'ultimo campo è un incremento. 124 00:08:50,674 --> 00:08:52,490 Ora, come capisci, 125 00:08:52,490 --> 00:08:56,390 il campo timestamp stesso è alla risoluzione di un secondo. 126 00:08:56,390 --> 00:09:00,110 Quindi, se hai più documenti che sono memorizzati nello stesso secondo, 127 00:09:00,110 --> 00:09:03,735 il campo di incremento distinguerà tra i documenti. 128 00:09:03,735 --> 00:09:06,500 Essi incrementano il campo è un campo auto-incrementante. 129 00:09:06,500 --> 00:09:11,750 Quindi ogni nuovo documento creato all'interno di un secondo otterrà un nuovo valore di incremento. 130 00:09:11,750 --> 00:09:14,150 Quindi, combinato con questi due, 131 00:09:14,150 --> 00:09:16,655 è possibile distinguere facilmente tra 132 00:09:16,655 --> 00:09:21,550 diversi documenti che sono memorizzati all'interno del database dei documenti. 133 00:09:21,550 --> 00:09:28,500 Quindi questo ti permette di dare chiaramente un ID univoco a ogni documento. 134 00:09:28,500 --> 00:09:30,960 Non solo, dato un ID, 135 00:09:30,960 --> 00:09:34,050 è possibile recuperare facilmente le informazioni da questo ID. 136 00:09:34,050 --> 00:09:37,460 Quindi, ad esempio, è possibile ottenere l'ObjectID e quindi chiamare 137 00:09:37,460 --> 00:09:40,880 il metodo getTimestamp dell'ID oggetto e 138 00:09:40,880 --> 00:09:44,655 questo restituirà il timestamp nel formato data ISO. 139 00:09:44,655 --> 00:09:49,595 In questo modo ti permetterà di identificare quando questo documento è stato creato. 140 00:09:49,595 --> 00:09:52,750 Con questa rapida comprensione di MongoDB, 141 00:09:52,750 --> 00:09:58,700 passiamo all'esercizio in cui prima installeremo MongoDB sul nostro computer 142 00:09:58,700 --> 00:10:04,970 e successivamente interagiamo con il database MongoDB utilizzando l'ondulazione Mongo, 143 00:10:04,970 --> 00:10:09,365 il ciclo di stampa di lettura valutiamo che Mongo supporta. 144 00:10:09,365 --> 00:10:12,695 Ora in poi, vedremo come possiamo accedere 145 00:10:12,695 --> 00:10:19,830 al server Mongo dall'interno della nostra applicazione nodo nella prossima lezione.