Is this the future of MySQL? 🤯

[@paolobooker4163]

Factura: 1000 USD (es un proyecto "hola mundo")

[@lluismf]

Eso para un join de 2 tablas.

[@antoniovm7116]

Exactamente

[@moisesalbertotorres3318]

El precio de uso del S3 es relativamente barato, 0.023USD por GB sin contar que cuentas con diferentes tipos de Buckets que se ajusten a tu demanda. Si tienes un acceso poco frecuente a ese Bucket, puede costar hasta 0.004USD * GB almacenado, sin mencionar los otros beneficios mencionados. Pero bueno...no te dejes guiar por comentarios que tal vez hayas leído en otros lados, si sabes trabajar y DIMENSIONAR proyectos en AWS, pues te sorprendería lo que te puedes ahorrar

[@victorjre]

@@moisesalbertotorres3318 Y las opciones S3 compatible que te permiten tener un bucket S3 en tu propio hw. Separar storage de computing puede ser una estrategia ganadora.

[@chimacamara8005]

Esto en el mudo de la ingeniería del dato es muy común. Me alegro de que divulgues sobre ello!

[@oscarberganzac]

Almacenar los datos en otra unidad, es algo que siempre se ha hecho. DBMS de mysql se ejecuta en un disco y en otra unidad ssd. Esto lleva años haciendose de manera local.

[@gatomulticolor9577]

Me recuerda a "AWS Athena" que usa "AWS S3" como almacenamiento (csv, json, parquet) y Athena hace las consultas SQL sobre esos datos en S3 con un Workgroup.

[@barrenaedu]

exacto

[@VelikaGaming]

Justo ahora ando aprendiendo AWS y sus diferentes servicios, la verdad son demasiados que por ahora estoy muy confundido jeje

[@barrenaedu]

@@VelikaGaming Lleva meses, tranquilidad. Soy SAAC-03 certified, te recomiendo los tutoriales de skillbuilder y leer en lo posible siempre de la documentacion de AWS. Se moderniza muy rapido el cloud y lo que leas por la web puede ser ya viejo.

[@lluismf]

Pero todo esta en la nube. Los accesos del motor de BD al storage son locales. No hay RPC, ni latencia.

[@gonzalo8459]

@@barrenaedu SAAC... en fin

[@miguelangeldeblas9013]

El cloud está bien para proyectos piloto y para proyectos pequeños. Dicho por gente que se dedica al almacenamiento/computación en la nube (NTT), si tienes una app que deba escalar mucho, mucho y que mueva mucho datos, lo mejor es montarte tu el sistema porque en la nube es carisimo. Puedes crear tu infraestructura como siempre con los costes que eso conlleva o si no quieres infraestructura puedes usa housing. La nube esta pensada para que entrar sea muy fácil pero salir sea muy difícil y caro. La telaraña la llaman.

[@ProfeQuiceno]

Gracias por compartir esa experiencia. ❤

[@synux3970]

@@miguelangeldeblas9013 Lo que te venden es escalabilidad global y ahorro pero solo lo primero es verdad, lo que haces es pagar más por la comodidad que ofrecen estos servicios y administrarlos, cosas útiles para aplicaciones ya creadas tipo Netflix.

[@MrOlaffPopov]

Estoy de acuerdo contigo y a la vez no. Como persona que se dedica al cloud, al final cualquier tecnología tiene su contraparte. El cloud es caro, si, pero te ofrece la abstracción a la hora de hacer mantenimiento, a la hora de actualizar tecnologías, te permite una escalabilidad extremadamente rápida, pero te pide trabajar en otras cosas claro. Me acuerdo un proyecto de una migración de un datalake a aws creo que era, y claro, las queries tardaban muchísimo. Tirando del hilo, negocio nos dijo que esas queries se hicieron hace 6 años y que como funcionaban en on premise que así se quedaban, sin actualizar índices ni nada. Mi punto es, creo que tiene más beneficios que cosas malas, pero te obliga a realizar un trabajo correcto por detrás, no todo vale o claro, al final se acaba pagando mas

[@paolobooker4163]

@@MrOlaffPopov Esa "ventaja" no sirve para el proyecto que el comentario menciona

[@plasmodiun1]

@@MrOlaffPopov Claro no es lo mismo tener el servidor en tu casa y que pete porque se te va la electricidad, a tener tu server en la nube ;v

[@lorenzogrv]

Gracias por divulgar crack, ni me enteré de esto si no es por ti Muy elocuente la explicación, me encanta cuando cualquiera explica algo nuevo aún sin conocerlo en profundidad, especialmente si dibuja mientras habla. Te pongo un pero imho: mezclar la arch del Sistema con la arch del software es inevitable (trabajan juntas) pero hablar de ambas como si fueran lo mismo es sobresimplificar: la teoría y la práctica no son lo mismo. Por lo que entendí de lo que explicas y sin ir a las fuentes parece que lo que haríamos es mover la responsabilidad de almacenar, a coste de complejidad, a beneficio de encapsular la posibilidad de escalar el almacenamiento de forma independiente. Muy interesante imho "Más barato que un rds sin ningún tipo de duda": yo, sin hacer los números, ni me atrevería a afirmarlo. Ahí 0% deacuerdo 😂 "Infinito" te lo compro como sinónimo de "es muy difícil llenarlo" 😅 Hasta ahí mi puntillismo, me moló el vídeo y me apeteció comentar mi opinión aunque pocas veces lo haga. Keep up the good work 👍🏼

[@leandrosys89]

Solo por claridad, no deberían usar el servicio de one zone de S3 porque solo usa una zona de disponibilidad y por lo tanto no va tener alta disponibilidad, es más barato, creo que lo que se refería era transfer acceleration que usaría los edge location para entregar el contenido más rápido, pero tiene más sentido para descarga archivos desde el cliente final. Sin embargo, tenerlo en s3 puede usar aws backup para manejar la replication entre regiones para estrategias de disaster recovery

[@weengineers5999]

Me imagino que allí el precio ya es diferente

[@willianmonoga5527]

En mi empresa ya hacemos esto de una forma diferente a través de kubernetes. Hacemos que se levanten tantos pods como sean necesarios y montamos un disco de baja latencia de azure en el directorio de los datos.

[@rumpelstiltskin08]

Me asusta que empiece a tener sentido, por que se puede volver la opción por defecto y siempre vamos a depender de las big tech aun para proyectos pequeños

[@Fran-kc2gu]

No, hay varias alternativas de S3 de codigo abierto que puedes hostear por tu cuenta no necesariamente necesitas usar AWS

[@rumpelstiltskin08]

@Fran-kc2gu S3 es un producto. Hay muchas alternativas compatibles con los SDK de S3. Son cosas muy diferentes

[@Jefferson4026]

Nunca va a llegar a ser la opción por defecto porque no todos buscan escalabilidad y menos proyectos pequeños

[@rumpelstiltskin08]

@@Jefferson4026 La palabra nunca en desarrollo de software no existe.

[@antoniolulee]

Puedes empezar en MySQL y migrarlo fácilmente

[@rubenlezameta3729]

Bienvenidos a Ingeniería de datos, ojalá y se hable más seguido estos temas!

[@davidgonzalo4025]

con lo bien que va guardar los datos en un excel, vaya manera de complicarse 😂😂😂😂😂

[@nicolasgonzalezbarrera1374]

@@davidgonzalo4025 csv 🤣

[@danielavila1661]

😂😂😂😂

[@JoseAntonio-jw6ih]

MySQL tiene distintos engines: InnoDB, MyISAM, etc. Supongo que por debajo es un nuevo engine que se basa en S3 para el almacenamiento. Tengo que echarle un vistazo

[@thecloudxperience1977]

Gracias por compartir. En mi opinion no veo la diferencia en el concepto a levantar contenedores de k8s con un pvc. Concretamente AKS con un file storage.

[@barrenaedu]

Redshift (basado en postgre) desde hace tiempo ya hace algo así permitiendo bajar datos a S3 y subirlos desde S3 en caliente desde el cluster. Me parece interesante que expandan los usos de estos artilugios para mejorar la persistencia en general, costos, availability, etc..

[@ansonyrolandomedinabaca8459]

Veo varios problemas al hacer esto y detallo: 1. S3 guarda objetos, por lo que no puedes editar un objeto como tal. Tendrías que leerlo, guardarlo en memoria, editarlo, eliminar el objeto anterior y crear un objeto nuevo modificado. 2. S3 no esta hecho precisamente para ser transaccional como una base de datos sql. Por la complejidad que implica el punto 1. 3. La cantidad de gets y puts que estarías creando seria demasiado, si pensamos que es una db transaccional, lo que los costos se dispararían. 4. Si lo piensas como una capa analítica, mejor usa athena. Quizás sea un ejercicio interesante pero a nivel de costos no lo veo fácilmente escalable.

[@OscarGarciaB]

Está basado en la tecnología que hay detrás de Neon, por lo que solo escala horizontalmente con réplicas de solo lectura. Las escrituras solo pueden realizarse en el nodo primario. La fragmentación es un problema, porque la tecnología usa un modelo en el que las modificaciones e inserciones son siempre información añadida ("copy on write" y "append only"). Para ciertos escenarios puede ser una solución fiable, escalable y predecible, pero para otros escenarios puede no escalar o ni tener gastos y crecimiento predecible.

[@ernestohernandez7700]

En practicidad esta bueno, pero como dices, habrá que pensar en que proyectos si aplica y en que no. Ya que esta el tema de seguridad, costos y beneficios, y con esto de la IA, ahorita los datos son muy valiosos. Al final de cuentas hay balanceadores y no te quitas de encima que la escalabilidad de mysql la tienes que elegir entre vertical u horizontal.

[@JohnnyDeCastro]

El problema de MySQL nunca han sido los datos, tu desde siempre has podido montar un disco en NFS. El problema sigue siendo el mismo, la concurrencia y la posible corrupción de datos. Y en la práctica no sueles elegirlo porque no importa la velocidad y latencia de red, al final nada iguala el acceso a disco nvme por el bus. El problema de crecer horizontalmente en MySQL con un datadir compartido son los bloqueos, la concurrencia y la corrupción de datos, de ahí el control exclusivo del datadir desde su diseño. Si esto lo soluciona de manera transparente vale oro, pero tengo mis reservas, grandes reservas, además que la latencia sigue siendo algo importante, no me creo nada de eso de la velocidad cuando lo compraras con el acceso directo a disco

[@RelatosdeRiqueza]

¿Es este el paso siguiente en la evolución de MySQL? ¡No puedo creer que los datos ya no sean un problema con S3! 📊🔥

[@Sancer_Uriel]

Conclusión Google Cloud se vende muy mal. Cloud SQL ya separa el almacenamiento del computo, te permite escalar hacia arriba el disco duro sin downtime y bajo demanda El computo hace upsize o downsize por debajo de 100ms de downtime. Cloud spanner, BigQuery y BigTable 100% separado sin downtime en ninguna de las dos cosas

[@ninjateriyaki]

Esto ya se usa en la industria. No quiero entrar mucho en detalles, pero en uno de mis clientes montamos FSx y S3 como filesystem para los datos de BBDDs y SAP. La única innovación que veo (que no sé si WeSQL lo hará así) es que el propio motor haga las llamadas al bucket directamente.

[@daep911]

Que interesante perspectiva, ese tipo de cosas es lo que hace que surgan nuevas características e innovaciones, y que haya un progreso en ese u otros campos. Es la puerta de entrada a posibles innovaciones 🎉 así como en su día las bd no sql ; que su concepto ya tiene muchos años, no tuvieron mucha importancia y auge, y en los últimos años sí.

[@jesuslopez6873]

Viva el alcohol

[@kaik3705]

Brutal! Cuéntame más de WeSQL!!!

[@ConcesionarioVirtual]

Hola midu!!! parce nosotros tenemos un CRM en S3 a pelo sin SQL y es muy costoso desarrollar. pero pasa algo increible... "NO SE CAE", aguanta muuuucho, suuuuuuuper barato. antes teníamos un php, mysql y el hosting costaba usd 1000 por cliente, hoy en día tenemos 25 clientes y la factura ronda USD900. más o menos tenemos medido que programar en archivos S3 a pelo nos cuesta casi 10-20 veces en en tiempo de desarrollo pero nos ahorramos mucho en soporte, caidas etc

[@deavi666]

Saludos, USD900 por los 25 clientes o por cada uno?

[@nelsonmendezz_]

Me parece una brillante idea lo bueno es que existen alternativas compatibles a S3 qué si luego quieres migrar es muy fácil como lo puede ser Minio o DigitalOcean Spaces

[@miguelrangel2894]

tuve una idea parecida hace años, para mi base de datos que estaba desarrollando, mas que solo s3 era un conector de fs agnóstico el el cual podrías hacer operaciones de disco con diferentes proveedores, no solo s3

[@konycatstudio9762]

Me vino a la mente la creacion de contenedores en Docker y volumenes

[@kristianpaul7]

Postgresql si puede escalar horizontalmente usando replicacion logica bi-direccional

[@ShellyWiebold-n3f]

Aprecio mucho tus esfuerzos! Tengo una pregunta rápida: Tengo una billetera SafePal con USDT y tengo la frase de recuperación. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). ¿Cómo debo proceder para transferirlos a Binance?

[@LtdJorge]

Esto es lo que hace Neon, más o menos. Y sistemas de base de datos avanzados (como Snowflake o modulares como Apache DataFusion) funcionan exactamente de esa manera.

[@alonso1062]

Donde trabajo, ya usamos S3 y los servicios de AWS para almacenar nuestros datos, archivos, Front-end, Back-end y las base de datos, y si la latencia es un dolor en una conexión de nuestra base datos con un servicio que está en México

[@cdoliveirar]

Subes con costo a S3 y para bajar esa info seguro costará el triple, cuidado con el costo oculto de AWS cuando ya no desees usarlo.

[@sogarapida89]

Pero veo un par de problemas, uno la isolacion, otro que tendras que tener un balanceador donde sepa donde mandar la consulta. Y en tanto a velocidad puede ser mas lenta ya que todo viajara por tcp. Por que dudo que usen el servidor de computo en el mismo donde tendras tu NAS. Pero para probar no esta mal, En su momento supongo que se hallará un nicho para su uso.

[@sebastianRomeroChamo]

Interesante, otro ejemplo IMAP desde hace varios años

[@TheWilfrido]

Y qué hay sobre las bases de datos Cassandra?, que es la que utiliza Discord y también te permite hacer clusters/nodos con replicación automática e incluso crear nuevos nodos automáticamente...

[@javidesarrolloweb]

Siempre con las ultimas noticias un grande, saludos

[@tortugaduelista4913]

Esto existe hace años con SCALITY y vSphere

[@sorecerer]

Lo que viene a ser un volumen distribuido donde estan los filegroups de la BBDD Bien que lo des a conocer

[@andreshernandezgarcia4252]

Buen video estimado @midulive, duda que herramientas usas para dibujar y explicar me interesa mucho

[@TitanTV_ManXD]

@@andreshernandezgarcia4252 Excalidraw

[@nonenone9131]

Esto no tiene ningún sentido, el argumento de base de que el problema es el disco en cada máquina es desconocer por completo la infraestructura empresarial y que para eso existen los SAN. MySQL tiene capacidades múlti master y multi esclavos, eso unido con un SAN escalas hasta donde se te pegue la gana.

[@JorgeDev92]

Multimaster no escala hasta donde te de la gana, el overhead de coordinarse y resolver los conflictos entre ellos crece a medida que conectas nodos, la latencia también es un problema. Se puede mitigar el primer punto configurando una mayoría simple de servidores para hacer ACK (quorum) pero estas sacrificando consistencia, este mecanismo también te puede servir si tienes los servidores en distintas zonas, por ejemplo nosotros tenemos un cluster separado en 3 zonas distintas 2 en España y 1 en Francia, aceptamos ir por confirmaciones parciales y asumimos que puede llegar una inconsistencia eventual, tal vez un pedido se cree mal pero es lo que hay (este peligro aumenta a medida que aumentas el numero de servidores y aumenta la cantidad de concurrencia) para "mitigarlo" otro poco lo que se hace es que las keys autoincrementales esten gestionadas segun el numero de nodos, por ejemplo el servidor 1 en un server de 8 nodos creara la key 1+(8*n) y el 6 la key 6 + (8*n) pero no dejan de ser trucos y parches. Escalar horizontal cualquier bdd es dificil y en el camino tienes que sacrificar cosas, imaginate, tener una aplicacion como podría ser la de un banco que requiere confirmaciones fuertes, entiendo que a lo que se debería aspirar primero que nada es a tener un minimo de redundancia (replicas, shards) pero pienso que lo suyo sería optar a partir de ahi por tener más escalado vertical que otra cosa y de ser necesario, dividiria el cluster de forma lógica en clusters más acotados para poder seguir la misma estrategia. Por ejemplo yo en un ecommerce para servir la parte web necesito (a parte de cosas menores) customers, catalog, carts, orders y order returns (luego por detrás muchisimas mas cosas pero me centro ahora solo en la parte de la web) pero no tengo ninguna necesidad de tener el mega cluster de bdd, puedo tenerlo separado (incluso en distintos motores de bdd, por ejemplo el buscador en elastic, los productos en mongo, los pedidos en mariadb) y luego, por ETL unificarlo todo en un server datawarehouse para sacar informes o hacer consultas más complejas que por el hecho de tener la información dispersa no sería facil (por ejemplo "quiero los clientes profesionales que me han comprado los productos top ventas" ya implica saber que el producto es top venta, que el cliente es del grupo de profesionales y que te ha comprado, cuando son 5 usuarios guay pero cuando tienes millones es una paliza) Ni el escalado horizontal ni el vertical

[@Capocomico]

Seria mas lento que la mda.

[@camilohernandezruiz2776]

No entiendo por qué es tan asombroso ¿no es simple separación de responsabilidades?

[@JorgeDev92]

La magia no existe, yo le veo muchos problemas a "separar las responsabilidades" en una BDD, como minimo la latencia ya veo claramente que va a ser un problema. Osea estas pasando de 0.00001ms de latencia a 1-2ms (o más), parece poca cosa, pero si haces muchas consultas o si estas consultas mueven mucho dato creo que podemos llegar a un absurdo en el que una consulta pase de 50ms a 1 hora solo por esa diferencia de latencia. Yo no se en que caso de uso el disco era un problema trabajo en un ecommerce bastante fuerte y haciendo tareas rutinarias de limpieza/compactación el cluster del ecommerce permance relativamente estable en unos 80GB conservando datos de los ultimos 3 años, está lejos de ser un problema. Estas diferencias en las latencias yo sabes donde lo note? En nuestro ecommerce legacy, era un prestashop, tuneado hasta el cansancio, originalmente tiraba casi 1700 queries una PLP y unas 1600 una PDP, durante casi un año me dedique en exclusiva a optimizar todas las consultas, eliminar todo lo innecesario y consegui reducirla a cerca de 70 queries (esas 70 estan demasiado metidas en el core de prestashop y quitar una sola me podría llevar un mes facilmente), pero lo bueno es que hay nada de latencia y esas 70 queries la mayoría tardan 0.05s incluso desactivando el plan de cache de Mariadb (NO_SQL_CACHE) por lo que va extremadamente bien para lo que es (Prestashop nos podria comprar el proyecto porque literalmente cogimos su mierda y la hicimos escalable nivel ecommerce potente) pero una semana nos tocaron algo en la infrastructura de servidores y añadieron 8ms al balanceador, imperceptible por las alertas que tenemos (nunca le dimos importancia), esas paginas que optimice pasaron a +570ms gratis y algunas paginas que seguian con mucha query que aún no habia tocado, como la página de checkout pasaron a casi 12s más.

[@snithfferx]

Nosotros tenemos algo parecido, la base por un lado y el sistema por otro, pero creo que esta persona está hablando de un ORM o similar verdad es decir, tener algo así como los binarios por un lado y el sistema que administra y distribuye dicha data por otro lado... o no?

[@kamalmajaiti]

Dime que no conoces las cabinas NVMe-oF o NVMe over RDMA que escalan a un rendimiento de 45000 transacciones por segundo en un solo nodo MySQL.

[@ramonborges7367]

midu pero el almacenamiento de myslq no se puede configurar modificando el parameto datadir en el archivo de configuracion y listo?

[@PSnaki]

¿No es lo que hace con mariadb columnstore enterprise edition?

[@octasquare]

Nada nuevo bajo el sol

[@cjnikolah]

Cual es la diferencia con Athena? O Redshift spectrum?

[@octasquare]

que esta es una solución opensource, por no decir casera. pero ya hace rato que se usa S3 para storage en sistemas con mucha data donde necesitas escalar rápidamente (y de forma independiente) la capa de computo. También esta EFS. que funciona con el mysql de toda la vida

[@chpatriots]

midulive Entonces igual me conviene aprender MySQL?

[@kristianpaul7]

s3 cada vez mas esta cerca de ser un filesystem tanto como un object storage, mas aun desde que aws libero un cliente de fuse

[@nandoholgado3050]

Y yo pensando que las grandes empresas ya estarían funcionando así 😅

[@rakysreplays8259]

Esperaré a que lo implementen en SQL Server

[@YosheMusic]

Es igual a los SQLwarehouses de Databricks sin paralelización…

[@marco70183]

No, no es el futuro, se nota el entusiasmo de un front, pero por dios esto no tiene futuro a gran escala, a menos que evolucione a otros conceptos ya s3 el que lo ofrezca, existiendo tantas miles de opciones

[@LtdJorge]

Claro que tiene futuro, si todas las data warehouse para analíticas modernas hacen esto.

[@weengineers5999]

@@LtdJorge Pero no todo debe estar en la nube

[@tianzun_sven]

OSea como un aws lake formation pero con sql?

[@danielcortesb]

Yo pensé que ya se manejaba asi. ¿Por qué no lo hacian si es bastante lógico?

[@mor3588]

TIDB utiliza un sistema muy parecido a ese

[@emil_cd]

No tiene mucho sentido, el problema no es cuántas veces pueda leerse en S3, el problema es cuántas veces puede escribir sin generar un conflicto en las versiones aparte de la latencia. Postgres ya puede utilizar S3 para hacer backups incrementales, periódicos, también se puede restaurar desde el mismo S3 con pgBackRest. Ahora tener todo el storage centralizado también es un antipatron para un cluster donde se busca redundancia de datos. Si tienes un caso de uso intensivo me iría por un clúster, y si es un caso básico con una instancia simple se soluciona. El problema también es exponencial, entre más crezca la base de datos más difícil será manejar esos archivos en S3, ya sea por cantidad o por tamaño. Entonces lo que trataba de solucionar se vuelve el problema principal.

[@marliote]

Tiene razón se bloquea, por eso tiene que ser uno solo, porque siempre el abre los archivos asíno se bloquea por el mismo lo tiene abierto MySQL, además que se rompe sal si no se guarde apropiadamente

[@josephmovil]

Creo que es un ERROR pensar en la NUBE y depender siempre de terceros !!

[@david47rojas60]

Pero seria traer todos los datos desde s3 al servidor de base de datos no? y hacer las operaciones que se hacen en sql

[@ГеннадийОловянников]

Todo va para nube - para el hermano grande, para que metes tus datos en sus manos y el hermano pone precio como le da gana - puede apagar todo negocio tuyo si no le gustas, tambien puede romper todos tus contraseñas con su computacion potente. Y si aparece un SkyNet dentro de esta nube todo mundo sera "descabezado", nada funcionara. Cuidado con esto. No ponga todos huevos en misma canasta

[@carlosamarilla7791]

pagar eternamente a aws, en vez de comprar un disco hdd o ssd, una vez, le veo mas beneficios a tener algo tuyo, en vez de la nube, claro, para replicacion, backup, etc, si lo usaria, si no costara dinero o no lo pagara yo 😅

[@phpsor]

Eso ya existia mas nadie hablala de ello. Hay varios sql techs que usan s3

[@CavalloGuido]

Pero lo de separar el disco ya se puede hacer con AWS EFS.

[@LoboSueltoOK]

No es ninguna genialidad. Cuando necesitas escalar infinitamente cualquier almacenamiento (llámese Base de datos, storage, etc) creas un SAN (Storage Area Network) y lo integras dentro de cada instancia de MySQL con un link virtual, de tal forma que para cada instancia esto es un disco/carpeta, cuando en realidad tienes un array infinito de servidores especializados en almacenamiento. Esta gente quiere venir a reinventar la rueda y hacerse de un renombre, pero todo eso ya está solucionado hace muchos años.

[@fabricianomirandavargas2746]

normalmente las bd que son servicios, los discos estan alojados en un storage, como S3, o Azure Blob Storage, no se que de novedoso tiene esto?

[@majalapatannn]

Idea original? Iceberg Data Catalogs

[@rodrigochaclan8349]

Eso no es lo que hace BigQuery, cloud spanner o AlloyDB!?

[@marcobenvenuto9144]

No tiene sentido separar los datos del motor, pues si al separarlos luego escalas el motor mysql tambien se escalan los datos porque alli van a crearse tambien conexiones, no se puede hacer una base de datos sin datos. es como hacer un frontal para que te lleve a otro frontal que escale y al final llegas a los datos que tambien se tendran que escalar.

[@LtdJorge]

Para nada. Todas las bases de datos de big data modernas tienen separado compute y storage.

[@pichulinojitoojete7387]

Eso es idea es evidente, si quieres escalar un prototipo realizas un codigo modular y no todo en uno.

[@juancarlospava7124]

Hola @midulive me recuerdas el nombre de la herramienta que usaste para hacer el diagrama, Muchas gracias. Saludos...

[@cristiangno]

Excalidraw

[@antoniolulee]

Está bien la idea. Tiene sentido

[@BigluisVargas]

No es lo que se hace ya cuando desplegas bases de datos con kubernetes?

[@carloschamorro6820]

Suena parecido a Apache Iceberg.

[@adrestrada1]

esta basado en la arquitectura de kafka.... ....en realida han convertido muchos servicios basados en la gestion de kafka.....blaaaa no me sorprende!!!!

[@cliffsandwitch]

pfff , eso lo hice hace 3 anios , con mongo y aks con un blobstorage en azure

[@IBMboy]

Latencia S3 de

[@mascachapas92]

mmm si es tan viable entonces, ¿por qué DynamoDB no utiliza S3 como almacenamiento de datos "activos" y deja atrás los SSDs?

[@lluismf]

Porque iria a pedales

[@whilrodfull]

El futuro empresarial o es Azure o AWS o Oracle🥲 suscripción si o sí... MONGO y demás solo serán didáctico? 😢

[@gTosca_666]

6:43 se convierte en un cliente servidor

[@madgamer5317]

Todo muy bonito, pero dile eso a una empresa, que pondrás sus datos en la nube, y te dicen un rotundo NO!!! XD

[@chrismkl9052]

@@madgamer5317 en realidad hay una que otra empresa que sí tienen o están implementando tener sus datos en la nube ojo que no son muchos, pero por el coste puede convencer a uno

[@joaquingse]

Esto no es lo mismo que hacer una bbdd en sql en Azure? Ahi se puede escalar en la nube no?

[@luiggi0925]

En esencia es lo mismo. Pero resulta más barato. Solo pagas por el costo computacional extra. Y el precio de almacenamiento en S3 es muchísimo menor que el costo de nuevas instancias AWS.

[@macstabiloTV]

One Zone no es multi region hasta lo que yo se…

[@NicolasSilvaVasault]

soy yo o esto existe hace rato?

[@Leo-fd2uh]

pero no lo hace snowflake?

[@santosmarte]

Ok, brutal nivel Dios, ahora si le veo un futuro bueno a MySQL

[@luchomizra]

antes por que no?

[@camilocaro6212]

que antes no era lo que era ? o que esperas que tenga una interfaz de lucecitas rgb

[@carlosvillegas33]

Creo que es mejor utilizar vitess

[@jozeues]

parece solo publicidad par amazon 😬😬😬😬😬🤐

[@No_Upstairs_474]

Osea una red local que no es local

[@manuelangelpicalloperez8860]

Pues depende...S3 no deja de estar en la casa de otra persona...si tú solución no chilla por eso pues adelante...

[@AleCuatro]

Está Interesante

[@sergiocarmona6567]

Yo no le veo nada especial esto ya lo hacia hadoop, y algo similar pasa en databricks y snow flake

[@jhonkevinfloresrojas3848]

No es asi como funcionan los archivos delta?

[@JOlivera3760022]

Eso se llama aws athena..

[@yosoyelmatz]

y cuanto cuesta? hehe

[@patriciozapata1047]

athena aws ?

[@mcalister1911Ab]

basicamente esta replicando lo que hace snowflake

[@midulive]

Snowflake lo mencionamos en el vídeo y él mismo en el artículo

[@JorgeDev92]

@@midulive Me has bloqueado algún comentario? No entiendo porque le he explicado con bastante detalle a un compañero unas dudas que tenia sobre usar un cloud privado con hierro propio, exponiendole nuestro caso, que tenemos tanto cloud como cloud privado como directamente servidores hosteados en nuestros almacenes y ahora mi comentario ya no está.

[@danieldiaz2093]

Prefiero seguir teniendo mi esquema en kubernetes con dos o tres replicas y chau

[@Fran-kc2gu]

Esto snowflake lo hace desde 2012, nuevo no es