WEBVTT

00:00:07.660 --> 00:00:08.780
Hola, Loles buenas tardes.

00:00:08.820 --> 00:00:10.320
¿Qué tal estás? Hola, Javi.

00:00:11.170 --> 00:00:13.059
Pues yo muy bien ¿Y tú cómo estás?

00:00:13.430 --> 00:00:14.570
Pues yo también muy bien.

00:00:14.610 --> 00:00:20.070
Primer episodio de la cuarta temporada o
podríamos decir último episodio de la temporada

00:00:20.070 --> 00:00:27.090
3 que dejamos frustrados porque yo estuve
convaleciente y tal y no pudimos hacer

00:00:27.090 --> 00:00:31.310
nuestro último episodio. Entonces empezamos
por el primer episodio, temporada cuarta

00:00:31.350 --> 00:00:34.920
y Oracle con Mongo. ¿Qué tal estás, Loles?

00:00:34.980 --> 00:00:38.900
¿Cómo lo ves el tema?
Oracle y Mongo y todo.

00:00:40.210 --> 00:00:44.070
Bueno, pues yo estoy muy bien, estoy
contenta de estar aquí contigo otra vez.

00:00:44.110 --> 00:00:48.370
Y el tema de Oracle y Mongo, pues nada,
como cuando hablábamos de Oracle y Postgre, son

00:00:48.410 --> 00:00:50.850
alternativas, son otros
motores de base de datos.

00:00:50.890 --> 00:00:55.610
A los que somos de BA y nos gusta esto,
pues nos gustan todas y las abrazamos a todas.

00:00:55.650 --> 00:01:00.230
Pero bueno, vamos a hablar un poquito
de diferencias, de similitudes.

00:01:01.030 --> 00:01:04.110
Muy bien, muy bien a ver, MongoDB.

00:01:04.410 --> 00:01:10.110
Según DB Engines, MongoDB es la primera
base de datos documental en el ranking.

00:01:10.490 --> 00:01:17.930
En el ranking de popularidad tenemos, en
el top 5, tenemos Oracle, SQL Server, SQL Postgres.

00:01:17.930 --> 00:01:23.330
Y después, las cuatro primeras son relacionales,
la primera base de datos documental

00:01:23.330 --> 00:01:28.630
es Mongo, la más popular, podríamos decir
que es la más popular ¿Tú por qué crees que

00:01:28.630 --> 00:01:30.690
es la más popular? O sea, ¿es la mejor?

00:01:30.730 --> 00:01:36.260
¿Es la más popular? Sí, hombre,
si lo dice David Engels con su

00:01:37.180 --> 00:01:42.560
ranking que es la más popular, será porque
hacen sus estadísticas y estas cosas, es verdad

00:01:42.560 --> 00:01:47.800
que se va el pobre va bajando va entre el
cuarto o quinto puesto O sea, Mongo y Pogre

00:01:47.800 --> 00:01:51.000
van repartiendo el cuarto
y el quinto puesto.

00:01:51.400 --> 00:01:52.920
Pero bueno, ahí se mantiene.

00:01:52.960 --> 00:01:58.700
Y sí, Mongo de Bell la base de datos no
SQL más conocida, más popular y que más se usa.

00:01:58.800 --> 00:02:00.920
En eso creo que estamos todos de acuerdo.

00:02:00.960 --> 00:02:07.240
Claro mira, si te parece, para lo mejor,
para introducir a todo el mundo en las bases

00:02:07.240 --> 00:02:10.600
de datos documentales y para partir un
poco de un mismo punto, hablamos de relacional

00:02:10.640 --> 00:02:18.260
documental, cuéntame un poco en qué se basa
Mongo para ser base de datos documental.

00:02:18.260 --> 00:02:21.460
Si, por ejemplo, en cualquier base de
datos puedes al final almacenar un JSON o puedes

00:02:21.500 --> 00:02:25.840
almacenar en tipos XML. ¿Qué
es lo que hace de Mongo?

00:02:25.940 --> 00:02:29.218
¿Que sea base de datos documental
diferente del relacional?

00:02:29.740 --> 00:02:32.500
Y cuéntame un poco de presentación, ¿no?

00:02:32.520 --> 00:02:34.131
¿De qué va una base de datos?

00:02:35.460 --> 00:02:41.240
Bueno, pues MongoDB es una base de datos
efectivamente basada en documentos donde no

00:02:41.240 --> 00:02:46.700
hay todo este paradigma que conocemos de
las bases de datos relacionales de tablas, relaciones,

00:02:46.840 --> 00:02:54.720
claves foráneas, todo esto en una base
de datos Mongo no existe como premisa,

00:02:54.760 --> 00:02:58.680
no es necesario, no es imprescindible y de
hecho no tenerlo también tiene sus ventajas

00:02:58.720 --> 00:03:02.400
pero MongoDB también permite, igual que
las bases de datos relacionales Oracle Oracle

00:03:02.440 --> 00:03:05.662
que comentas en este caso y
es de lo que estamos hablando.

00:03:05.940 --> 00:03:11.340
Igual que permite en un campo de una tabla
definirlo como tipo de datos JSON y guardar

00:03:11.340 --> 00:03:16.060
ahí documentos. Vale, pues la base de datos
MongoDB dentro de sus documentos también

00:03:16.060 --> 00:03:23.080
permiten establecer una estructura fija
para las tablas, unas relaciones con otras

00:03:23.080 --> 00:03:25.720
tablas que en MongoDB no se llaman
tablas, se llaman colecciones.

00:03:25.760 --> 00:03:31.860
La principal diferencia entre Oracle y
MongoDB es que las tablas se llaman colecciones

00:03:32.440 --> 00:03:39.460
Y las columnas en MongoDB se llaman campos
y no existen, en principio, restricciones

00:03:39.460 --> 00:03:41.460
de integridad ni nada de esto.

00:03:41.680 --> 00:03:47.100
¿Cuál es la ventaja? Pues que facilitan
el desarrollo ágil de las aplicaciones.

00:03:47.180 --> 00:03:52.440
A ti no te ha pasado que cuando te pidan,
oye, que para hacer una modificación en la

00:03:52.440 --> 00:03:56.480
aplicación necesitamos que nos modifiquen
las tablas y añadas columnas, pero entonces

00:03:56.520 --> 00:03:58.700
esta columna la tienes Que
quitar y se mueve a otra.

00:03:58.740 --> 00:04:03.380
Y aquí donde había una relación de uno a
muchos ahora necesito una tabla intermedia y

00:04:03.420 --> 00:04:07.360
entonces tienes que tocar tantas cosas de
estructura y mover datos de un lado para otro

00:04:07.400 --> 00:04:11.920
que esa complejidad que tienes que
resolver tú como DBA, los desarrolladores mientras

00:04:11.960 --> 00:04:13.640
tanto están esperando, ¿sí o no?

00:04:13.680 --> 00:04:19.120
¿Eso te ha pasado? Bueno, y me han pasado
cosas peores de relatos para no dormir Mira,

00:04:19.180 --> 00:04:25.140
yo tengo programadores que en vez de
hacerme yo insumiendo por ejemplo, imagínate dos

00:04:25.140 --> 00:04:30.200
tablas que tenga una foreign key que
apunta una primary key pues me cruzan las tablas

00:04:30.200 --> 00:04:34.756
uniéndome las dos foreign key, where foreign
key igual a la otra foreign key, ¿no?

00:04:35.940 --> 00:04:40.320
La complejidad de datos a nivel de modelo
también se traduce después a la complejidad

00:04:40.360 --> 00:04:45.660
de construir una query y bueno, por no
decir que estaba diciendo con Armadona el otro

00:04:45.660 --> 00:04:51.500
día que el SQL era un lenguaje más odiado
de todo el mundo amo Python, primero aprendí

00:04:51.500 --> 00:04:57.120
con Pascal, después con C C++, amo todos
los lenguajes y con SQL, Dios, cuánto lo odio

00:04:57.120 --> 00:05:00.787
porque si, toda esa complejidad
relacional pues al final la tienes

00:05:01.940 --> 00:05:04.960
MongoDB no la tiene MongoDB
no la, o sea, puedes

00:05:06.400 --> 00:05:10.140
Implementar un mecanismo para que la
tengas, aunque tampoco tiene sentido que implementes

00:05:10.180 --> 00:05:13.440
en MongoDB todas las restricciones de una
base de datos relacional porque para eso te

00:05:13.480 --> 00:05:16.860
vas a una base de datos relacional,
MongoDB lo que tiene de bueno es que puedes no tener

00:05:16.900 --> 00:05:22.560
ninguna ninguna, entonces eso es un eso
para los desarrolladores de hoy día pues las

00:05:22.560 --> 00:05:29.680
aplicaciones se adaptan constantemente a
las necesidades del mercado, del cliente necesitan

00:05:29.680 --> 00:05:34.400
actualizaciones muy rápidas entonces
necesitan una base de datos que no les limite, entonces

00:05:34.440 --> 00:05:38.840
MongoDB para eso es estupendo, porque los
desarrolladores hacen lo que quieren, que necesito

00:05:38.880 --> 00:05:43.620
campos, pues ellos a partir de ya empiezan
a meter campos, o sea empiezan a meter valores,

00:05:43.660 --> 00:05:49.780
perdón empiezan a meter valores en esos
campos y la base de datos, eso se lo traga, lo

00:05:49.780 --> 00:05:53.900
gestiona y luego haces consultas sobre
eso, lo sabes gestionar o sea, quiero decir, al

00:05:53.940 --> 00:05:59.760
final toda esa potencia sí que estarás
pensando eso es el caos, efectivamente, con MongoDB

00:05:59.760 --> 00:06:05.560
puedes estar en el extremo del caos, de
pueden meter lo que quieran, como quieran, cuando

00:06:05.560 --> 00:06:10.860
quieran que eso es muy flexible aunque
luego tiene sus inconvenientes da miedo eso, da

00:06:10.860 --> 00:06:14.960
miedo porque de repente dices, oye, ya
pero entonces los nombres de los campos lo están

00:06:15.000 --> 00:06:19.120
dando ellos efectivamente, ya pero Si a un
desarrollador le da por llamarle a un campo

00:06:19.160 --> 00:06:23.620
nombre y el de al lado dice, pues yo lo
necesito también y le voy a llamar name pues

00:06:23.660 --> 00:06:30.860
efectivamente tiene dos campos, uno llamado
nombre lo mismo pero porque ya se delega

00:06:30.860 --> 00:06:34.800
en el programador ahí es el programador
que tiene que saber el desarrollador el que tiene

00:06:34.840 --> 00:06:39.520
que guardar la integridad que antes la
base de datos se la proporcionaba por sí mismo

00:06:39.560 --> 00:06:47.820
pero bueno entre el paradigma del caos
absoluto y el paradigma de la estructura

00:06:47.820 --> 00:06:53.160
absoluta y todo rígido controlado y tal
existen muchos puntos intermedios y mongo MongoDB

00:06:53.160 --> 00:06:55.549
te permite colocarte
donde más te interese.

00:06:55.620 --> 00:06:59.220
Oye, pues para determinadas colecciones hay
una serie de campos que son obligatorios

00:06:59.260 --> 00:07:00.980
tenerlos y se tienen que llamar así.

00:07:01.020 --> 00:07:06.380
Y además aquí sí que quiero una entidad,
una relación de esta colección con esta sobre

00:07:06.380 --> 00:07:07.860
estos campos que tienen que coincidir.

00:07:07.900 --> 00:07:11.678
O aquí no quiero relaciones para
que mis consultas sean más rápidas.

00:07:11.720 --> 00:07:13.920
Toda esa flexibilidad
la proporciona MongoDB.

00:07:13.960 --> 00:07:21.520
Qué bueno, qué bueno hablábamos antes,
comentando un poco la jugada sobre Oracle

00:07:21.520 --> 00:07:29.480
versus Mongo, que Oracle ha hecho en
la nueva versión, en la nueva 23, ha

00:07:29.480 --> 00:07:36.500
hecho un acercamiento muy muy
grande a toda la parte documental de

00:07:36.500 --> 00:07:40.900
Jason, a todo esto que dices, bueno,
caótico por tener un documento que lo tenga Todo

00:07:40.940 --> 00:07:44.860
ya relacionado, quitamos la complejidad de
lo relacionado, Lo tenemos todo relacionado

00:07:44.900 --> 00:07:49.790
ya en un documento. De una
forma que ellos han llamado...

00:07:49.790 --> 00:07:55.730
Primero, que ellos en el cloud han hecho
una integración con Mongo, con una API para

00:07:55.730 --> 00:08:02.910
la que tú desde Oracle puedes ver y
consultar y acceder a un destino Mongo de forma transparente.

00:08:02.910 --> 00:08:11.810
De hecho, estaba buscando en SPU un
artículo que ha escrito, que escribió David

00:08:11.810 --> 00:08:21.670
Sanz sobre cómo crear con OCI, podéis
echar un ojo, esa interconexión

00:08:21.670 --> 00:08:26.370
de un autónomo, que está, además todo esto
está disponible en la capa de free -tire,

00:08:26.370 --> 00:08:32.190
de decir, bueno, me creo en Autonomous
Free, tengo una base de datos Mongo remota y con

00:08:32.190 --> 00:08:35.250
la API de Mongo las conecto y
las veo de forma transparente.

00:08:35.290 --> 00:08:39.690
Es decir, eso ha sido, Oracle se está
acercando mucho al tema de Mongo.

00:08:40.110 --> 00:08:47.250
Y por otro lado, en la 23, esto
se puede hacer con 19, pero en

00:08:47.250 --> 00:08:52.750
la 23 ahí tienes un componente
nuevo, que son las duality views.

00:08:53.810 --> 00:08:59.950
A mí esto me gustaría verlo funcionando y
me gustaría ver cómo se comporta con grandes

00:08:59.950 --> 00:09:06.070
volúmenes y cómo integramos, como dices
tú, el caos absoluto con el relacional más absoluto.

00:09:06.070 --> 00:09:15.990
Pero te dice Oracle que tú puedes crear
una vista que se llama Duality Views,

00:09:15.990 --> 00:09:23.410
en la que tú puedes tener un cruce de
tablas, digamos, presentado como JSON y

00:09:23.440 --> 00:09:28.560
puedes operarlo Con comandos de JSON, de
modificación de documentos y páginas, etc.

00:09:28.560 --> 00:09:36.080
Y la vista te convierte esas
modificaciones que haces sobre la visión

00:09:36.080 --> 00:09:42.860
que estás teniendo de documentos, te lo
convierte a UDATES en las tablas y al revés.

00:09:42.940 --> 00:09:50.460
Es decir, tú puedes tener un Duality View
sobre Campos JSON y poder verlos como si

00:09:50.500 --> 00:09:54.760
fuese un comando SQL desde una serie.

00:09:54.760 --> 00:10:01.780
Tú podrías acceder a hacer un
select from y filtrar en el web y

00:10:01.780 --> 00:10:04.980
filtrar como si fuese en Twitter.

00:10:05.800 --> 00:10:09.120
De forma que tú podrías
tener un entorno híbrido.

00:10:09.140 --> 00:10:15.780
Es decir, para aquellas cosas que necesitas
resolver toda esa complejidad relacional

00:10:15.780 --> 00:10:19.000
ya relacionada en un documento,
pues utilizarías JSON.

00:10:19.690 --> 00:10:25.830
Y para aquello, en lo que sea más
estricto, tener organizado esos maestros de talla y

00:10:25.830 --> 00:10:30.090
padrillo que tengas a lo mejor vínculos de
integridad y referenciales muy fuertes, que

00:10:30.130 --> 00:10:35.010
tengas que tener mucha integridad y mucha
consistencia en los datos, relacional, y tenerlo,

00:10:35.050 --> 00:10:41.270
según dicen, la 23C,
de forma transparente.

00:10:43.680 --> 00:10:47.740
No sé cómo lo ves esto a nosotros nos
tienen que dar una charla los seis, el día 1 de

00:10:47.780 --> 00:10:53.020
octubre nos tienen que explicar ya nos
hicieron una demo una pequeña demo de cómo crear

00:10:53.020 --> 00:10:57.860
las duality views estas pero nos tienen
que dar una charla un poco más para contarnos

00:10:57.860 --> 00:11:04.360
a ver cómo funciona quizá a lo mejor nos
cuentan cómo va más a nivel interno pero, ostras,

00:11:04.380 --> 00:11:06.300
es un acercamiento importante, ¿no?

00:11:06.340 --> 00:11:08.300
De Oracle a Mongo, es decir

00:11:10.530 --> 00:11:13.630
¿cómo lo ves eso? No les queda otra, ¿no?

00:11:13.710 --> 00:11:17.810
Al final, si no quieren perder cuota de
mercado, que se les vayan clientes, ellos lógicamente

00:11:17.850 --> 00:11:19.810
defienden su producto,
lo quieren evolucionar.

00:11:19.850 --> 00:11:25.030
Y si la demanda actual está tirando por
ahí, pues lógico que den respuesta a esas necesidades.

00:11:25.070 --> 00:11:27.830
Yo lo veo muy bien que sigan
trabajando en ese sentido.

00:11:27.870 --> 00:11:33.750
Hace, no sé, pues decirte, dos, tres años
las soluciones que estaban proponiendo eran

00:11:33.750 --> 00:11:37.890
dolores de cabeza. También te habrás
encontrado con eso de, vale, si tú te creas aquí

00:11:37.930 --> 00:11:45.030
una columna de tipo JSON, que antes no era
ni JSON, era o XML o directamente un text

00:11:45.030 --> 00:11:49.230
grande o algo así. Y entonces metes ahí
las cosas y entonces ponte a lanzar consultas

00:11:49.270 --> 00:11:51.890
sobre eso. Son consultas sobre cadenas.

00:11:52.070 --> 00:11:54.530
O sea, eran súper eso es el infierno.

00:11:55.190 --> 00:12:00.470
Ahora, las propuestas de ahora, pues si
tienen más coherencia, lo están haciendo más

00:12:00.470 --> 00:12:03.410
agradable y más... Pues
ahora la verdad es que sí.

00:12:03.850 --> 00:12:06.090
Pobrez también está en ese intento.

00:12:06.810 --> 00:12:12.090
Sí, Poses también va a intentar
meter documental y todo eso.

00:12:12.090 --> 00:12:19.490
Sí, hace tiempo ya que tiene el tipo de
dato JSON y, bueno, pues con su juego de herramientas,

00:12:19.490 --> 00:12:21.390
de funciones para poder
acceder a la información, ¿no?

00:12:21.430 --> 00:12:25.810
De buscar el valor de un determinado campo
dentro de ese campo JSON que al final no deja

00:12:25.850 --> 00:12:29.870
de ser texto. Y están ahí, sigue
siendo Todavía arduo, ¿vale?

00:12:29.930 --> 00:12:35.250
Pero, bueno, están ahí en el intento y es
lógico lo que tienen que hacer, que es darnos

00:12:35.250 --> 00:12:38.330
facilidades y servicio a los clientes.

00:12:38.330 --> 00:12:43.950
Sí, es interesante porque al final parece
que lo están acotando todo a decir, bueno,

00:12:44.030 --> 00:12:51.550
no tenemos por qué tener un solo
estándar y al final el cliente

00:12:51.550 --> 00:12:59.570
tiene la razón cuando está teniendo a lo
mejor entornos en los que hay modelos documentales

00:12:59.570 --> 00:13:03.730
y un poco cada cosa para su función.

00:13:03.730 --> 00:13:10.950
Pero sí parece que están acotando mucho,
como te está diciendo, a manejar con Graph,

00:13:11.150 --> 00:13:15.250
SQL y JSON. Es decir, bueno,
vamos a entender estos tres.

00:13:15.610 --> 00:13:19.888
Para ciertos temas analíticos y tal,
Graph es muy visual, es muy interesante.

00:13:21.370 --> 00:13:29.290
Y para eso, para la gestión de aplicaciones
y tal, pues la parte de Jason, creo, yo

00:13:29.290 --> 00:13:36.310
creo que va a sustituir al XML, aunque
cuidado, hay muchísimas cosas que

00:13:36.310 --> 00:13:42.470
están con el XML. Las nóminas del banco te
siguen pidiendo, sube el fixero que se miele

00:13:42.470 --> 00:13:45.490
de la remesa, es decir,
los bancos que aún siguen.

00:13:46.310 --> 00:13:50.710
Yo apunto contigo a que el XML desaparece,
lo que pasa que lógicamente habrá muchas cosas

00:13:50.750 --> 00:13:55.570
todavía, pero ya se están las cosas nuevas
ya se hacen con JSON yo creo que el XML, es

00:13:55.570 --> 00:14:01.970
más potente JSON que el XML, acabará por
caer en desuso En base a datos, en base a datos

00:14:01.970 --> 00:14:06.410
sobre todo en base a datos sobre todo es
decir, en base a datos tú tenías la posibilidad

00:14:06.450 --> 00:14:12.710
de hacer tablas Sanidadas, definir
utilizar lo que hicieron como orientación a objetos

00:14:12.710 --> 00:14:17.550
en la versión 8 de decir, bueno, yo tengo
una columna que es de un tipo, que es un tipo

00:14:17.550 --> 00:14:23.230
array y eso cuando implemento la tabla
tengo una columna que es una tabla anidada y de

00:14:23.230 --> 00:14:27.650
ahí poder construir a partir de queries
una salida en formato xml, un poco más o menos,

00:14:27.690 --> 00:14:32.450
con un par de tablas, más o menos podías
hacerlo pero no cuando la complejidad relacional

00:14:32.490 --> 00:14:36.790
era mucho más grande y entiendo que con
JSON eso lo tienen mucho más resuelto.

00:14:36.830 --> 00:14:42.270
Mucho más resuelto, sí Qué bueno Luego en
el caso, por ejemplo, en MongoDB aunque los

00:14:42.270 --> 00:14:46.530
documentos están en formato JSON, pero la
base de datos internamente los almacena en

00:14:46.570 --> 00:14:52.110
su equivalente binario. Entonces, lo que
se guarda realmente es binario, que ocupa mucho

00:14:52.110 --> 00:14:53.610
menos, es mucho más rápido.

00:14:54.050 --> 00:14:58.790
Y, o sea, que al final también ese
formato permite esa traducción.

00:14:59.540 --> 00:15:05.720
¡Qué bueno! Oye, cuéntame, vamos a hablar
un poco de MongoDB, ¿cómo lo ves tú que está

00:15:05.720 --> 00:15:09.860
implantado? ¿Tú lo ves, por ejemplo, que
la gente está sustituyendo oracles por Mongo,

00:15:09.900 --> 00:15:15.360
que son complementarios en los clientes
más buenos que conozcas o los clientes para los

00:15:15.360 --> 00:15:19.440
que has trabajado? ¿Cómo ves
tú que cohabitan estas dos?

00:15:20.350 --> 00:15:26.430
No, no, yo en la otra charla recuerdo que
te dije, no, Oracle o sea, Postgres, hay clientes

00:15:26.430 --> 00:15:29.652
que Se pasan de Oracle a
Postgres porque es un equivalente

00:15:30.610 --> 00:15:36.750
Válido y a coste cero, principalmente pero
en el caso de Mongo no te diría no considero

00:15:36.750 --> 00:15:42.010
que lo esté sustituyendo yo creo que son
complementarios Mongo debe cuidado, es un como

00:15:42.010 --> 00:15:47.810
empresa, es una empresa que funciona muy
bien el soporte que dan es buenísimo, tienen

00:15:47.810 --> 00:15:49.890
Tienen la versión community
también, gratuita.

00:15:49.930 --> 00:15:52.819
La página web Buscar
Documentación es una maravilla.

00:15:54.030 --> 00:15:56.470
Y, bueno, es ¿Cómo funciona el soporte?

00:15:56.570 --> 00:15:57.210
¿Cómo funciona el soporte?

00:15:57.250 --> 00:16:00.010
Es como a lo mejor también...

00:16:00.010 --> 00:16:01.732
El soporte, claro, lo que yo he

00:16:04.040 --> 00:16:09.160
Conocido en mi... Pues tú lo has dado

00:16:10.760 --> 00:16:13.180
Bien de no, yo que sé es que...

00:16:17.900 --> 00:16:25.240
Bueno, Ahí está. ...implicado

00:16:25.380 --> 00:16:28.420
la comunidad, nos damos
soporte los unos a los otros.

00:16:28.480 --> 00:16:32.020
Que no te creas, ¿eh? También es
maravilloso porque yo mando un correo electrónico cuando

00:16:32.060 --> 00:16:34.020
tengo un problema al grupo, ¿vale?

00:16:34.080 --> 00:16:40.240
Al grupo de administradores de Postgres y
de seguida me están conectando, me están contestando,

00:16:40.240 --> 00:16:44.420
perdona, personas que son del grupo de
desarrollo global de Postgres, que yo muchas veces

00:16:44.460 --> 00:16:49.360
veo la respuesta y veo la firma y digo,
wow, es que me ha escrito el Tom Lane, ¿sabes?

00:16:49.440 --> 00:16:52.640
Y me quedo flipando, digo, ¿cómo tiene
esta gente tiempo para contestarme a mí?

00:16:52.680 --> 00:16:58.480
No sé. Es muy bueno pero bueno, MongoDB ha
tenido otra vez la oportunidad de tener un

00:16:58.480 --> 00:17:03.940
soporte, o sea, de disfrutar de un soporte
de pago, porque al final el cliente para el

00:17:03.940 --> 00:17:07.980
que yo estoy trabajando ahora paga
a MongoDB para que nos dé soporte.

00:17:07.980 --> 00:17:12.600
Entonces, el soporte funciona muy
bien, o sea, te atienden muy rápido.

00:17:12.640 --> 00:17:17.200
Además, se involucran mucho en enseñarnos
a los DBAs para que nos aprendamos a manejar

00:17:17.240 --> 00:17:21.740
solos. Hacen unas sesiones
prácticamente de formación de tú a tú.

00:17:23.080 --> 00:17:28.680
Y bueno, hoy hemos tenido una incidencia
grave y nada, enseguida se han conectado con

00:17:28.680 --> 00:17:31.420
nosotros en videollamada y a
resolverla y aprendes un montón.

00:17:31.460 --> 00:17:35.120
Que casi agradeces que hayan incidencias
de ese tipo porque dices, ¿qué cuatro horas

00:17:35.160 --> 00:17:38.660
me he pasado aprendiendo de esta gente?

00:17:38.740 --> 00:17:40.480
¿De qué tengo que mirar? ¿Qué no sé qué?

00:17:40.520 --> 00:17:44.040
Todo, ¿sabes? Cosas que tú, bueno, las
sabes, a lo mejor las has estudiado, pero cuando

00:17:44.080 --> 00:17:46.469
te enfrentas a eso
siempre hay cosas que...

00:17:46.520 --> 00:17:51.500
Madre mía, ostras. Y estoy muy contenta,
la verdad, el soporte funciona muy bien.

00:17:51.740 --> 00:17:55.760
La empresa de Río como empresa
es de una estructura y da gusto.

00:17:56.750 --> 00:18:00.230
Pasearte por la página web de Mongo
y luego me dices, ¿solo con eso?

00:18:00.270 --> 00:18:03.850
Sí, le echáis un ojo hombre, la
página web de Oracle es gigantesca.

00:18:03.890 --> 00:18:05.930
Eso es papel, lo se puede decir.

00:18:06.770 --> 00:18:08.850
¿Eh? Dime tú puedes decir lo que quieras.

00:18:08.890 --> 00:18:11.730
Aquí Oracle no paga nada, no patrocina.

00:18:11.850 --> 00:18:14.350
O sea, aquí se puede hablar
la experiencia de cada uno.

00:18:14.390 --> 00:18:17.390
¿Las opiniones de las personas
son personales intransferibles?

00:18:17.430 --> 00:18:20.763
Iba a decir, es para pegarse
un tiro, pero es que queda feo.

00:18:21.110 --> 00:18:25.750
Bueno, pero no, la página web de Oracle
tal cual, cuando entras en la documentación yo

00:18:25.790 --> 00:18:30.030
creo que la han indexado muy bien esto yo
creo que la ha mejorado muchísimo y la página

00:18:30.070 --> 00:18:33.910
de descargas quizá, a lo mejor te puedes
perder un poco pero es que hay tantos productos

00:18:33.950 --> 00:18:38.030
que pero bueno, a lo mejor
¿cuántos componentes hay?

00:18:38.450 --> 00:18:43.850
La base de datos, conectores cliente
y poco más Sí, bueno, tiene su

00:18:45.410 --> 00:18:49.770
Plataforma en la nube también tiene
bastante software, pero bueno Bueno, no como Oracle,

00:18:49.810 --> 00:18:51.250
es que Oracle es un gigante.

00:18:51.290 --> 00:18:55.710
Pero dentro de que es un gigante, la
parte, ese acercamiento a la página web tiene que

00:18:55.750 --> 00:18:59.770
ser algo mucho más sencillo cuando utilizas
el buscador que hacierte un poquito más,

00:18:59.810 --> 00:19:01.470
no sé. Ahí yo lo tengo...

00:19:03.090 --> 00:19:04.510
Tengo muchas quejas sobre...

00:19:04.550 --> 00:19:07.670
Pero bueno, también es
verdad que hace tiempo que no

00:19:08.770 --> 00:19:10.530
busco cosas ahí en Oracle también.

00:19:10.570 --> 00:19:14.570
Fíjate, yo me pierdo buscando en
Metalink, buscando los parches.

00:19:14.750 --> 00:19:17.670
Cada vez que tengo que buscar un parche,
digo, es que como puede ser que ya, mira que

00:19:17.710 --> 00:19:22.950
llevo años, no lo encuentro nunca la
primera nunca digo pero por favor no no no habrá

00:19:22.950 --> 00:19:29.970
alguna forma fácil de decir el parche de
julio aquí descargátelo aquí no el último madre

00:19:29.970 --> 00:19:36.990
mía cada vez que lo busco
familia plataforma no sé qué pero

00:19:36.990 --> 00:19:42.230
que no se desanimen al final tener cosas
en las que mejoran es un aliciente también para

00:19:42.230 --> 00:19:46.790
seguir progresando o sea que ahora que
tiene ahí para mejorar un poquito y ya está, que

00:19:46.830 --> 00:19:49.070
estemos más contentos los DBAs.

00:19:49.070 --> 00:19:52.510
¿Y tú crees que los DBAs
estamos yendo cada vez a un...?

00:19:52.510 --> 00:19:54.990
Porque como dicen que
los DBAs vamos a morir...

00:19:55.030 --> 00:19:59.830
Bueno, lo iban diciendo desde la 9i, que
la tarea de los DBAs va a desaparecer.

00:20:00.350 --> 00:20:06.850
Yo creo que no mientras haya que hablar
con humanos, vamos a seguir siendo necesarios.

00:20:07.070 --> 00:20:08.903
Yo creo que no, eso es como todo.

00:20:09.070 --> 00:20:11.750
A ver, y si tuviéramos que
desaparecer, ¿qué hacemos?

00:20:11.790 --> 00:20:16.068
Si los fabricantes de biscuits, pues
ahora buscan la vida haciendo otra cosa.

00:20:16.470 --> 00:20:21.710
No vamos a estar buscando que los
pobrecitos tengan trabajo, pues nosotros si llega el

00:20:21.710 --> 00:20:24.390
momento que no nos hacemos falta,
Pues aprenderemos otra cosa.

00:20:24.430 --> 00:20:29.150
Pero no lo tengo todas conmigo, porque es
verdad, mira, yo ahora con MongoDB trabajo

00:20:29.150 --> 00:20:34.010
con servidores on -prem, pero también con
la plataforma en la nube y la herramienta es

00:20:34.010 --> 00:20:38.370
una pasada, porque hasta tienes un
apartado donde te propone los índices, o sea, te hace

00:20:38.410 --> 00:20:44.550
su análisis de consultas, te dice, te las
ordena y te dice, esta es la que más tarde

00:20:44.550 --> 00:20:48.650
te tarda 6 minutos, esta tal, te propone
los índices y entonces haciendo un análisis

00:20:48.690 --> 00:20:52.550
de todo eso, además con el soporte de Mongo,
no lo hacía yo que me pueda equivocar.

00:20:52.590 --> 00:20:57.990
O sea, te voy a decir, con la gente
experta, pues había una consulta que estaba utilizando,

00:20:58.050 --> 00:21:04.050
no estaba utilizando un índice que era el
mejor para esa consulta, estaba utilizando

00:21:04.050 --> 00:21:10.090
otro que también tenía, porque al final,
dices tú, si es, y al final nos dijo, el propio

00:21:10.090 --> 00:21:11.990
soporte dijo, utilizar un GINT,

00:21:17.780 --> 00:21:23.600
Dice que, Correcto, que
al final la tecnología,

00:21:25.260 --> 00:21:38.910
Tecnología, lo Más... ¿Tú

00:21:39.100 --> 00:21:46.180
crees que vamos en dirección, así
como hablan de la multinube y que un

00:21:46.180 --> 00:21:50.200
poco, porque están diciéndonos, es decir,
pues los que sean arquitectos de OCI van a

00:21:50.240 --> 00:21:55.060
tener que saber de las otras nubes porque
vamos a estar, todos vamos a ser vecinos y

00:21:55.060 --> 00:22:00.400
al final pues hay una certificación
multicloud, todas tienen su certificación multicloud.

00:22:00.600 --> 00:22:08.140
¿Tú crees que los DBAs vamos a ir al final
a un modelo, entre comillas, de multibase

00:22:08.140 --> 00:22:13.920
de datos, de que se pida un DBA de Oracle
que sepa también de Mongo, que sepa también

00:22:13.920 --> 00:22:20.380
de, bueno, hablar de otras, Cassandra, que
son así, Gerard, que son así, pero, ¿tú crees

00:22:20.380 --> 00:22:26.480
que se va a pedir que los DBAs conozcamos
más horizontalmente los otros motores?

00:22:26.480 --> 00:22:33.500
O crees que vamos a seguir con esas
especializaciones y decir, no, es que encontrar un

00:22:33.500 --> 00:22:39.420
administrador de Mongo solo saber Mongo ya
requiere o solo saber Oracle para mí la certificación

00:22:39.420 --> 00:22:43.160
de Oracle ya es como para decir, me dedico
solo a esto, no me puedo dedicar a 20 cosas

00:22:43.200 --> 00:22:48.800
más. Pero como un poco cada vez vamos todo
a que sea un poco más sencillo y más manejable

00:22:48.800 --> 00:22:55.800
¿tú crees que Vamos a Multibase de datos,
multiplataforma o a especializarnos

00:22:55.800 --> 00:23:02.940
en cosas distintas aquí nos dirigimos no
te lo sé decir porque la verdad que yo previendo

00:23:02.940 --> 00:23:08.760
como se diga el futuro soy muy buena te
diría que yo considero que deberíamos de no deberíamos

00:23:08.760 --> 00:23:13.820
de perder la especialización en algún
motor o algunos motores los que nuestra capacidad

00:23:13.820 --> 00:23:19.260
tiempo y volumen de trabajo nos permita
porque yo también entiendo que en tu caso está

00:23:19.260 --> 00:23:23.020
dedicado ahora que el cien por cien obra
que consume todo tu tiempo porque también tienes

00:23:23.060 --> 00:23:25.340
muchos clientes que te demandan ese motor.

00:23:25.380 --> 00:23:27.220
Entonces, ¿por qué tienes
que estudiar de otro?

00:23:27.260 --> 00:23:31.120
Eres bueno en eso, continúas siendo bueno
en eso porque el producto no va a dejar de

00:23:31.160 --> 00:23:33.960
evolucionar y tú tienes que ir
evolucionando a la vez que él.

00:23:34.000 --> 00:23:38.420
Bastante tienes con estudiar las novedades
que vayan saliendo sobre Oracle, ¿no?

00:23:38.460 --> 00:23:42.940
Pero luego hay motores, pues a lo mejor si
MongoDB es más sencillo, a lo mejor pues eso

00:23:42.980 --> 00:23:47.820
hay un cliente, el que tengo yo ahora mismo
es un cliente, se puede llevar junto con

00:23:47.820 --> 00:23:53.640
otros motores, a lo mejor en mi caso, si
yo llevo mongos y postgres, pues no estés cabellado,

00:23:53.680 --> 00:23:55.124
por el volumen de trabajo.

00:23:55.580 --> 00:24:00.120
Y algo ahora, pero especialización sí,
porque de qué te sirve saber, o sea, nunca vas

00:24:00.160 --> 00:24:03.720
a saber mucho de todo. Eso,
vamos, no sé, no tienes vida.

00:24:04.640 --> 00:24:11.900
Claro, No, y por el lo que requiere
para especializarse, es decir, es

00:24:11.900 --> 00:24:16.080
fácil ser administrador de momo, o dices,
no, no, espera, que es otra carrera que te

00:24:16.120 --> 00:24:18.720
tiras tres años hasta que
puedas jugar un poco de pelota.

00:24:18.760 --> 00:24:25.820
Yo en eso, Javi, para mí la palma es
oracle, O sea, con MongoDB, yo te digo el caso mío,

00:24:25.900 --> 00:24:30.940
¿vale? Yo estaba trabajando hasta el mes
de junio, o sea, yo en julio cambié de trabajo,

00:24:31.100 --> 00:24:38.120
¿no? Y yo hasta junio estaba trabajando
con Postgres, el 95 % de las bases de datos

00:24:38.120 --> 00:24:43.160
que utilizaban eran Postgres y yo por mi
cuenta, porque me llamaba la atención, siempre

00:24:43.160 --> 00:24:46.880
me ha llamado la atención de que una base
de datos no es SQL, pero cómo se estructura

00:24:46.920 --> 00:24:51.020
la información y cómo previenes
los duplicados y cómo, ¿sabes?

00:24:51.020 --> 00:24:56.260
Era como, necesito entender cómo funciona
eso, pues por mi cuenta hace un año, además

00:24:56.260 --> 00:25:00.940
fue este verano no, el anterior empecé a
estudiar MongoDB por mi cuenta, porque además

00:25:00.980 --> 00:25:05.520
en la página web de MongoDB hay
documentación que la proporcionan ellos, te forman ellos,

00:25:05.560 --> 00:25:11.080
hay cursos el curso de administración es
verdad que está en inglés, pero está sustitulado

00:25:11.080 --> 00:25:13.960
en español, que lo de inglés para mucha
gente no es un problema hoy día, pero para mí

00:25:14.000 --> 00:25:19.240
sigue siendo pero está sustitulado en
español entonces pues los cursos muy bien Entonces

00:25:19.240 --> 00:25:23.320
yo me monté mi laboratorio de práctica, Lo
típico que hacemos cuando estamos estudiando

00:25:23.360 --> 00:25:30.540
y aprendiendo. Me tiré menos de
un año en hacer todos los cursos

00:25:30.540 --> 00:25:35.900
que habían ahí. Y entonces, claro, cuando
haces el curso de administración, haces todos

00:25:35.900 --> 00:25:42.640
los módulos, te mandan un correo que te
dice cupón del 50 % en el examen de certificación.

00:25:42.740 --> 00:25:45.360
Y valía 150 euros y dije, hostia, 75.

00:25:46.230 --> 00:25:53.230
No me digas no me digas es decir, ya el
Fundations de Oracle te cuesta esa pasta.

00:25:54.090 --> 00:25:59.090
Vas a seguirme encima si has estudiado
con ellos, te lo descuentan a la mitad.

00:25:59.870 --> 00:26:04.930
Bueno, pues hice el examen de
certificación, es proctorado, o sea, no es que te lo regalen.

00:26:05.130 --> 00:26:10.290
O sea, aseguran que eres tú, que nadie te
está activando, que no tienes apuntes en la

00:26:10.290 --> 00:26:11.670
mesa, que no tienes software de grabación.

00:26:11.710 --> 00:26:14.432
O sea, súper controlado
hice mi examen y lo pasé.

00:26:16.480 --> 00:26:18.300
Y, o sea, ¿cuánto me costó?

00:26:18.340 --> 00:26:21.700
Pues un año de estudiar y un año de
estudiar y sacarme la certificación.

00:26:21.740 --> 00:26:25.140
Eso, yo no sé, el oracle a mí me parece
que hace falta un poquito más de tiempo.

00:26:25.180 --> 00:26:27.660
¿Eso quiere decir que es
mejor o es peor, Mongo?

00:26:27.700 --> 00:26:31.200
No, yo pienso un año a la vez
que estás trabajando, ¿no?

00:26:31.260 --> 00:26:36.420
No fue un año sabático que decir, colgué
los hábitos y me tiré un año de trabajo.

00:26:36.660 --> 00:26:40.700
Yo trabajaba y estudiaba en mi tiempo libre,
como me gusta, pues no me pesaba, ¿no?

00:26:40.740 --> 00:26:44.600
Pero que te quiero decir, yo recuerdo de
cuando trabajaba con Oracle, montar el Data Guard

00:26:44.640 --> 00:26:50.120
de Oracle, fue buscándome un white paper
por ahí, supongo que por la página de Oracle,

00:26:50.280 --> 00:26:54.200
no te quiero engañar, lo encontraría por
ahí y tal, entonces lo monté yo en un laboratorio

00:26:54.240 --> 00:26:59.820
que me monté yo, me costó, pero al final
lo saqué y luego ya lo implementé, me llevó

00:26:59.820 --> 00:27:04.060
mucho tiempo, pero tú sabes cómo se monta
una réplica en Mongo, es que no hace falta,

00:27:04.100 --> 00:27:09.560
o sea, no te puedes llevar la vida, en
Postgres también es fácil, pero también te lleva

00:27:09.560 --> 00:27:11.740
tu horita en montarla, ¿sabes?

00:27:11.740 --> 00:27:15.220
Y en MongoDB si supiera
que son dos comandos.

00:27:16.220 --> 00:27:21.080
Sí, y aguanta eso, es decir, tú puedes
tener alta disponibilidad y alta criticidad de

00:27:21.080 --> 00:27:24.360
Mongo y eso aguantar
como aguanta un oracle.

00:27:25.480 --> 00:27:32.760
Tiene muy currado, MongoDB
es primario y secundario, no

00:27:32.760 --> 00:27:38.680
es multi maestro, pero puedes tenerlo
fragmentado, y puedes tener clústeres fragmentados,

00:27:38.720 --> 00:27:40.660
¿no? Sharding bueno, el sharding, sí.

00:27:40.700 --> 00:27:46.200
Claro, es que ahí es donde, digo
yo, ahí es donde te la juegas, ¿no?

00:27:46.220 --> 00:27:50.220
Cuando tú tienes una alta
disponibilidad activo, digamos, ¿no?

00:27:50.260 --> 00:27:55.440
O sea, tienes esos racks con esos disaster
recovery que tienes un stand -by, que tienes

00:27:55.440 --> 00:28:00.640
el stand -by sincronizado para que te haga
un failover automático con propagación de

00:28:00.640 --> 00:28:05.480
todo. Yo entiendo que ahí Oracle
tiene mucho trabajo en ser la...

00:28:05.480 --> 00:28:11.960
Mucho trabajo hecho, quiero decir, en ser
la plataforma para entornos críticos, de máxima

00:28:11.960 --> 00:28:17.080
disponibilidad, porque yo siempre en
broma, siempre digo eso, el RAC no es alta disponibilidad,

00:28:17.120 --> 00:28:20.900
porque el RAC se te cae el clusterware
y tienes un único punto de falla.

00:28:20.940 --> 00:28:24.960
A mí no pero claro, luego dices, no, es
que luego está la máxima disponibilidad, ¿no?

00:28:25.000 --> 00:28:29.300
Cuando dices, tengo RAC con Data Guard,
con otro nivel de Disaster Recovery, con una Team

00:28:29.340 --> 00:28:34.660
Data Guard, cuando, vale, dices, tienes
una infraestructura muy, muy, muy tocha, Y el

00:28:34.660 --> 00:28:40.580
RA lo puedes tener de 50, sin
problema, y terabytes a punta pala.

00:28:40.680 --> 00:28:43.700
Perfecto ¿Con Mongo hasta dónde llegamos?

00:28:44.100 --> 00:28:48.100
¿Con almacenamiento, por ejemplo,
memoria, shard y todo eso, servidores?

00:28:48.940 --> 00:28:53.780
Sí, todo eso está muy currado, pero ya te
digo, Lo que han hecho es la sencillez máxima,

00:28:53.820 --> 00:28:56.500
pero lo que estás comentando
exactamente lo tiene Mongo así también.

00:28:56.540 --> 00:29:01.260
Al final, los SART, tengo una base de
datos fragmentada porque en RAS, corrígeme si me

00:29:01.300 --> 00:29:06.360
equivoco, creo que la base de datos está
distribuida, pero las instancias son individuales,

00:29:06.360 --> 00:29:10.640
o sea, cada instancia tiene su memoria y
su proceso, memoria, proceso, memoria, proceso,

00:29:10.680 --> 00:29:12.180
y lo que está distribuida en
la base de datos puede ser.

00:29:12.220 --> 00:29:18.100
La base de datos está en un mismo lugar
que sería el ASM, la nube de almacenamiento en

00:29:18.100 --> 00:29:21.300
la cabina de discos y
digamos, tú tienes un acceso

00:29:23.440 --> 00:29:28.160
Concurrente organizado entre todo, luego
aparte las cachés están fusionadas, es decir,

00:29:28.200 --> 00:29:35.800
hay como el bloque que tú estás modificando
en una instancia tienes como un mapeo

00:29:35.800 --> 00:29:43.140
de dónde está el bloque original, quién
es el máster de bloques y bueno, pero en

00:29:43.140 --> 00:29:46.400
realidad base de datos solo tienes una, lo
único que tienes es que puedes, sobre esa

00:29:46.440 --> 00:29:52.260
base de datos física, los ficheros solo
están una vez, puedes levantar varias instancias

00:29:52.260 --> 00:29:58.140
en varios servidores para que cada uno
atienda, cada instancia puede tener su servidor

00:29:58.140 --> 00:30:05.460
tiene su rollback y tal y bueno de

00:30:05.460 --> 00:30:10.480
Ridulog pues tiene también la escritura.

00:30:11.020 --> 00:30:18.470
Es decir, es una levantada y accesible

00:30:18.470 --> 00:30:23.359
desde varios servidores. Si tienes alta
disponibilidad, que se caiga un nodo y el resto,

00:30:23.470 --> 00:30:30.250
si tú tienes transparente, los otros nodos
sí absorben incluso la sesión y podrían continuar

00:30:30.250 --> 00:30:37.570
la sesión sin problemas. Podría de la de
la transacción pero podría recordar podría reconectar

00:30:37.570 --> 00:30:43.080
y continuar sí pues aquí como es parecido
pero no es igual lo que lo como ellos lo han

00:30:43.080 --> 00:30:50.200
resuelto es tú tienes una serie de sartes
sart 0 el saludo es algo por ejemplo

00:30:50.200 --> 00:30:55.720
no entonces tú tienes tu base de datos
distribuida en esos sal pero esos son base de

00:30:55.720 --> 00:31:00.140
datos a son disco memoria son sé que
son servidores completos con su espacio.

00:31:00.700 --> 00:31:05.080
¿Qué es lo que hace? Pues tú las colecciones,
Que las colecciones son el equivalente

00:31:05.120 --> 00:31:10.060
a tabla, hemos dicho, las colecciones que
son pequeñitas, esas no se sardean, esas se

00:31:10.060 --> 00:31:14.160
dejan enteras en lo que se llama el SAR
primario, vamos a suponer que es el SAR cero.

00:31:14.200 --> 00:31:18.100
Y luego las colecciones que son grandes,
que esas si las quieres fragmentar, pues eligen

00:31:18.140 --> 00:31:22.720
la clave de SAR por la que la vas a fragmentar
y entonces pues si tienes tres, ellos

00:31:22.760 --> 00:31:27.820
solitos se dividen y se van balanceando
conforme va creciendo la información en alguno

00:31:27.820 --> 00:31:31.876
de de los SAR, hay un balanceador que
te va distribuyendo la información.

00:31:32.280 --> 00:31:37.520
Pero es que luego cada SAR por sí mismo es
un réplica set, es decir, te estás conectando

00:31:37.520 --> 00:31:41.880
a un primario pero tienes dos secundarios
por debajo, que en caso de que un SAR te falle,

00:31:41.920 --> 00:31:45.200
no te está fallando los tres servidores,
te está fallando sólo el principal.

00:31:45.240 --> 00:31:47.740
Y entonces un secundario
sube como principal.

00:31:48.000 --> 00:31:52.720
Entonces tienes cubierta la alta
disponibilidad, aparte del escalado horizontal.

00:31:53.850 --> 00:31:57.430
Esa es la forma Oracle
también tiene el sharding.

00:31:57.970 --> 00:32:04.010
Tú también tienes un componente que es
configurar Oracle con una arquitectura de sharding

00:32:04.010 --> 00:32:09.980
y más o menos, bueno, no tengo mucha
experiencia en eso, también tengo experiencia en

00:32:09.980 --> 00:32:13.147
el sharding de Oracle, pues
puede participar y contarnos.

00:32:15.120 --> 00:32:22.120
Pero bueno, es decir, el sharding apareció
un poco como quizá a lo mejor para

00:32:22.120 --> 00:32:26.820
emular el funcionamiento de Mongo, para
decir, bueno, yo también puedo implementar ese

00:32:26.860 --> 00:32:34.500
sharding con varios shards y
jugar un poco con esa colección de

00:32:34.500 --> 00:32:40.280
replicación. Y un poco, estoy mirando aquí
la documentación dice pues que está orientado

00:32:40.280 --> 00:32:44.410
para Alta disponibilidad Sí,

00:32:45.390 --> 00:32:52.190
claro, una vez que el motor puede
implementar eso, el escalado horizontal con alta disponibilidad

00:32:52.190 --> 00:32:55.970
lo tiene todo cubierto, porque ahí puedes
añadir shard todos los que quieras, cuanta

00:32:56.010 --> 00:33:03.030
más demanda más necesidades, más shard y
problema resuelto Sí, una base de datos sharded

00:33:03.030 --> 00:33:09.150
es una base de datos single logical que
está particionada de forma horizontal a través

00:33:09.150 --> 00:33:16.890
de un pool de bases de datos
oracle físicas que no comparten

00:33:16.890 --> 00:33:23.890
hardware o software. Es como
repartir una estructura lógica

00:33:23.890 --> 00:33:31.410
particionada, entiendo, o
replicada entre varios sitios.

00:33:31.410 --> 00:33:38.630
Pero bueno muy interesante al final yo
creo que el pescatero de arriba sabe qué

00:33:38.630 --> 00:33:43.850
es lo que está haciendo el pescatero de
abajo y un poco se están vigilando un poco que

00:33:43.850 --> 00:33:49.330
hace uno y luego te digo lo que más me
impresionó de MongoDB una de las cosas que más

00:33:49.330 --> 00:33:55.370
me gusta que hay bastantes pero tú sabes
estas consultas en SQL que son uniones de muchas

00:33:55.370 --> 00:33:59.090
tablas pero tienes que ponerle un subsales
para a sacar no sé qué y además luego tienes

00:33:59.130 --> 00:34:02.070
que hacer el group by y te sale
una pedazo de consulta que eso...

00:34:02.110 --> 00:34:07.670
Es complicadísimo entenderla de un golpe
de vista, es complicadísimo optimizarla porque

00:34:07.670 --> 00:34:11.392
aunque tú ejecutes el explain es
que tú ya no sabes qué va a pasar.

00:34:11.910 --> 00:34:15.830
Horrible, ¿no? Si tú supieras esas
consultas pesadas como se Hacen en Mongo, un día te

00:34:15.870 --> 00:34:18.670
voy a dar una masterclass
exclusiva para ti.

00:34:19.330 --> 00:34:24.830
Oh, oh, yo quiero sí, sí, te lo digo en
serio, pero solamente para que veas qué dices

00:34:24.830 --> 00:34:31.310
tú. Dios, cómo lo han resuelto de una
forma tan sencilla y entonces quedan las consultas

00:34:31.310 --> 00:34:36.430
súper súper claro súper sencilla es lo que
hacen al final es una tubería de agregación

00:34:36.430 --> 00:34:40.790
o sea lo que van haciendo es ir pasando
los documentos de etapa en etapa tú qué quieres

00:34:40.830 --> 00:34:45.550
hacer quieres filtrar datos pues sobre la
colección dime la etapa de filtrado entonces

00:34:45.590 --> 00:34:49.310
a la salida que tienes los documentos que
te interesan ahora que quieres agrupar pues

00:34:49.350 --> 00:34:52.730
entras una etapa de agrupación pero claro
tú cuando lees la consulta estás viendo las

00:34:52.770 --> 00:34:57.330
etapas y al final la última es la de
ordenación o la última es la de que te lo vuelque

00:34:57.370 --> 00:35:02.910
en otra colección. Entonces se ve todo
clarito así para abajo porque las consultas SQL

00:35:02.910 --> 00:35:05.521
son como anidadas para
adentro y súper grandes.

00:35:06.870 --> 00:35:09.570
Son un esqueletito así delicado y sutil.

00:35:10.430 --> 00:35:13.090
Sería muy fácil y la verdad
es que es una pasada.

00:35:13.130 --> 00:35:16.910
Qué bueno, pues sería una forma visual de
ver el árbol de ejecución porque muchas veces

00:35:16.950 --> 00:35:21.190
es un explain plan si estás viendo
cruces digamos de dos en dos.

00:35:21.390 --> 00:35:23.070
Todo va un poco como a pares.

00:35:24.090 --> 00:35:28.070
Esta tabla con esta a esta tabla accedo a
través de un índice y la combino con esta otra,

00:35:28.110 --> 00:35:33.350
el resultado lo combino es decir, al final
el árbol de ejecución es ir pareando e ir

00:35:34.310 --> 00:35:41.150
agrupando hacia el tronco, digamos a mí me
resulta a veces complejo, optimizar una consulta

00:35:41.150 --> 00:35:47.770
base de tiras del explain sí es difícil,
pero esas cosas que dices es nuestro día a día,

00:35:47.870 --> 00:35:53.610
pero algunas dices tú me va de mí claro,
como esa imagen de Matrix Al final ya lo veo,

00:35:53.790 --> 00:35:57.390
¿no? Yo veo rubia, morena...

00:35:58.790 --> 00:36:01.550
Y luego tiene muchas cosas en común
que también me sorprendieron, ¿eh?

00:36:01.590 --> 00:36:07.210
Porque MongoDB, al igual que Oracle, al
igual que Postgre, implementa su cuaderno de

00:36:07.210 --> 00:36:10.870
bitácora, ¿no? Lo que en Oracle
es el red o en Postgre es el wall.

00:36:10.910 --> 00:36:14.690
MongoDB tiene su journal, es que es
lo mismo, la misma implementación.

00:36:14.730 --> 00:36:16.470
Tienen muchas similitudes también.

00:36:16.510 --> 00:36:21.232
O sea, al final, como motor de base de
datos, lo que es la base, no es tan diferente.

00:36:21.760 --> 00:36:26.960
Y tú puedes recuperar cosas así, puedes
recuperar en el journal, digamos, quién ha hecho

00:36:26.960 --> 00:36:31.160
qué determinada modificación,
como en el logminer o cosas así.

00:36:31.540 --> 00:36:38.880
Supongo que necesitas, o sea, con auditorías,
leer directamente el journal, pues

00:36:38.880 --> 00:36:40.510
la verdad es que hasta ahí no he llegado.

00:36:40.550 --> 00:36:46.910
Ah bueno y un poco cómo funciona
internamente el Mongo así transacciones

00:36:47.870 --> 00:36:54.710
inserts Tiene su propio juego claro,
porque claro, ya olvídate de SQL estamos hablando

00:36:54.710 --> 00:36:59.910
que no es una base de datos SQL, entonces
tú no haces select no haces insert, no haces

00:36:59.910 --> 00:37:04.590
update sabes, todas esas operaciones
olvídate de hecho trabaja en un modo que ellos le

00:37:04.630 --> 00:37:08.730
llaman el modo perezoso porque para crear
una tabla no tienes que hacer un create table,

00:37:08.770 --> 00:37:11.330
nombre de la tabla y
definir las columnas, ¿no?

00:37:11.370 --> 00:37:15.750
Directamente dices que quieres
insertar en una colección que se llama

00:37:16.810 --> 00:37:20.730
clientes, que ni existe, pero tú dices que
quieres insertar en clientes y que quieres

00:37:20.770 --> 00:37:24.810
insertar este documento, y tú le mandas el
documento y él coge y te crea la colección

00:37:24.850 --> 00:37:27.072
clientes y te inserta el documento, ¿no?

00:37:27.190 --> 00:37:32.390
Cuando en una base relacional te
diría, no existe la tabla, ¿no?

00:37:32.430 --> 00:37:36.370
Y si no ha metido las columnas que son,
pues no existen las columnas, o sea, quejas por

00:37:36.410 --> 00:37:38.010
todos lados, ¿no? Y aquí
se lo traga todo, ¿no?

00:37:38.050 --> 00:37:40.670
Y bueno, lo que decía, no existe el SQL.

00:37:40.890 --> 00:37:45.750
Entonces, el tema transacciones, tienen
su juego que se llaman operaciones CRUD.

00:37:46.030 --> 00:37:52.250
CRUD son las siglas de
Create, Read, Update y Delete.

00:37:53.370 --> 00:38:00.240
Creación, Replace, de
reemplazar, Update, actualizar.

00:38:00.320 --> 00:38:02.000
Bueno, hay operaciones CRUD.

00:38:02.000 --> 00:38:07.780
Y entonces, claro, tú tienes esas
operaciones para hacer inserciones que puedes hacer

00:38:07.780 --> 00:38:12.380
un insert one, te inserta un documento
puedes hacer un insert Many, te inserta varios

00:38:12.420 --> 00:38:17.720
documentos a la vez, update one que te
actualiza uno, update many que te actualiza varios

00:38:18.560 --> 00:38:24.480
tiene su propio API para acceder, para
manejar la información de la base de Atom Mongo

00:38:24.480 --> 00:38:29.460
eso hay que aprenderlo, es como aprender
SQL por primera vez en nuestra vida hace unos

00:38:29.460 --> 00:38:37.390
pocos de años Aprender otro juego, otro
lenguaje Qué bueno Qué bueno, qué bueno Muy

00:38:37.770 --> 00:38:42.950
interesante Y una pregunta, ¿cómo ves
que está el mercado La parte humana?

00:38:43.110 --> 00:38:49.290
La parte, digamos, de clientes Y de
instalaciones y tal Vista ¿Cómo lo ves?

00:38:49.650 --> 00:38:53.290
Hay profesionales de Mongo,
hay demanda Se piden personas

00:38:54.810 --> 00:39:02.210
Exclusivas de Mongo ¿Tú qué tendencia
ves en las ofertas o en las posibilidades

00:39:02.210 --> 00:39:08.240
de... Mira, MongoDB hoy día se pide
en exclusiva, creo que no, ¿vale?

00:39:08.300 --> 00:39:14.280
Yo no creo que se pida en exclusiva
MongoDB porque ahora mismo MongoDB se está utilizando

00:39:14.280 --> 00:39:17.240
para implementaciones nuevas, por
lo menos es lo que yo veo, ¿no?

00:39:17.280 --> 00:39:23.060
Cuando se van a poner a desarrollar una
aplicación móvil nueva, pues se decantan o

00:39:24.220 --> 00:39:28.100
probablemente se decanten por una base de
datos Mongo por debajo, pero a lo mejor la

00:39:28.140 --> 00:39:32.440
base de datos principal y donde está la
información originalmente es un orable por decir

00:39:32.480 --> 00:39:37.520
algo entonces simplemente pues poco a poco
irá ganando terreno, o sea MongoDB es una

00:39:37.520 --> 00:39:42.280
base de datos que merece la pena conocerla
y todo el paradigma, no sé, no SQL es muy

00:39:42.280 --> 00:39:47.060
interesante, yo creo que está y estará en
el futuro esto no es algo que va a ser desde

00:39:47.060 --> 00:39:50.820
mi punto de vista no va a ser una moda
pasajera viene para quedarse, entonces sí que

00:39:50.860 --> 00:39:54.360
merece la pena aprenderlo, lo están
demandando pues sí, cada vez más Lleva tiempo, ¿eh?

00:39:54.400 --> 00:39:56.900
Lleva tiempo y está bien pagado

00:39:58.800 --> 00:40:00.411
¿cómo de bien pagado estamos?

00:40:00.560 --> 00:40:04.960
Más que verá que menos que verá que más o
menos estas cosas quedan feas pero yo estoy

00:40:05.000 --> 00:40:09.240
contenta, yo estaba muy contenta en el
trabajo que tenía antes yo he estado 20 años,

00:40:09.280 --> 00:40:14.200
tú lo sabes casi 20 años trabajando
para un servicio de emergencias

00:40:15.260 --> 00:40:19.360
bueno, yo estaba encantada he aprendido
muchísimo, pero es verdad que era el servicio

00:40:19.400 --> 00:40:23.220
de emergencias, entonces 20 años haciendo
lo mismo, trabajando con en el mismo motor

00:40:23.260 --> 00:40:26.800
y todo. Llega un momento que la
gente así que somos inquietas, ¿no?

00:40:26.840 --> 00:40:30.100
Como yo pues llega un momento que tocas
techo y dices, no puedo progresar más.

00:40:30.140 --> 00:40:34.300
Y luego también había un techo económico,
o sea, un servicio público, que lo público

00:40:34.340 --> 00:40:36.620
está muy bien, que hay que guardar
el dinero, que es de todos.

00:40:36.660 --> 00:40:39.060
Entonces, ¿qué pasa? Que no tenías
tampoco posibilidad de ganar más.

00:40:39.100 --> 00:40:43.989
Entonces, La aspiración económica, por un
lado, que no es lo que más pesa, pero también,

00:40:44.140 --> 00:40:45.720
sobre todo porque hace falta, ¿no?

00:40:45.760 --> 00:40:49.440
Y sobre todo la inquietud esa
mía de querer aprender más y de

00:40:50.400 --> 00:40:54.200
la ansiedad que tengo siempre por
aprender, que es verdad que la tengo, pues eso me llevó

00:40:54.240 --> 00:40:57.300
a cambiar de trabajo, entonces estoy
contenta, si me preguntas económicamente estoy muy

00:40:57.340 --> 00:41:01.700
contenta Sí, pero no solo tú, es decir, tú
cuando ves por ejemplo las ofertas, ves que

00:41:01.740 --> 00:41:08.820
lo más cotizado a lo mejor es
Oracle, lo menos cotizado es yo que

00:41:08.820 --> 00:41:13.260
sé MySQL o ¿cómo es la cotización ahí?

00:41:13.420 --> 00:41:17.220
O lo más cotizado es un perfil abierto

00:41:18.340 --> 00:41:24.000
Javi, no creo que sea tanto el motor no
creo que haya y el ganar más sea por el motor,

00:41:24.080 --> 00:41:26.240
creo que es más por la
experiencia, fíjate.

00:41:26.280 --> 00:41:32.240
O sea, yo creo que cuando una empresa está
dispuesta a pagar más por ti, es porque está

00:41:32.240 --> 00:41:35.518
pagando, que eres un experto,
que vas a resolver problemas,

00:41:36.220 --> 00:41:40.140
y cuando no pueden pagar tanto, o no quieren
pagar tanto, o no necesitan lo que sea,

00:41:40.180 --> 00:41:43.940
contratan un junior, una persona para
empezar a aprender, pero del motor que necesiten,

00:41:43.980 --> 00:41:46.660
no es que si es, sabes, Oracle, creo yo.

00:41:46.660 --> 00:41:52.520
Crees que va a la par y las diferencias
van por la experiencia yo creo que sí, que se

00:41:52.520 --> 00:41:57.560
pagan bien por la experiencia, porque al
final un experto te soluciona muchas papeletas,

00:41:57.560 --> 00:42:04.580
pero por el motor no creo
que bueno, y ya ahora ya te

00:42:04.580 --> 00:42:08.160
digo, ¿para cuándo tus
cursos de Mungo publicados?

00:42:09.240 --> 00:42:13.100
Pues Espero que para pronto y además

00:42:14.960 --> 00:42:22.080
Sabes que lo quiero publicar en tu plataforma
de formación en Café Database Mi casa

00:42:22.080 --> 00:42:28.880
es tu casa Loles, mi casa es tu casa Sí,
sí, lo grabaré Me apetece mucho la verdad y

00:42:28.880 --> 00:42:34.420
sacar un curso que lo tengas ahí que lo
pueda disfrutar, que lo necesite y sí, sí, lo

00:42:34.420 --> 00:42:40.600
haremos, lo sacaremos Está muy bien, muy
bien ¿Y cuánta formación se necesitaría por

00:42:40.600 --> 00:42:45.600
hacer un poco lo que sería el mapa de
estudios que la persona tendría que hacer para

00:42:45.600 --> 00:42:50.280
administrar Mongo. O sea, si por ejemplo
en Oracle tú tienes administración, backup,

00:42:50.500 --> 00:42:56.780
tuning, alta disponibilidad o
configuración, digamos, entornos Linux o desalaciones y

00:42:56.780 --> 00:43:02.280
eso, y optimización, que sería el currículum
un poco que seríamos para Oracle, ¿cuál

00:43:02.280 --> 00:43:06.990
seguiríamos para Mongo? Pues yo lo tengo
por aquí en el índice, te podría decir.

00:43:07.470 --> 00:43:09.350
Por encima, ¿eh? Un poco para...

00:43:10.370 --> 00:43:14.950
Hablaríamos de la filosofía, un poco las
características principales de Mongo, una introducción,

00:43:14.990 --> 00:43:20.770
conocer un poco la empresa, la plataforma,
las opciones que hay de software, porque ya

00:43:20.770 --> 00:43:23.310
he dicho que tiene una versión community
que es gratuita, pero tiene una versión también

00:43:23.350 --> 00:43:26.090
enterprise, tiene la
versión de Mongo Atlas, las

00:43:29.320 --> 00:43:37.960
Temas De Las

00:43:37.960 --> 00:43:44.970
acciones, De las clases Cruz, que

00:43:47.020 --> 00:43:54.100
Te he contado. Hablaron de
Sardin y básicamente eso sería a

00:43:54.100 --> 00:43:55.520
lo mejor como los temas más principales.

00:43:55.560 --> 00:43:57.560
De todo eso se hablaría en un curso.

00:43:57.800 --> 00:44:05.060
Un añito, lo que yo le dediqué con sus
prácticas, con tus laboratorios y tus ejercicios.

00:44:05.060 --> 00:44:13.180
Y a lo mejor podríamos hacer cosas en
la plataforma de Oracle Cloud Entiendo

00:44:13.180 --> 00:44:17.980
que se pueden montar mongos en la opción
de Oracle Ya que Oracle está diciendo que en

00:44:17.980 --> 00:44:25.260
el cloud va a tener cabida Que en AWS se
puede instalar un Oracle Y que en Azure también

00:44:25.260 --> 00:44:32.800
Es posible que a lo mejor podamos tener un
proyecto conjunto Combinando un Oracle conectado

00:44:32.800 --> 00:44:36.320
con un mongo en cloud y usarlo.

00:44:36.400 --> 00:44:40.940
Pues claro que sí mi casa es tu
casa y mi OCI es tu OCI también.

00:44:41.940 --> 00:44:48.960
Como EIS nos dan una pasta para utilizar
en OCI pues cuando tú quieras solo tienes

00:44:48.960 --> 00:44:54.540
que decirme Javier, venga,
vamos a meternos en harina.

00:44:55.140 --> 00:44:59.240
Lo tendré en cuenta a mí esas cosas de
experimentar siempre me han gustado.

00:44:59.280 --> 00:45:03.200
Muy bien los que estáis en la audiencia,
si queréis, podéis participar.

00:45:03.240 --> 00:45:09.800
No solo estamos aparte que estamos un café,
ya me he acabado el mío si tenéis alguna

00:45:09.800 --> 00:45:14.960
pregunta, nos queréis preguntar algo es un
café entre amigos al que estáis invitados

00:45:14.960 --> 00:45:19.170
pero podéis participar si queréis si no

00:45:20.690 --> 00:45:26.770
Poco más poco más, yo ya he hablado
contigo todo lo que quería hablar muchas ganas de

00:45:26.770 --> 00:45:33.430
ver esta parte de lo que te decía de
Oracle funcionando en 23 ahí con toda esa integración

00:45:33.430 --> 00:45:40.530
de Jason y la conectividad con
Mongo ver las dos cosas porque

00:45:40.530 --> 00:45:43.419
puede ser muy interesante
fíjate, yo estaba pensando

00:45:43.530 --> 00:45:49.630
Oracle debería funcionar para estar a la
altura con estas Duality Views, debería estar

00:45:49.630 --> 00:45:56.230
funcionando a la misma altura, digamos en
rendimiento que una base de datos Mongo servida

00:45:56.230 --> 00:46:02.510
en remoto Con lo cual ahí se pueden
hacer experimentos interesantes ¿no?

00:46:02.610 --> 00:46:10.050
¿te imaginas? Una query optimizada por
Oracle utilizando el modelo de JSON y

00:46:10.050 --> 00:46:12.370
otra con eso que dices tú de Mongo.

00:46:12.450 --> 00:46:14.283
De comparativas, ¿no? Ahí, a ver.

00:46:14.790 --> 00:46:18.930
Exacto, porque fíjate, incluso en Oracle
conectado con otro Oracle, cuando tienes bases

00:46:18.970 --> 00:46:25.410
de datos distribuidas y tienes que jugar
un poco con quién es él, cuál es la base de

00:46:25.410 --> 00:46:30.530
datos que se encarga de la optimización,
con el GIMP de Drive Insight, es decir, si soy

00:46:30.530 --> 00:46:35.770
la principal y te pido unas tablas, quiero
que esta parte, la optimización la haga yo

00:46:35.770 --> 00:46:37.010
y tú me pasas las tablas.

00:46:37.050 --> 00:46:43.090
O quiero que la optimización se haga en la
base de datos remota y después el resultado

00:46:43.090 --> 00:46:48.790
vuelva a la principal. Esos juegos así, es
súper interesante si cruza relacional con

00:46:48.790 --> 00:46:51.010
documental. Hombre, si consigue eso

00:46:53.390 --> 00:46:59.190
Sería un gran logro y un éxito para ellos
eso sí que te lo reconozco Eso estaría bien

00:46:59.190 --> 00:47:01.634
Es verdad que ahora
mismo, sobre todo porque

00:47:02.390 --> 00:47:06.150
Cambiar y migrar y todo eso para las
empresas es mucho más costoso, pero si le das lo

00:47:06.190 --> 00:47:11.660
que necesitan en la actualidad, integrado
con lo que ya tienen pues es claro que no hay

00:47:11.660 --> 00:47:14.470
color Es una jugada, ¿eh?

00:47:14.590 --> 00:47:17.550
Y ver también en qué va
fino y en qué va cojo

00:47:19.330 --> 00:47:25.890
Ambos en qué ganan unos en qué ganan otros
no porque al final al final dices si quieres

00:47:25.890 --> 00:47:32.190
montar esta esta solución así esa pues la
mejor opción es esto para poderlo de un zapato

00:47:32.190 --> 00:47:36.910
pues oye pues a lo mejor es mira no es que
si solamente vas a almacenar documentos vámonos

00:47:36.950 --> 00:47:43.750
a mongo si vas a tener algo híbrido quizá
ahora que esa solución si es solamente porque

00:47:43.750 --> 00:47:49.270
quieres una capa de por por encima, no sé,
incluso a lo mejor entiendo que Postgres también

00:47:49.270 --> 00:47:55.530
tendrá conectividad con Mongo Postgres nos
estamos metiendo porque como tú también eres

00:47:57.750 --> 00:48:02.430
¿Sabes que no lo sé? Si Postgres tiene
conectividad con Mongo actualmente, no estoy puesta

00:48:02.470 --> 00:48:06.530
todavía, no me he puesto a investigar
sobre eso Podría ser interesante

00:48:08.910 --> 00:48:12.750
Ver ahí Hermana ¿Cómo sería?

00:48:14.670 --> 00:48:21.910
Hermandades, hermanamiento entre motores
puede ser una cosa chula pues oye

00:48:21.910 --> 00:48:29.850
Loles muchísimas gracias por tomarte un
café conmigo por abrir la temporada y mi

00:48:29.850 --> 00:48:35.850
casa es tu casa que lo
sepas un placer pues sí

00:48:36.940 --> 00:48:44.290
hasta la próxima nos Despedimos ya

00:48:44.290 --> 00:48:48.050
son las 8 en Madrid Madrid.

00:48:48.050 --> 00:48:50.661
Hemos adelantado, retrasado
un poquito la hora.

00:48:51.990 --> 00:48:55.657
A ti un abrazo y un abrazo a todos
los que estáis escuchando esto.

00:48:55.750 --> 00:49:00.570
Y si lo estás escuchando en el podcast
porque está grabado, pues que sepas que a la próxima

00:49:00.610 --> 00:49:03.590
para participar, pues en
directo puedes participar.

00:49:05.580 --> 00:49:07.580
Y nada uy, se me había entrecortado.

00:49:07.620 --> 00:49:09.380
A ti también te he entrecortado a veces.

00:49:09.420 --> 00:49:11.200
Sí, un ratito te he entrecortado.

00:49:11.240 --> 00:49:13.480
Por eso no sabía cuándo si
te están despidiendo ya.

00:49:13.520 --> 00:49:15.780
Es que no sé si soy yo o eres tú.

00:49:15.900 --> 00:49:20.040
Eso no lo sé son las horas
son las horas, sí, sí

00:49:21.060 --> 00:49:27.380
oye, pues un placer Loles, un placer el
placer es mío, Javi, que te siga yendo muy bien,

00:49:27.460 --> 00:49:29.620
que enseguida te dan noticias mías ahí.

00:49:29.660 --> 00:49:35.240
Y contigo, y contigo vamos a hacer, venga,
vamos a montar cursos de Mongo también en

00:49:35.240 --> 00:49:42.080
la academia en la base, claro que sí claro
que sí, vamos a abrirlo a otros motores, como

00:49:42.080 --> 00:49:47.480
ahora que se abre a otras clouds, pues
nosotros también vamos a abrirnos a a otros motores,

00:49:47.560 --> 00:49:54.660
claro que sí por supuesto
un abrazo Javi chao

00:49:54.660 --> 00:49:55.640
hasta pronto