1 00:00:03,710 --> 00:00:08,700 Permítanme darles una visión general rápida de MongoDB. 2 00:00:08,700 --> 00:00:10,875 ¿ Por qué MongoDB es interesante? 3 00:00:10,875 --> 00:00:13,165 ¿ Cómo es útil para nuestra aplicación? 4 00:00:13,165 --> 00:00:16,290 ¿ Y cuáles son algunas de las características más destacadas de MongoDB en 5 00:00:16,290 --> 00:00:19,845 contraste con las bases de datos SQL tradicionales? 6 00:00:19,845 --> 00:00:23,190 Así que esto no será todo un tratado o bases de datos. 7 00:00:23,190 --> 00:00:25,890 Supongo que tiene suficiente conocimiento de las bases de datos. 8 00:00:25,890 --> 00:00:31,050 Así que lo que yo presentaría lo que MongoDB sería fácil para usted seguir. Por 9 00:00:31,050 --> 00:00:34,695 su conocimiento previo de las bases de datos, 10 00:00:34,695 --> 00:00:40,235 supongo que ya entiende que las bases de datos se utilizan para almacenar datos estructurados 11 00:00:40,235 --> 00:00:42,515 y también le permiten realizar 12 00:00:42,515 --> 00:00:46,455 diversas operaciones de los datos, incluyendo consultar los datos, 13 00:00:46,455 --> 00:00:48,740 insertar registros en la base de datos, 14 00:00:48,740 --> 00:00:53,870 actualizar un registro existente en la base de datos o eliminar un registro de la base de datos. 15 00:00:53,870 --> 00:00:58,795 Las operaciones típicas de crud que se admiten en las bases de datos. El 16 00:00:58,795 --> 00:01:02,870 lenguaje de consulta estructurado o bases de datos basadas en SQL han sido 17 00:01:02,870 --> 00:01:07,330 muy populares durante mucho tiempo como medio de almacenar datos. 18 00:01:07,330 --> 00:01:13,760 MySQL es un ejemplo de base de datos basada en SQL. 19 00:01:13,760 --> 00:01:16,850 Han sido muy eficaces para almacenar 20 00:01:16,850 --> 00:01:20,230 datos y luego abordar muchas de las necesidades de las aplicaciones. 21 00:01:20,230 --> 00:01:27,650 De hecho, muchos sitios web ya usan bases de datos SQL como back-end para almacenar datos dado 22 00:01:27,650 --> 00:01:30,630 que por qué no hay bases de datos SQL 23 00:01:30,630 --> 00:01:35,610 importantes con nuevos tipos de aplicaciones que se están conectando. 24 00:01:35,610 --> 00:01:37,850 Hay una creciente demanda de 25 00:01:37,850 --> 00:01:43,170 nuevas características que no todas las bases de datos basadas en SQL pueden abordar. 26 00:01:43,170 --> 00:01:46,400 Entonces, aquí es donde la base de datos basada en NoSQL no solo la 27 00:01:46,400 --> 00:01:51,485 base de datos basada en SQL está ganando mucha concesión, 28 00:01:51,485 --> 00:01:54,720 MongoDB es un ejemplo de eso. 29 00:01:54,720 --> 00:01:58,745 Por lo tanto, las bases de datos NoSQL están diseñadas para 30 00:01:58,745 --> 00:02:03,305 abordar algunas de las deficiencias de las bases de datos basadas en SQL. 31 00:02:03,305 --> 00:02:08,935 Las bases de datos NoSQL se pueden clasificar en cuatro categorías diferentes. 32 00:02:08,935 --> 00:02:13,315 Tenemos bases de datos basadas en documentos como MongoDB, 33 00:02:13,315 --> 00:02:17,820 tenemos las bases de datos basadas en valores clave más simples como Redis, 34 00:02:17,820 --> 00:02:24,710 bases de datos basadas en la familia de columnas como Cassandra y luego las bases de datos de gráficos más nuevas como 35 00:02:24,710 --> 00:02:32,210 Neo4J y de hecho hay más ahora en el mercado que estos ejemplos que he dado. 36 00:02:32,210 --> 00:02:34,370 Pero, por supuesto, en este curso, 37 00:02:34,370 --> 00:02:40,050 nos concentraremos principalmente en bases de datos basadas en documentos, MongoDB en particular. 38 00:02:40,050 --> 00:02:44,855 Así que voy a revisar más sobre MongoDB en el resto de esta conferencia. 39 00:02:44,855 --> 00:02:48,095 Las bases de datos de documentos, como su nombre lo indica, 40 00:02:48,095 --> 00:02:50,200 se construyen alrededor de los documentos. 41 00:02:50,200 --> 00:02:56,530 Un documento es una unidad autónoma de información y puede estar en muchos formatos diferentes, 42 00:02:56,530 --> 00:03:03,425 siendo JSON uno de los formatos más populares para almacenar documentos en una base de datos de documentos. 43 00:03:03,425 --> 00:03:07,535 Como ejemplo, aquí se muestra un documento JSON y 44 00:03:07,535 --> 00:03:12,215 esto sería algo que se otorga en una base de datos de documentos típica. 45 00:03:12,215 --> 00:03:15,730 Los propios documentos se pueden organizar en colecciones. 46 00:03:15,730 --> 00:03:20,830 Por lo tanto, una colección es un grupo de documentos y, a su vez, 47 00:03:20,830 --> 00:03:26,205 la base de datos en sí puede considerarse como un conjunto de colecciones. 48 00:03:26,205 --> 00:03:31,970 Así que estos términos, «Colecciones de documentos» y «La base de datos» se producirán 49 00:03:31,970 --> 00:03:39,290 con frecuencia cuando discutamos sobre bases de datos de documentos y MongoDB en particular. 50 00:03:39,290 --> 00:03:42,910 ¿ Por qué las bases de datos NoSQL son de interés para nosotros? 51 00:03:42,910 --> 00:03:45,890 En particular, la escalabilidad es una de 52 00:03:45,890 --> 00:03:49,560 las razones por las que las bases de datos NoSQL han brillado muy bien. 53 00:03:49,560 --> 00:03:52,015 Ahora, en términos de escalabilidad, 54 00:03:52,015 --> 00:03:53,630 cuando nos fijamos en los dos requisitos: 55 00:03:53,630 --> 00:03:56,990 disponibilidad y consistencia de las bases de datos, normalmente, 56 00:03:56,990 --> 00:04:02,390 las bases de datos SQL encuentran muy difícil cumplir ambos requisitos simultáneamente. 57 00:04:02,390 --> 00:04:05,239 Por lo tanto, existe una compensación entre disponibilidad y consistencia. 58 00:04:05,239 --> 00:04:08,690 Así que aquí es donde las bases de datos NoSQL han tenido mucho 59 00:04:08,690 --> 00:04:12,175 más éxito en el cumplimiento de ambos requisitos. 60 00:04:12,175 --> 00:04:14,705 Aquí es donde 61 00:04:14,705 --> 00:04:17,465 también entra en vigor el tercer aspecto destacado aquí, la tolerancia de partición. 62 00:04:17,465 --> 00:04:23,660 Ahora particionar una base de datos SQL y luego distribuirla no es tan sencillo. 63 00:04:23,660 --> 00:04:29,239 Mientras que una base de datos NoSQL es mucho más susceptible de 64 00:04:29,239 --> 00:04:34,755 ser subdividida y luego distribuida a través de varios servidores. 65 00:04:34,755 --> 00:04:40,990 El segundo aspecto de por qué las bases de datos NoSQL han sido populares es la facilidad de implementación. 66 00:04:40,990 --> 00:04:43,165 Cuando utiliza una base de datos SQL, 67 00:04:43,165 --> 00:04:48,200 existe la necesidad de hacer coincidir los registros de su base de datos SQL con 68 00:04:48,200 --> 00:04:53,410 objetos en su idioma nativo como Java o Javascript, etc. 69 00:04:53,410 --> 00:04:56,810 Por lo tanto, existe una necesidad de mapeo relacional de objetos y 70 00:04:56,810 --> 00:05:00,920 aquí es donde una puerta de enlace intermedia necesita completar este requisito. 71 00:05:00,920 --> 00:05:07,950 Con una base de datos NoSQL como una base de datos basada en documentos que almacena datos en forma de JSON, 72 00:05:07,950 --> 00:05:12,200 el mapeo se vuelve bastante sencillo y esa es una de las razones por las que las 73 00:05:12,200 --> 00:05:17,900 bases de datos NoSQL han sido muy populares en el área de desarrollo web. 74 00:05:17,900 --> 00:05:20,680 Viniendo a MongoDB en particular, 75 00:05:20,680 --> 00:05:23,820 MongoDB es una base de datos de documentos. 76 00:05:23,820 --> 00:05:27,150 El servidor en sí puede admitir varias bases de datos. 77 00:05:27,150 --> 00:05:31,790 Una base de datos en particular es un conjunto de colecciones 78 00:05:31,790 --> 00:05:36,620 y la colección en sí, como hemos discutido anteriormente, es un conjunto de documentos. 79 00:05:36,620 --> 00:05:41,705 Así que el documento se convierte en la unidad de información en el caso de MongoDB. 80 00:05:41,705 --> 00:05:46,825 El documento en MongoDB no es más que un documento JSON. 81 00:05:46,825 --> 00:05:53,470 De hecho, MongoDB almacena el documento en una forma más compacta llamada como formato BSON. 82 00:05:53,470 --> 00:05:56,495 Hablaremos de eso en la siguiente diapositiva. 83 00:05:56,495 --> 00:06:00,175 Mientras que MongoDB es una base de datos basada en documentos, 84 00:06:00,175 --> 00:06:04,160 almacena los documentos JSON en una forma compacta 85 00:06:04,160 --> 00:06:09,125 llamada como el formato BSON o el formato JSON binario. 86 00:06:09,125 --> 00:06:12,920 Ahora esto admite prefijo de longitud en cada valor para 87 00:06:12,920 --> 00:06:16,870 que saltar sobre un campo sea mucho más fácil. 88 00:06:16,870 --> 00:06:23,365 Como puede ver, MongoDB admite características adicionales que una simple base de datos de documentos. 89 00:06:23,365 --> 00:06:27,835 También se almacena la información sobre el tipo de un valor de campo. 90 00:06:27,835 --> 00:06:31,280 Y además, dentro del documento JSON, 91 00:06:31,280 --> 00:06:35,405 se almacenan tipos primitivos adicionales que son útiles 92 00:06:35,405 --> 00:06:39,860 cuando se realizan operaciones en la base de datos. 93 00:06:39,860 --> 00:06:43,190 Cosas como el formato de fecha UTC, 94 00:06:43,190 --> 00:06:48,920 también admite binarios sin procesar y también usa un formato de ID de objeto 95 00:06:48,920 --> 00:06:54,790 para almacenar el ID de cada documento en la base de datos si lo desea. 96 00:06:54,790 --> 00:06:58,745 Hablemos de eso con un poco más de detalle en la siguiente diapositiva. 97 00:06:58,745 --> 00:07:02,330 Hablemos sobre el ID del objeto MongoDB. 98 00:07:02,330 --> 00:07:07,000 Cada documento en la base de datos MongoDB debe tener un campo ID, 99 00:07:07,000 --> 00:07:08,985 un campo de ID de subrayado, 100 00:07:08,985 --> 00:07:14,055 que actúa como la clave principal del documento. 101 00:07:14,055 --> 00:07:17,465 Y este campo es único para cada documento. 102 00:07:17,465 --> 00:07:20,810 El campo ID en sí se puede usar en 103 00:07:20,810 --> 00:07:25,955 muchos formatos y un formato particular que MongoDB 104 00:07:25,955 --> 00:07:30,020 asigna automáticamente en caso de que no elija usar su propio campo de ID 105 00:07:30,020 --> 00:07:35,350 es el ID de objeto que se crea de forma predeterminada por MongoDB. 106 00:07:35,350 --> 00:07:37,550 Por lo tanto, el ID del objeto en sí es 107 00:07:37,550 --> 00:07:43,660 una pieza estructurada de información, pero se almacena como el ID del documento. 108 00:07:43,660 --> 00:07:47,825 Como ejemplo, el campo ID que 109 00:07:47,825 --> 00:07:52,390 Mongo asigna automáticamente en caso de que no especifique un campo ID 110 00:07:52,390 --> 00:07:55,960 contiene el ID del objeto en forma de una cadena larga. 111 00:07:55,960 --> 00:08:00,605 Ahora esta cadena tiene un formato específico que 112 00:08:00,605 --> 00:08:06,530 le permite almacenar una cantidad de información dentro del ID del objeto. 113 00:08:06,530 --> 00:08:11,975 Veamos la estructura del ID del objeto en la siguiente diapositiva. 114 00:08:11,975 --> 00:08:16,325 Como mencioné, el campo ID de objeto en sí es 115 00:08:16,325 --> 00:08:22,635 un campo de 12 bytes que almacena información en un formato específico. 116 00:08:22,635 --> 00:08:26,445 Los primeros cuatro bytes incluyen una marca de tiempo, 117 00:08:26,445 --> 00:08:31,760 la marca de tiempo Unix típica en la resolución de un segundo. 118 00:08:31,760 --> 00:08:34,340 Así que esto se cuenta en los primeros cuatro bytes. 119 00:08:34,340 --> 00:08:37,580 Luego, los siguientes tres bytes hacia el ID de 120 00:08:37,580 --> 00:08:40,490 la máquina, la máquina en la que se está ejecutando 121 00:08:40,490 --> 00:08:43,910 el servidor Mongo y los siguientes dos bytes es el ID del proceso, 122 00:08:43,910 --> 00:08:47,000 el proceso específico de Mongo que ha creado 123 00:08:47,000 --> 00:08:50,674 este documento y luego el último campo es un incremento. 124 00:08:50,674 --> 00:08:52,490 Ahora, como usted entiende, 125 00:08:52,490 --> 00:08:56,390 el campo de marca de tiempo en sí está a la resolución de un segundo. 126 00:08:56,390 --> 00:09:00,110 Por lo tanto, si tiene varios documentos que se almacenan en el mismo segundo, 127 00:09:00,110 --> 00:09:03,735 entonces el campo de incremento distinguirá entre los documentos. 128 00:09:03,735 --> 00:09:06,500 El campo de incremento es un campo auto-incrementante. 129 00:09:06,500 --> 00:09:11,750 Por lo tanto, cada nuevo documento creado en un segundo obtendrá un nuevo valor de incremento. 130 00:09:11,750 --> 00:09:14,150 Por lo tanto, combinado con estos dos, 131 00:09:14,150 --> 00:09:16,655 puede distinguir fácilmente entre 132 00:09:16,655 --> 00:09:21,550 diferentes documentos que se almacenan dentro de su base de datos de documentos. 133 00:09:21,550 --> 00:09:28,500 Por lo tanto, esto le permite dar claramente un ID único a cada documento. 134 00:09:28,500 --> 00:09:30,960 No solo eso, dado un ID, 135 00:09:30,960 --> 00:09:34,050 puede recuperar fácilmente información de este ID. 136 00:09:34,050 --> 00:09:37,460 Entonces, por ejemplo, puede obtener el ObjectID y luego llamar 137 00:09:37,460 --> 00:09:40,880 al método GetTimestamp del ID del objeto y 138 00:09:40,880 --> 00:09:44,655 esto devolverá la marca de tiempo en el formato de fecha ISO. 139 00:09:44,655 --> 00:09:49,595 Esto le permitirá identificar cuándo se ha creado este documento. 140 00:09:49,595 --> 00:09:52,750 Con esta rápida comprensión de MongoDB, 141 00:09:52,750 --> 00:09:58,700 vamos a continuar con el ejercicio donde primero instalaremos MongoDB en nuestro ordenador 142 00:09:58,700 --> 00:10:04,970 y luego interactuaremos con la base de datos MongoDB usando la ondulación Mongo, 143 00:10:04,970 --> 00:10:09,365 el bucle de impresión de evaluación de lectura que Mongo admite. 144 00:10:09,365 --> 00:10:12,695 Ahora a partir de entonces, veremos cómo podemos acceder 145 00:10:12,695 --> 00:10:19,830 al servidor Mongo desde nuestra aplicación de nodo en la siguiente lección.