Episode Transcript
[00:00:01] Speaker A: Hola a todos y bienvenidos a un nuevo episodio de nuestro podcast Finos Más que Costes. Hoy es un tema interesante porque quizá tratemos uno de los temas que más quebraderos de cabezas dan en algunos casos, que son las bases de datos. Entonces hoy tenemos a una experta en ello, Felicia Lobillo. ¿Qué tal Felicia? ¿Cómo estás?
[00:00:23] Speaker B: Hola, muy buenas. ¿Qué tal?
[00:00:27] Speaker A: Muchas gracias por estar ahí con nosotros. Felicia es una especialista en bases de datos en Azure y trabaja en Microsoft, así que tenemos a alguien muy potente para analizarnos cómo gestionar todo el tema de costes y base de datos en la nube.
Por supuesto tenemos a nuestro presentador, Damián. Damián, ¿Qué tal? ¿Cómo estás hoy?
Así que adelante.
Genial. Pues bueno, como sabemos que eres toda una pro con el tema de las bases de datos y estamos viendo, sobre todo en la parte española, que tenemos mucha migración todavía por hacer o en proceso de hacerse y que todavía no sabemos en algunos casos cómo medir los costes y cómo tenerlos controlados.
¿Cómo estás viendo tú que los clientes lo están haciendo para controlar ese tipo de costes? ¿Y si tienes algún tipo de recomendación a la hora de tener esos costes, sobre todo en base de datos bajo control?
[00:01:39] Speaker B: Pues a ver, yo la experiencia que tengo a lo largo de mi vida profesional y cuando empezamos sobre todo a trabajar con el cloud, es que había y todavía hay un poco de inquietud los clientes porque no tienen del todo claro cuánto se van a gastar y eso es muy preocupante cuando tienes que tener un presupuesto, entonces se suelen hacer presupuestos excesivos.
Entonces yo creo que también hace falta un poco de experiencia. Una vez al principio no sabes nada, luego ya vas adquiriendo un poco más de experiencia. Pero básicamente yo creo que hay que controlar los gastos monitorizando constantemente tu base de datos. Sobre todo hay ciertos productos que son más sensibles, por ejemplo, una base de Datos como Cosmos DV en Azure, que es Pay as you go Puro, ¿No? Es un flat fee, un pago constante fijo a lo largo del mes. En ese tipo de productos es importante que controles muy bien qué es lo que está pasando, que observes tu base de datos y luego el año siguiente, en el siguiente periodo, pues vas ajustando y vas haciendo un conocimiento continuo y una mejora continua. Yo tenía un profesor cuando estudié que se llama Jorge Chávez, que nos explicaba la realimentación negativa y nos reíamos mucho. Pero es verdad, es eso. Tú pones la ducha a tope de caliente, te quemas y luego lo pasas a tope a la izquierda, te muerde frío, luego pasas un poco sin el bajo y ya tengo una temperatura que es la temperatura adecuada. Pues yo creo que pasa un poco eso. Tú tienes que. Empiezas, dices, venga, voy a hacer un presupuesto. Luego vas ajustando porque ves que no hacía falta tanto.
Luego también hay muchas herramientas que se pueden utilizar en todos los proveedores de clan, solo en Azure hay herramientas para limitar el uso. Puedes tener alarma, el Advisor que te va diciendo cosas que puedes ir haciendo, sobre todo en una base de datos, por ejemplo, como Cosmos.
Luego también una cosa que creo súper importante es acudir a tu proveedor de cloud, en este caso yo hago sesiones de optimización o de mejores prácticas constantemente con clientes para que ellos comprendan cómo funciona una base de datos como esta. Porque no es lo mismo utilizar una base de datos, como decía antes, con un flat fino, con un coste fijo al mes, que una sensible.
Tienes que conocer un poco cómo funciona la tecnología. No digo que tengas que ser un experto en la tecnología, pero tienes que conocer un poco intrínguli para saber sacarle el máximo partido. Y eso es algo que te puede proporcionar tu proveedor. Y yo me dedico a eso, hago muchísimas sesiones de mejores prácticas con los clientes. ¿Por qué? Porque en una base de datos como esta, sobre todo en las tecnologías nuevas, NoSQL, cuando venimos del mundo de base de datos relacionales, y todavía se utilizan las bases de datos relacionales, pero normalmente lo que hacemos es, tenemos un modelo de datos, diseñamos el modelo de datos en plan cartesiano y ahí ese modelo de datos se utiliza para 50 aplicaciones. Las aplicaciones se adaptan al modelo de datos. Puedo tener tres aplicaciones que corren encima del mismo modelo, pero no SQL, es al revés. En NoSQL tú tienes que saber cómo es tu aplicación y vas a tener un modelo de datos específico que se ajusta perfectamente a tu aplicación para tener la mínima latencia, las máximas prestaciones.
Entonces es muy importante que conozcas cómo funciona y sobre todo porque en una base de datos como Cosmos el rendimiento y el coste van juntos. Tendrás muy buen rendimiento y el coste será muy bajo.
Lo contrario es si la tienes mal configurada, tardará mucho y te costará mucho más, entonces por eso es muy importante conocerlo. Luego también hay astucias que los clientes pueden utilizar en todos los proveedores de cloud, casi todos los productos hay una versión gratuita que se puede utilizar para probar o para entornos de desarrollo, algunos son más o menos generosos, pero hay free tier de la base de datos. También tienes, por ejemplo en el caso de Cosmos tienes un emulador local que puedes utilizar para ir diseñando tu modelo de datos sin incurrir en costes, tienes también reservas, en fin, hay muchas herramientas para controlar tu coste y alcanzar ese nivel de crucero.
[00:06:03] Speaker A: Sí, ese nivel estable cuando ni te quemas ni te mueres de. Vamos a decir de lo que has hablado un poco. Yo la verdad es que sí que tuve bastante experiencia con el tema de la NoSQL y con aplicaciones que me hicieron optimizar bastante tanto el coste como el performance. ¿Y qué tips ves un poco en ese tipo de bases de datos que pueden ser útiles para el cliente que pueda optimizar y jugar un poco ahí en la línea del coste y la performance tipo? Pues no sé, yo me acuerdo de. Yo sufría mucho con los index, tenía que hacer index para todo, para que todo fuera bien, pero claro luego el index se me iba a cosas muy largas, tenía que cuadrar perfectamente las las keys. ¿Cómo juegas tú con eso?
[00:06:53] Speaker B: Verás, yo creo que uno de los aspectos más importantes de Cosmos DV es que proporciona la capacidad que tú provisionas en Cosmos y provisiones capacidad, puedes usar serverless, pero si provisionas capacidad la vas a tener con un SLA, o sea, tú dices necesito tantas unidades de petición que son los request unit y la vas a tener con SLA. Entonces hay varias maneras de configurar esa capacidad que necesitas, puede ser una capacidad plana, eso se llama el throughput, el throughput en la cadencia de operaciones puedes configurar un throughput que se llama manual, pero en el fondo lo que es siempre el mismo, yo tengo intervalos pero no tengo picos y pago por lo que provisiono, entonces tiene que ajustarse completamente a cómo es el perfil de tu aplicación. Si tu aplicación tiene un workload, una carga de trabajo que muy muy previsible, pues este tipo de trupo te viene muy bien porque pagas el consumo requestioning, la unidad de consumo en Cosmos, es decir, cómo utilizar la base de datos en factura por cómo utilizar la base de datos aparte del almacenamiento, si tienes trupus manual, el coste de la RU es el nominal, es el básico, pero claro, cuando no estás utilizando la aplicación o tienes un pico o no tienes un pico, quiero decir, tienes un baño de operación, estás pagando lo que has provisionado, entonces tienes que saber si tu aplica va a tener una carga de trabajo de este tipo o no. Hay otra opción que es hacer auto scale.
El 80% de las cargas de trabajo que yo veo se ajustan mucho mejor a tu escale, donde el coste de la RU es un poco mayor, pero tienes un máximo de tu provisional y al final vas a pagar por lo que consumes. Entonces si tú tienes un pico de vez en cuando, pero no todo el tiempo, tienes una carga de trabajo que no es previsible. Auto Scale funciona muchísimo mejor. Es que te puede salir hasta 80% más barato porque al final estás pagando por lo que usas.
Entonces esto es una de las cosas que los clientes tienen realmente que entender, que no todo es Trupus manual. Trupus manual, imagina si yo tengo un campo de sensores iot que están constantemente mandando datos constantemente, entonces tengo Trupus manual porque siempre es el mismo workload, yo lo conozco, entonces pago por lo que provisiono, pero lo que provisiono es lo que utilizo.
Pero como digo, luego viene un Black Friday en retail por ejemplo, que hay, no sé, en banca que siempre hay picos que no sé cuándo van a venir o sé cuándo van a venir, pero simplemente no quiero estar pagando lo que provisiona. Pues autoescale muchísimo mejor.
Luego también es muy importante como tú decías, la indexación y sobre todo el modelado de datos y el particionamiento, porque Cosmos Divi es una tecnología distribuida, es una base de datos distribuida que distribuye los datos a lo largo de varias, varias particiones. Por ejemplo, yo soy un cliente de un operador de telco, por ejemplo, y todo lo que yo produzco, mis llamadas, mis facturas, todo va a estar almacenado junto, eso es una partición utilizando un identificador, por ejemplo, el número de teléfono, el NIF, lo que sea, lo tuyo va a estar en otra partición y luego todo esto se organiza en nodos. Entonces esa clave de particionamiento que utilizo es fundamental porque cuando accedo a los datos y hago una query para sacar los datos, voy a utilizar esa clave de particionamiento para ir directamente donde está, sacarlo todo un plumazo que eso por eso es tan rápido, pero también lo que es más importante es que esa query, esa clave de particionamiento se utiliza para enrutar la llamada al nodo donde está la información, entonces es muy importante que tú sepas cómo vas a acceder a los datos, por eso decía que tiene que estar completamente a medida de la aplicación, si yo voy a entrar en la aplicación por número de teléfono, tendré que tener una clave de particionamiento de número de teléfono, por un ejemplo fácil tienes que entender el particionamiento porque el particionamiento es lo que hace que Cosmos tenga un SLA de throughput, un SLA de latencia, tiene unos SLA impresionantes precisamente porque tiene estas particiones y estas claves de particionamiento. Además de la clave de particionamiento la indexación también es crucial, porque la indexación hace que dentro de una partición tú encuentres los datos de manera más rápida, pero claro, hay una indexación por defecto que es todos los campos, todas las propiedades, el nombre, el apellido, todo va a estar indexado. Claro, llega un momento que no me conviene tener todo indexado por dos razones, la primera es porque los campos que realmente no estoy utilizando cada vez que escribo, porque las bases de datos también tienen inserts y updates, tú escribes en la base de datos, cada vez que tú escribes estás recalculando índice, está consumiendo recursos para hacer esta escritura, entonces las escrituras son más pesadas cuando tengo más intersección, entonces al final lo ideal es que restrinjan la indexación a los campos que utilizas en tus cláusulas WHERE y GROUPBY y ya está, lo demás lo quitas, porque incluso aunque tu información fuera tan estática que hace diez años no la cambias y que es una cosa completamente escrita en piedra, ¿Para qué vas a estar pagando el almacenamiento de la indexación si no lo estás utilizando, o sea que son dos razones por las que la indexación también hay que revisarla?
También a la hora de cambiar el throughput, si yo tengo un throughput y pongo otro, pues hay que tener también cuidado porque Cosmos hace, como decía, tiene particiones y estas particiones pueden cambiar dependiendo del volumen de datos, si tengo más volumen de datos, pues Cosmos va sacando particiones para tener las particiones tamaño relativamente razonable, porque eso es como los bolsos de las mujeres, si el bolso es muy grande no encuentras nada, si el bolso es pequeñín encuentras cosas enseguida En Cosmos las particiones tienen que tener un tamaño relativamente raso, pan, no pequeño, el tamaño adecuado para que pueda garantizar. Por eso tiene SLA.
Entonces, cuando el volumen aumenta, a veces Cosmos tiene que sacar nuevas particiones. Y cuando tengo más trupu, también tiene que sacar más particiones para que entre todas me den el truco que yo necesito. Pero tampoco el Trupus no es un juguete. Tú no puedes subir el Truput. Voy a subir el truput a 200.000 rus. ¿Por qué? Porque eso va a generar un montón de particiones. Ya sabemos todos que por la ley de entropía cuesta mucho más trabajo meter la pasta en el tubo que sacarla.
Recoger particiones es algo que se puede hacer. Hay una funcionalidad para eso que es el merge, pero no todas las colecciones van a poder perder, no todas las particiones lo van a soportar. Entonces, bueno, ¿Que hay que tener? Hay que tener eso también pendiente en la mente. Luego también hay una cosa que en Cosmos sirve para reducir costes, que es la cacha integrada.
De una cacha integrada donde tú tienes query muy repetitiva, dame esto, dame esto, siempre la misma query, la misma query. En vez de ir al backend a las particiones y consumir R, puedes tener una caché. Tú calculas cuántas peticiones necesitas de ese tipo, cuántas rus te cuesta, calculas el volumen de datos que tienes que almacenar y te haces el caso de negocios, si te conviene o no tenerla. Pero puede reducir todavía más la latencia.
Cosmos tiene una latencia, tiene un SLA de latencia de lecturas puntuales, que es un tipo de lectura concreto. No es una query de 10 ms siempre. Normalmente cuando la utilizas bien son menos de 100 ms siempre.
Lo que decía, que con la caché, por ejemplo, se puede llegar a tres, cuatro milisegundos. Pero bueno, sobre todo porque no estás incurriendo en consumo de RUS.
Y luego una cosa que es súper importante, y esto lo digo siempre en las sesiones de Best Practices, que los datos que están en una base de datos NoSQL, en general, las bases de datos operacionales no son almacenes de base de datos Persecula secular. Tú tienes que tener un ciclo de vida del dato definido y tienes que almacenar datos calientes en esa base de datos. Y tienes que decir, pues no sé, lo que necesite dos años, un año o lo que sea, pero no puedes tener los datos. Lo puedes tener, pero ¿Para qué los vas a tener? Tienes que ir desde el principio teniendo una estrategia de archivado del dato, llevándolo a otro tipo de almacenamiento que sea más barato, pues un blog o yo que sé.
Entonces, eso hace, si tú lo haces desde el principio, al usuario de negocio, que es el que quiere esos datos, son sus datos. Al usuario de negocio tú le estás diciendo, mira, los datos los tienes aquí, pero cada mes yo te voy a ir, o cada dos años, y tú le vas enseñando desde principio al usuario que tiene los datos en otro sitio, pero que los tiene, que no los pierde. ¿Qué pasa si no lo haces? Cuando pasen cinco años, dile tú al usuario de negocio que vas a archivar datos, no lo va a conseguir, no te va a dejar, porque no sabe, no se fía. Claro. ¿Dónde me vas a poner los datos van a estar accesibles? Entonces, una cosa que hay que también educar al usuario de negocios de principio, con esto que os digo del ciclo de vida del dato, porque las bases de datos funcionan mejor cuando son más ligeras. Si tengo 10 años de datos, pues Cosmos te va a dar el SLA igual, pero te va a costar más.
[00:16:15] Speaker A: Totalmente. Y no me quiero imaginar una base de datos con 10 años de actividad, de sensores, de cualquier cosa del año 2012, a saber cuántas queries puede haber ahí, de coches o de no sé, o plaquitas de cualquier tipo de sensor. Tiene que ser una locura, la verdad, lo que te puedes encontrar ahí si no archivas datos.
Estuvimos hablando, no dije muchos tips.
[00:16:48] Speaker B: Y.
[00:16:48] Speaker A: También hablaste mucho de herramientas y cómo, o sea, el tema de visualizar un poco con Phoenix y la gente de Buscan, siempre visualizamos, tienes una herramienta.
[00:17:05] Speaker B: Bueno, en el portal de Azure tú tienes para monitorizar tu base de datos, tienes las métricas y puedes sacar, por ejemplo, tienes gráficas, hay un montón de herramientas para visualizar todas las métricas que la base de datos expone dentro de una. Por ejemplo, que es súper interesante, es, imagina, yo he aprovisionado un throughput, yo he dicho, quiero que mi base de datos tenga tantos throughput, 80.000 rus al segundo, 80.000 peticiones por segundo.
Es súper importante poder ver si las estoy utilizando o no, en qué medida las estoy utilizando.
Me explico. Si las estoy utilizando a lo largo del mes, que es cuando se emite la factura cada hora, se calcula la factura y luego hay meses emite. Entonces, si yo durante el mes estoy utilizando mucho ese throughput que he provisionado, quiere decir que mi aplicación es muy previsible, estoy utilizando más o menos lo que he provisionado. Entonces, esa métrica que se llama el consumo de Reu normalizado, se ve perfectamente. Tú lo puedes calcular a la hora, durante una granularidad de una hora a lo largo de un mes.
Si tú ves que ese grupo que has provisionado no lo estás usando ni siquiera la mitad del tiempo, es que tu workflow no es previsible, es que tienes arriba, tienes abajo. Entonces, en ese caso te deberías ir a manual, perdón, deberías ir a auto scale. Esto es algo que tú puedes ver con las métricas, pero también en Azure el Advisor te dice si una tabla, que en Cosmos DB se llama containers, si un container tiene pinta de que va a estar mejor en auto scale o en manual, te dice. Entonces está muy bien que tú revises todos tus mensajes del Advisor y que lo compruebes. Tampoco puedes, eso no va a misa, no puedes tomar papel juntilla y hacerlo, pero sí deberías revisarlo y para eso te sirve el monitor. Y luego hay otra cosa, esto ya es súper técnico, es.
Puedes registrar, cuando tienes necesidad de observar la base de datos de manera más profunda, pues se puede activar los diagnostic logs de Azure. Entonces vas a tener una información muy, muy, muy detallada sobre la operación en la base de datos. Luego puedes hacer queries con el lenguaje Custo SQL Language, que es como un SQL así un poco alemán. Entonces haces eso y lo activas una semana o dos, porque eso cuesta, también tiene un precio activar los logs, etc. Los almacena durante dos semanas, los observas y cuando ya tienes claro qué es lo que está pasando, puedes ver las queries que consumen más. Puedes hacer en la documentación de Azure hay un montón de ejemplos de queries que se pueden utilizar. Esto ya no es tan visual, pero no deja de ser Finox. Al final lo que tienes que hacer es un informe y enseñárselo a la gente de Finox, que no sea tan técnico, pero es que es bastante técnico esa parte, muy técnica.
Y luego también tienes en el SDK de Cosmos también puedes activar la métrica de índices para que te recomiende si lo deberías usar o no lo deberías usar, etc. Yo creo que, por ejemplo, en cuanto a índices, un buen dato es cuánto ocupa el índice con respecto a los datos reales. Y si es más de un 10% a lo mejor lo deberías revisar por lo que decíamos antes, porque la escritura se hace mucho más pesada. Yo creo que esos 10% es el valor más lógico, más recomendable.
[00:20:48] Speaker A: Súper interesante. Y al final yo también he visto, bueno, sobre todo cuando me preparé el tema de los exámenes y demás, el tema de las queries y los logs. Al final eso es algo que casi se puede extrapolar a cualquier provider, que el tema de ver unos log analytics, activarlos y poder entrar ahí. Luego a partir de los logs puedes jugar con las métricas en base a logs, que eso es súper interesante para alertas y demás. Es algo súper interesante. Sí que es verdad que siempre hay que tener en cuenta el coste y el ciclo de vida de los logs y cuánto tiempo los conservas y cuántos insertas y demás. Porque yo el otro día tuve un error que saltaba ahí un 503 cada 0,5 segundos y tuve que decir. Y de repente al día siguiente vi un pico ahí que dije, ¿Qué está pasando? Y veía log storage ahí a tope y dije, pero estamos metiendo un log aquí cada, no sé, cada cinco segundos.
[00:21:42] Speaker B: Digo, no puede ser activarlo eso durante un periodo de tiempo, eso dos semanas, hasta que tú ya hayas analizado qué es lo que pasa, luego ya lo desactivas y ya corriges lo que sea y ya está.
No es algo que se deba tener activo todo el tiempo para qué. Es un montón de información.
[00:21:58] Speaker A: No, no, hay que tener cuidado con eso. En World los críticas y hace falta. Sí, pero hay que ser consecuente con.
[00:22:08] Speaker B: Otra cosa que también, perdón, pensando que también recomiendo, es que a veces cuando venimos de una migración, es una migración de datos que están on premise y los voy a llevar Cosmos DB, por ejemplo, normalmente los clientes tienen una ventana para migrar esos datos.
Bueno, lo puede hacer de mil maneras, pero imagínate, es un tera de datos y los tienes que cargar. Entonces tú provisionas un throughput en la base de datos. Entonces vas a ir cargando, consumiendo esas rus por segundo. Cuantas más ponga, más capacidad tendrás de escritura. Entonces tú dices, bueno, pues voy a provisionar un montón de reus para que me tarde muy poco, porque cuanto más R tienes, más rápida será la carga, hasta que eso genera un montón de particiones y el día de mañana, cuando tú ya has terminado tu carga, que te has tardado tres horas, imagínate con 5.500 millones de rus y de repente tienes que pasar al régimen permanente, donde ya las Rus que necesita son 30.000, pues tienes un montón de particiones, ha fragmentado todo y ahora 30.000 se van a dividir entre todas las particiones. Entonces cada una va a haber muy poco.
Es algo que yo tengo una hoja extra, una herramienta para ayudar a los clientes a decidir cuánto voy a poner para mi carga inicial. Al final tenga una carga inicial con una duración razonable y aceptable por negocio, pero que no fragmente demasiado la base de datos.
Aunque como digo, hay un merge que se puede utilizar. Pero bueno, yo creo que es algo, y esto también lo veo mucho, yo.
[00:23:56] Speaker A: Creo que sobre todo si alguien, no sé si alguien ha tenido experiencia de hacer un sharding en manual o gestionado por uno mismo y con un open source y demás por su cuenta, que creo que sabe perfectamente que hacerlo luego otra vez para atrás y todo el proceso que ello conlleva, es.
[00:24:21] Speaker B: Mucho más difícil.
[00:24:24] Speaker A: Ya hacer el sardin y que todo vaya bien a nivel, vamos a decir, más rudimentario.
Es algo difícil y es algo que bueno, tiene su historia y que funcione bien. Luego, evidentemente no todo lo que está automatizado y demás, pero es una cosa compleja.
Revertirlo ya puede ser el caos más absoluto de que vaya todo bien, aunque evidentemente está todo súper, súper controlado. Y bueno, yo quería, porque ya que vemos que eres toda una máster en Cosmos y en todo el tema de Azure y demás, y bueno, sabemos que eres cinturón negro en una Black Belt. Absolutamente, yo soy cinturón naranja, pero eso es de otras cosas.
Quería saber un poco cómo ha sido tu camino para masterizar todo el tema, qué competencias has tenido que pasar, cómo se consiguió un poco ese tema y.
[00:25:27] Speaker B: Cuéntanos en qué consiste. Pues verás, yo además tengo un perfil un poco claro, porque vengo de toda la vida de integración de sistemas. Estuve muchísimos años en una compañía que hace dos y algo me viene aquí. Y francamente, cuando yo vine a Microsoft, Cosmos, Quingen, por ejemplo, sabía.
Bueno, es que lo que sabía era ridículo, sabía muy poco. ¿Pero sabes qué ha pasado? Que la documentación es muy buena, que he aprendido muchísimo en reuniones con clientes, me he pegado mucho con la base de datos y he aprendido mucho de mis compañeros que han sido muy generosos también, me han ayudado muchísimo, he hecho muchísimas presentaciones para recoger el conocimiento y tener saco mi tomo de conocimiento y al final lo he asentado y lo he.
Lo he digerido, es mucha información, Yo no soy DBA, yo no tengo perfil de DBA, no soy tampoco desarrolladora, entonces bueno, pues he tenido que estudiar mucho, pero la verdad es que he tenido tiempo para estudiar y le he echado muchas ganas porque la verdad que me parece un tema muy bonito y sobre todo porque CosmoDB es una base de datos que no se parece a ninguna cosa que yo haya visto antes y la verdad que es muy bonito, no solamente el logo, que no sé si lo habéis visto y está chulo, eso es lo que le digo yo también a los jinetes de broma, les digo, oye, ¿Por qué no ponéis cosas arquitectura que te va a quedar súper bonita, no? Pero es una base de datos muy buena, muy buena, una maravilla, tecnología muy puntera, nació creo que fue en 2015, o sea que es muy reciente, todo esto es muy nuevo.
Pues así lo he hecho, leyendo mucho y estudiando mucho. Y luego también hay una certificación, la DP, que bueno, para alguien como yo que no desarrolla, pues me costó también mi ratito.
[00:27:36] Speaker A: Al final cuesta para todo el mundo.
[00:27:43] Speaker B: ¿No? No, llegas ahí, tienes un Learning pad, o sea, si tú vas a la documentación de Cosmos, tienes un learning pad con un montón de módulos que está muy bien para ir aprendiendo.
También está muy bien utilizarla, por ejemplo, si no quieres ir a la nube directamente, puedes utilizar el emulator, el emulador, que lo instalas en local, esta es una aplicación que tienes aquí en local y vas aprendiendo los conceptos.
Y luego, bueno, yo también porque soy, como decía, soy Black Belt, Global Black Belt, entonces tengo acceso al grupo de producto también, que es, pues digamos, donde se cuece todo esto, son los que lo han desarrollado y los que van evolucionando el producto, entonces es apasionante oírles hablar de cómo funciona, cómo ver el tapiz del revés, es muy chulo, eso también es un sitio privilegiado para mí. Pero bueno, generar el Learning Path es muy potente, yo lo he seguido, lo he hecho varias veces, cuando necesito algo estoy constantemente con la documentación, pasando página buscando lo que necesito.
[00:28:54] Speaker A: Sí, yo, vamos, recuerdo que al final era un sistema bastante útil, además en la última actualización del tema de las certificaciones lo metieron para que se pudiera usar durante el examen, lo cual cuando, o sea, yo llegué al examen, me acuerdo y no sabía que esto pasaba y mitad del examen me dijo ¿Puedes mirar la documentación?
Y en plan, digo, dije, ¿Este botón qué es en el ordenador del examen? Me dice, no, si es la documentación, Digo, ah, que se puede mirar la documentación.
Ah, bueno, ya está, entonces ya está aprobado el examen, no pasa nada, porque yo llevaba todo el entrenamiento con exámenes y demás, pero sobre todo mirando la documentación para las dudas y tal, está bastante bien, ¿No?
[00:29:37] Speaker B: Ahora está la cosa más seria enormes, pero ahora lo que sí hay es que la documentación se actualiza por la documentación y en la certificación se basan sobre, sabéis que CornosDB tiene varias APIs, pero la API de base, la core, que es la NoSQL, antes se llamaba SQL, ahora se llama NoSQL, bueno, esa es la de base para la certificación.
Y ahora yo sé que ha renovado el contenido de Learning Path, porque claro, la base de datos está en continua evolución. Ahora hay otro tipo nuevo de auto scale que es más económico todavía, que se llama Dynamic Auto scale. Luego tienes capacidades, todas las bases de datos de Azure y en concreto Cosmos también, tienen capacidades nativas de búsqueda para poder implementar aplicaciones de nueva generación basadas en G, o tienen capacidades vectoriales, tienen capacidades de búsqueda de texto. Entonces todo esto no estaba en la documentación anterior.
Yo no sé si esto ya está incluido, pero si no está incluido se va a incluir en breve, porque las bases de datos ahora tienen muchísimas más funcionalidad todas de lo que se venía teniendo.
[00:30:58] Speaker A: Al final es un poco eso, que vaya evolucionando y ver cómo se mueve.
Y bueno, ya que has mencionado todo brevemente, el tema de la IA y demás, ahora que ya sabemos todo el rollo que está ahora otro día con todo el tema Deepsea que reventó el mercado y demás, bueno, sabemos que Microsoft ha hecho inversiones muy potentes en empresas de IA, en su propio desarrollo de IA, el Copilot está en absolutamente en todos los lados. ¿Cómo está afectando eso también un poco a los clientes que estás viendo tú y en tu caso en el tema de Cosmos, con el tema de los datos? Y sobre todo por quizá más lo orienta más a la pregunta de, vamos a decir, el Retrieval, el rack, el aumento del contexto para los modelos de IA usando Cosmos quizá puede ser algo interesante.
[00:31:54] Speaker B: Sí, bueno, la apuesta ahora mismo, hasta ahora ha sido siempre Azure OpenAI y está basado, pero por supuesto que Microsoft trabaja con todos los modelos, incluido Deepsea.
Cosmos está muy vinculado con la IA, porque Cosmos, por ejemplo, es la base de datos donde se almacena todas las conversaciones, ChatGPT, todas van a Cosmo.
Esto irá evolucionando, no sé cuál es la postura que vamos a tener futuro, pero yo creo que desde mi punto de vista, la aparición de 15, bueno, cuando todo el tema de la seguridad esté completamente claro y se pueda utilizar con toda la seguridad, a mí me parece que es una buena noticia, porque si tú.
Si vamos a tener aplicaciones inteligentes, cuanto más eficiente sea mejor, o sea, que es una cosa que creo que va a aportar, es una buena noticia.
[00:32:59] Speaker A: El tema de la eficiencia ha sido quizá lo más bueno, aparte de las connotaciones políticas y geopolíticas que tiene todo el tema de la eficiencia es algo que a mí sinceramente me sorprende bastante.
Me gustaría ver cómo se desarrolla y cómo se hacen las métricas una vez que esté todo más asentado y que con sus visiones seguía, porque la verdad es que ha sido algo bastante sorprendente y que hay que ver cómo han sacado esa diferenciación con respecto sobre todo a tantos módulos. Es decir, aunque Todos conocemos tema OpenAI, pero bueno, tanto los modelos de Google como los modelos de Antropic, como los Mistral y demás, más o menos se mueven en unos rangos similares y de repente es verdad que llega esta nueva EA.
[00:33:48] Speaker B: Habrá que estudiarlo, habrá que ver cómo es y habrá que utilizar tecnología que sea completamente eficiente.
[00:34:01] Speaker A: Bueno, y es muy positivo para el ecosistema. Yo creo que al final tener una referencia, que haya un nuevo salto, que se vea una nueva capacidad ahora de eficiencia, puede reducir costes, que es al final lo más importante, porque al final todo este tema está incrementando mucho el coste y el gasto en la nube de recursos y demás, y ver cómo eso se puede optimizar para poder darle aún más carga y poder mejorar. Y lo que has mencionado es muy interesante, lo del tema de las conversaciones, que ya sabemos dónde se almacena, sí.
[00:34:34] Speaker B: Se almacenan en Cosmos, y de hecho Cosmos es una base de datos muy.
Yo lo veo mucho, muchísimas de las aplicaciones que se están desarrollando con genial conversacionales. Las conversaciones se almacenan en Cosmos por varias razones. Una es porque tú quieres tener tu historial de conversaciones, puedes analizar lo que los clientes han ido diciendo, etc. Eso te sirve para hacer analítica, luego recuperarlas, porque también mejora la experiencia de usuario, ver cuáles son las últimas conversaciones que he ido teniendo, los clientes quieren ver eso.
Y también porque tú puedes utilizar estas conversaciones, si tú las vectorizas, puedes utilizar la base de datos como un caché semántico. Entonces cuando hay una nueva pregunta, en vez de ir otra vez a chat GPT o Azure OpenAI a preguntar, tú a los tokens, simplemente nos vas a servir la respuesta desde la base de datos, porque ya se ha hecho la misma pregunta antes, se parece muchísimo una que han hecho antes. Entonces eso abarata también el coste y lo hace muy eficiente.
[00:35:39] Speaker A: Sobre todo para la gente que. Bueno, simplemente por aclarar, por si hay gente que no está familiarizado, el tema de. Al final todo el tema de la IA y el contexto que se le da a la IA desde aplicaciones externas o documentación externa, parte de la base de vectorizar la información de texto, que no se lee de texto puro y BAS, sino que todo se vectoriza, se tokeniza y se hace vectores, para que cuando haces la query a la base de datos, ese vector, digamos que lo que entra se vuelve a vectorizar, se compara la distancia de vectores, esto igual es más técnico, y vuelves con el contexto más cercano lo más rápido posible.
Entonces, al final, toda la vectorización lo que te permite es, uno, es un almacenamiento súper eficiente, si alguien ha hecho cualquier cosa con vectores en un país, en Python y demás, todo el análisis de datos se relaciona con vectores y distancias entre ellos.
Y dos, te permite comprimir muchísimo la información, porque si metieras texto ahí en el campo text, nos podríamos morir, uno, de eficiencia y dos, de.
De la cantidad de cosas que devuelve la base de datos. Es algo súper interesante.
[00:37:01] Speaker B: Y también es muy interesante tener la vectorización en la propia base de datos, como puedes hacer con Cosmos, porque los datos operacionales suelen ser muy dinámicos. Entra nueva llamada, una nueva queja, no sé cuál, tiene una nueva transacción, lo que sea.
Eso, si esos datos los quieres vectorizar, sabes que las bases de datos tienen esta capacidad de change data capture, o sea que son capaces de detectar cambios en los datos. Y esto lo puedes utilizar para automatizar un proceso, por ejemplo para ir a buscar los vectores para el nuevo dato que tengo, cuando hay un update o lo que sea, tenerlo ya en la misma base de datos, pues una cosa que simplifica la arquitectura, lo hace muy eficiente y para qué te vas a llevar los índices a otro sitio si los puedes tener en la propia base de datos, los índices para buscar tu vectorización y todo eso está muy bien, eso es algo que está muy de moda ahora.
[00:38:00] Speaker A: Al final es aplicaciones inteligentes, todo el mundo, todo el mundo quiere meter, al final es la clave y yo creo que en business, y tú probablemente lo sepas más, dar el contexto, al final la mayoría de aplicaciones van a ser un modelo de IA con el contexto del negocio embebido en algún punto, yo creo que el 90% va a ir sobre todo a eso, es decir, coges el contexto de tu negocio, se lo embebes a la IA y ando evidentemente con las capacidades va a ser eso y va a ser el 90 % de todo lo que vamos a ver a nivel negocio.
[00:38:37] Speaker B: Incluso mira, he visto también casos en los que imagina, tú tienes tus datos operacionales y cuando pones inteligencia artificial encima de los datos operacionales puedes conseguir que te los enriquezca, por ejemplo, qué sé yo, un ejemplo, una receta de cocina y tú pones los ingredientes y luego pones las instrucciones y si te ha faltado la sal, pero en las instrucciones si la sal, pues la IA lo va a añadir, añade la sal y las instrucciones cuando te lo enseñan, pero yo no lo tengo en la base de datos, lo va a dar la IA, entonces puedes aumentar tus datos y puedes enriquecerlos, es algo que es muy potente o también tú puedes jugar con qué grado de libertad tiene el aplicarse sobre restringe al JSON que tienes y no salga del guión, pero si le das libertad puedes enriquecer los datos y tener tus datos aumentados, digamos.
[00:39:34] Speaker A: Súper.
Y una cosa que quería preguntarle, que solemos preguntar a la gente un poco ahora que estamos ya llevamos un poco más de año, que está siendo bastante intensito, pero ¿Cómo ves que va evolucionando el tema en este caso de las bases de datos y en tu caso más concretamente Cosmos, ¿Cómo ves que puede ir evolucionando? ¿Hacia dónde se puede ir moviendo?
¿Cómo lo ves tú en 2025?
[00:40:02] Speaker B: Yo lo que veo es que hay mucha base de datos, muchas tecnologías.
En Cosmos por ejemplo estamos haciendo también un poco de racionalización porque hay muchas APIs y hay que simplificar un poco la base de datos. Todas están teniendo ya capacidades de búsqueda vectorial, capacidades de búsqueda híbrida, capacidad de búsqueda de texto. Todas las bases de datos tienen esto ya de serie y la que no lo tiene lo va a tener en breve.
Todas lo tienen que tener porque ya es una cosa, una commodity ya eso hay que tenerlos. Y también hay una tendencia que es por ejemplo la base de datos SQL de Azure ahora se pueden utilizar en SaaS en nuestro producto Fabric, entonces SQL es la primera, pero luego van todas las demás. Cosmos también se ofrecerá como SaaS, entonces ya será muchísimo más fácil incluso utilizar una base de datos de este tipo, que es que realmente vas a desplegar en un segundo y no vas a tener prácticamente que ocuparte de ella porque será SaaS y no PAS. Entonces eso es algo que también está evolucionando en el portfolio no te sé decir si todo va a ser SaaS.
Yo veo que hay una tendencia al SAF también para facilitarlo porque hay clientes prefieren esas, Tiene que haber de todo.
[00:41:30] Speaker A: Yo me piqué un DAS, nosotros llamamos el DAS, el Data Visa Service y si eso no lo tengo que volver a picar sería un detalle porque ahí hubo mucho, recuerdo que mucho recurso invertido y mucho esfuerzo y mucho trabajo de entender cómo podemos hacer un DAS en cierta tecnología. Entonces si ya el proveedor de nube ya te da el DAS hecho con los datos y que ya sólo sea hacer, vamos a decir, el modelo de datos en caso de SQL o en NoSQL, bueno, también un modelo de datos pero tenerlo distinto será un detalle.
Así que bueno, pues esperando eso con muchas ganas, la verdad creo que ha sido muy interesante, creo que hay muchísimos tips, no sé si nos va tiempo a hacer todos los shorts y todos los clips que deberíamos hacer con todos los tips que nos has dado y nada, felicidades y un placer tenerte hoy.
[00:42:39] Speaker B: El placer ha sido, muchísimas gracias.
Hasta pronto entonces.
[00:42:45] Speaker A: Hablamos y nos vemos en el siguiente episodio.
[00:42:47] Speaker B: Muy bien, adiós.
[00:42:50] Speaker A: Chao, chao.
