- Google Cloud afirmó que, manteniendo el precio de Cloud Spanner, aumentó el rendimiento hasta en un 50% y amplió 2.5 veces la capacidad de almacenamiento por nodo, lo que lo deja en la mitad del costo de Amazon DynamoDB para la mayoría de las cargas de trabajo
- Incluso después de la mejora, Spanner mantiene consistencia externa fuerte, latencia de un solo dígito en milisegundos, escalado prácticamente ilimitado y un SLA de disponibilidad de 99.999%
- La capacidad de almacenamiento por nodo aumenta de 4 TB a 10 TB, y los usuarios seguirán pagando solo por el almacenamiento realmente utilizado, sin importar el nuevo límite ampliado
- La actualización se ofrecerá primero en algunas configuraciones de instancias regionales y multirregionales, y el resto de las configuraciones junto con la mejora de almacenamiento se aplicarán en los próximos meses
- Los clientes reciben estas mejoras con las tarifas actuales sin reprovisionamiento, tiempo de inactividad ni acciones por parte del usuario, y pueden iniciar instancias listas para producción desde 65 dólares al mes o usar una prueba gratuita de 90 días
Mejora de precio-rendimiento de Cloud Spanner
- Google Cloud aumenta el rendimiento hasta en un 50% y amplía 2.5 veces la capacidad de almacenamiento por nodo de Cloud Spanner sin cambiar el precio
- Con esta mejora, señaló que Spanner puede usarse a la mitad del costo de Amazon DynamoDB para la mayoría de las cargas de trabajo
- Spanner ofrece en conjunto alto rendimiento, escalado prácticamente ilimitado, latencia de un solo dígito en milisegundos, SLA de disponibilidad de 99.999% y semántica de consistencia externa fuerte
- Se aplicará a todos los clientes de Spanner en los próximos meses, sin necesidad de reprovisionamiento, tiempo de inactividad ni acciones del usuario
Cambios en cómputo y almacenamiento
- En cómputo, el rendimiento mejora un 50%, aumentando la eficiencia de costos tanto en cargas de trabajo relacionales como en cargas de trabajo clave-valor
- En almacenamiento, la capacidad que puede alojar un nodo de Spanner aumenta de 4 TB a 10 TB
- Aunque aumente el límite de capacidad, solo se paga por el almacenamiento realmente utilizado
- Esto da más flexibilidad para optimizar el entorno de Spanner
- Para cargas de trabajo comparables, Spanner ofrece hasta 2 veces más rendimiento de lectura por dólar que Amazon DynamoDB
Características de rendimiento y cargas de trabajo aplicables
- Spanner ofrece latencia predecible de un solo dígito en milisegundos para lecturas y escrituras con consistencia fuerte a través de múltiples zonas de disponibilidad dentro de una misma región
- También ofrece SQL familiar, sin tiempo de inactividad por mantenimiento y un SLA de disponibilidad de 99.999%, por lo que es adecuado no solo para datos relacionales sino también para cargas de trabajo clave-valor orientadas a lectura
- Dentro de Google, Spanner se utiliza en servicios como Ads, Gmail y Photos
- Según la publicación del blog de Prime Day de Amazon, DynamoDB procesa 126 millones de consultas por segundo en su pico
- Spanner, según Google, procesa 3 mil millones de consultas por segundo en su pico y administra más de 12 exabytes de datos
Casos de clientes y calendario de disponibilidad
- Uber afirmó que Spanner es un componente importante para operaciones críticas y que aporta valor en escalabilidad y bajos costos operativos
- Antes de adoptar Spanner, su framework de gestión de datos requería mucha supervisión y esfuerzo operativo, lo que aumentaba la complejidad y el gasto
- Soluciones tradicionales como el sharding y la consistencia eventual eran barreras para la velocidad de desarrollo
- Tras adoptar Spanner, los costos operativos se simplificaron, mejoró la estabilidad y se obtuvo mejor rendimiento y desempeño al mismo precio
- CERC mejora la eficiencia operativa gracias al aumento del rendimiento y de la capacidad de almacenamiento por nodo
- La mejora de precio-rendimiento ya está disponible en algunas configuraciones de instancias regionales y multirregionales, y el resto de las configuraciones se incorporará después
- La mejora de almacenamiento se desplegará durante los próximos meses
- Los usuarios pueden aprovechar la prueba gratuita de 90 días o iniciar una instancia lista para producción desde 65 dólares al mes
1 comentarios
Opiniones de Hacker News
Hace poco migramos la infraestructura de GCP a AWS. Movimos todo: clústeres de Kubernetes, balanceadores de carga, almacenamiento, Lambda, KMS
Google da la sensación de operar su stack tecnológico como una startup que quiere armar currículum, y había demasiadas partes inmaduras, hacks y funciones sin documentar. Al usar GKE, con cada nueva versión y funcionalidad que salía, teníamos que seguir retocando los workarounds críticos que habíamos metido en la infraestructura por defectos del lado de Google
Era como si la mitad del tiempo del equipo de infraestructura se fuera en prepararse para problemas de Google y la otra mitad en el trabajo de infraestructura que originalmente habíamos planeado; no se terminaba nunca. Después de migrar a AWS, la factura de 3 clústeres de Kubernetes quedó en alrededor del 60% de lo que pagábamos en GCP
El soporte de AWS fue increíblemente bueno, y el de Google fue terrible. Un bug que reportamos en 2020 se cerró hace poco como stale sin ninguna acción, con la explicación de que la API había cambiado tanto que ya no tenía sentido. Cada mes, el día de facturación, nos recordaba que le estábamos pagando a desarrolladores que no podían hacer cosas que otras empresas hacen mucho mejor, y no lo extraño para nada
Trabajo en videojuegos en Europa, y cuando estuve en Ubisoft, AWS me dejó una impresión muy mala. Después de pasar a Tencent/Sharkmob, intenté que me gustara AWS porque era el estándar de la industria, pero la mayor parte me parecía basura inconsistente cubierta con funciones Lambda
A esas trampas raras las llamábamos temas de las 3 a. m.. Eran problemas para los que no tienes la capacidad mental a las 3 de la mañana, así que convencí al estudio de pasarse a GCP, y hasta hoy estoy muy agradecido por esa decisión
En cambio Azure, que tiene mucha más cuota que GCP, es terrible y en general es un desastre completo. Aunque pagues soporte, es difícil que te conecten con alguien de ingeniería, y AWS es excelente
Usamos Enterprise Support, así que sus responsables están en nuestros canales de Slack, y los TAM también son buenos. Si necesitamos al responsable de Route53, se agenda una llamada esa misma semana; para una solicitud de funcionalidad de EKS, podemos hablar con un product manager esa misma tarde. Azure es un caos desde la base
Cuando desarrollaba servicios de AWS, atendíamos directamente las llamadas de soporte de clientes, sin intermediarios. Hablábamos de técnico a técnico, a veces hacíamos compromisos con el cliente en el momento, e incluso había clientes que gestionaban nuestro trabajo como si fuera un proyecto
Cuando hablaron con GAE, efectivamente el downtime que habían visto tenía correlación con el downtime de GAE. Durante un tiempo, la disponibilidad de GAE mejoró, pero nosotros ahora también usamos AWS
En cambio, el soporte de GCP es de calificación F, y da la sensación de que casi tienes que suplicar para recibir cualquier nivel de ayuda
La comparación de que “según el blog de Amazon Prime Day, DynamoDB procesa 126 millones de consultas por segundo en el pico. En cambio, Spanner procesa 3.000 millones de consultas por segundo en el pico, más de 20 veces más, y administra más de 12 exabytes de datos” no parece exactamente justa
Los 126 millones de consultas por segundo de Amazon se leen como la carga que los servicios relacionados con Amazon que procesan Prime Day generaron en DynamoDB, no como todo AWS
Una comparación más justa sería que compartieran la carga pico que los servicios de Google generaron en Cloud Spanner, no sumar todos los servicios de Spanner que corren en todo GCP y en infraestructura interna de Google fuera de GCP
Si dijeran que Photos, Gmail y Ads dependen en gran medida de la infraestructura de GCP, sería una señal fuerte de confianza, pero para mí sería información nueva. En particular, en este artículo normalmente dicen “Cloud Spanner”, pero solo cuando hablan de Gmail, Ads y Photos dicen “Spanner”, así que queda confuso si usan la infraestructura de Cloud Spanner o si ejecutan Spanner en su propia infraestructura
En Amazon, prácticamente todos los servicios están construidos sobre AWS, así que parece un claro voto de confianza, pero históricamente tenía la impresión de que GCP se usaba mucho menos en los servicios internos de Google
“DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second.”
Amazon dejó esto muy claro. Si Google usó esa cifra sin ese contexto, es una comparación totalmente ruin y deshonesta. La persona que escribió este artículo parece carecer de honestidad
https://www.youtube.com/watch?v=268jdNwH6AM
En el blog dice: “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” Pero el Spanner interno de Google y GCP Spanner son distintos. Que un servicio de Google use Spanner no significa necesariamente que use GCP
Aun así, según entiendo, Spanner y GCP Spanner se parecen mucho más entre sí que Borg y Kubernetes
Incluso sumando todo el uso de AWS, si el uso propio de Amazon durante Prime Day es de 126 millones de consultas por segundo, es bastante dudoso que DynamoDB supere a Spanner
Si buscas “Database as a Queue”, te das una idea del ambiente. De hecho, en AWS es realmente difícil usar una base de datos relacional, y para que un equipo obtenga una excepción tiene que pasar hasta por aprobación del CEO, lo que demuestra la solidez de DDB
Para muchos proyectos, Postgres sigue siendo más barato que ambos. He usado los dos, pero prefiero por mucho adaptar un proyecto a Postgres/CockroachDB antes que usar Spanner o DynamoDB
Spanner y DynamoDB tienen muchas más trampas, aumentos repentinos de costos, dependencia del proveedor y otros problemas. AWS, GCP, Azure, Oracle Cloud e incluso despliegues basados en operadores de Kubernetes soportan muy bien Postgres, así que simplemente usen Postgres
Si puedes operar Postgres correctamente, obviamente deberías usarlo. Si puedes meter todos tus datos en Postgres en una sola máquina, no hay razón para usar una base de datos de escala global de nivel P
Si estás creando una app de chat con millones de mensajes y casi ninguna “relación”, genuinamente me pregunto si deberías usar Postgres o alguna familia NoSQL
Al lidiar con funciones distribuidas y código desplegado en Lambda, la gestión de conexiones SQL se volvió una pesadilla y empezaron a perderse requests por todos lados
PostgreSQL es excelente, y trabajo en Google, pero estoy 100% de acuerdo. Hasta que deje de alcanzar, simplemente usa PG. Esta discusión recién tiene sentido cuando entras en el terreno de Spanner y DynamoDB
Si algo es totalmente distinto pero un poco más barato, podríamos decir “simplemente usa” cualquier cosa. Por ejemplo, guardar registros como commits en un repositorio de GitHub es gratis y suficientemente barato para proyectos pequeños, pero no es lo mismo
GCP Spanner cuesta “desde 65 dólares al mes”, mientras que el nivel gratuito de AWS ofrece “25 GB de almacenamiento de datos, 2.5 millones de solicitudes de lectura de streams”, entre otras cosas.
https://aws.amazon.com/dynamodb/pricing/
En algún momento las líneas del gráfico se cruzarán, pero el título de Google me parece engañoso.
Salvo con fines educativos, casi no hay motivos para usarlo en un proyecto pequeño; los clientes de Spanner son, por ejemplo, lugares a los que ni CockroachDB les alcanza. Si la base de datos no es tan enorme, PostgreSQL es suficiente.
Hoy en día hay muchas aplicaciones que alcanzan más de 100 millones de usuarios en un mes, así que no estamos hablando de una situación de 50 QPS. Además, omitieron el límite por bytes de DynamoDB. Si te pasas de 1 KB aunque sea por 1 byte, te cobran 2 unidades de lectura.
Decir “Google también debería ofrecer un descuento de entrada” es muy razonable, pero no dice si el producto real es más caro o más barato.
Me gustaría probar Spanner en proyectos personales o side projects, pero una instancia lista para producción empieza en 65 dólares al mes. DynamoDB puede operarse casi a 0 dólares al mes con cobro por solicitud.
Pero el cobro por solicitud también es gratis solo mientras te mantengas dentro del nivel gratuito. Hay que revisar los límites; si los superas, deja de ser gratis.
La arquitectura de CRDB, en esencia, internamente se parece a Spanner.
https://www.cockroachlabs.com/get-started-cockroachdb/
Antes me gustaban bastante los productos de Google, así que tengo sentimientos encontrados. Estoy bastante atado a Gmail y ya corro varias cosas en GCP.
Pero cada vez siento más que Google me ha quemado con cierres repentinos de servicios. Tenía todos mis dominios en Google Domains y estaba contento, pero hace poco lo vendieron de golpe a Squarespace, y no quiero tratar con esa empresa.
Uso Google Pixel y también usaba la app Google Podcasts, pero escuché que también la cerrarán y la trasladarán a YouTube Music. Probé YouTube Music, pero la detesto, así que tengo que buscar una alternativa.
A largo plazo quizá sean servicios menores, pero me inquieta volver a confiarle servicios importantes a Google. Antes de invertir tiempo, termino preguntándome: “¿Qué pasa si algún día Google vende o cierra Cloud Spanner? ¿Me metería en problemas entonces?”
El registro de dominios puede ser un campo minado en términos regulatorios y de reputación, pero otros productos cloud, incluida la distribución de contenido, también lo son. Todavía no creo que muestre un gran patrón de cierres de servicios de Google Cloud, pero al menos se encendió una luz amarilla.
La discontinuación de productos de Google es molesta, pero no tiene relación con los productos y servicios de Google Cloud. Google Cloud tiene clientes de pago, así que no creo que anuncien el cierre de productos y servicios de golpe.
Google Domains es un producto de Google, y el producto equivalente del lado de Google es Google Cloud Domains, ofrecido a clientes de Google Cloud.
“Las organizaciones de todos los tamaños y de todas las industrias tienen una necesidad creciente de acelerar su transformación digital e impulsar la innovación basada en IA”; cómo terminó Google así.
Si Spanner no tiene una versión on-demand que cobre por unidad de trabajo en lugar de por nodo, es difícil compararlo con DynamoDB en muchos casos de uso.
Como el rendimiento promedio es mucho menor que el pico, dudo que se vean ahorros de costo en Spanner.
Eso sí, el desarrollo con Spanner parece mucho más fácil que con DynamoDB.
Google tiene antecedentes de subir drásticamente el costo de sus servicios. El vendor lock-in es peligroso.
Me pregunto si habrá pasado con otros servicios. En los servicios cloud empresariales, donde está muy por detrás de AWS como segundo o tercer lugar, parece mucho menos probable.
Aunque es un ejemplo viejo, conozco un caso en el que bajaron costos: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
Hasta donde sé, AWS, por ejemplo, solo ha bajado precios de servicios.
Si montas una base de datos Postgres en un Droplet, sale casi gratis y el rendimiento también es bastante bueno
Por 65 dólares al mes puedes conseguir un servidor muy potente en Hetzner. Hay que abrirse paso entre esa selva absurda que es el menú de productos cloud, y después de verlo una vez, decidí que era mejor aprender los fundamentos de administración de Linux para usarlos toda la vida.
Comparar Postgres con Spanner es parecido a comparar una van de reparto con un tren. El tren siempre tiene costos fijos más altos.
Administrar Linux es una habilidad útil, pero mi capacidad de administración de Linux no puede competir con la confiabilidad, disponibilidad y escalabilidad de sistemas cloud como Dynamo, S3 o Spanner.
Demasiado tiempo se va en configuraciones y resolución de problemas específicas de cada servicio que no tienen mucho sentido en otros lugares.
Si usas durante un mes 1 GB de almacenamiento, ítems de 1 KB, 100 mil escrituras y 100 mil lecturas, en DynamoDB bajo demanda son 0.39 dólares. Incluso si subes las escrituras y lecturas a 1 millón cada una, son 1.63 dólares. Si usas lecturas con consistencia fuerte, sube a 1.75 dólares, y si además usas escrituras transaccionales, llega a 3.00 dólares.