Google Cloud Spanner agora disponível por metade do preço do Amazon DynamoDB
(cloud.google.com)- O Google Cloud informou que, mantendo o preço do Cloud Spanner, aumentou a taxa de processamento em até 50% e ampliou em 2,5 vezes a capacidade de armazenamento por nó, fazendo com que ele custe metade do Amazon DynamoDB na maioria das cargas de trabalho
- Mesmo após as melhorias, o Spanner mantém forte consistência externa, latência de um dígito em milissegundos, escalabilidade praticamente ilimitada e SLA de disponibilidade de 99,999%
- A capacidade de armazenamento por nó aumenta de 4 TB para 10 TB, e os usuários continuam pagando apenas pelo armazenamento efetivamente utilizado, independentemente do novo limite
- A atualização será disponibilizada primeiro em algumas configurações de instância regionais e multirregionais, com as demais configurações e o upgrade de armazenamento sendo aplicados ao longo dos próximos meses
- Os clientes recebem as melhorias na tarifa atual sem reprovisionamento, indisponibilidade ou ação do usuário, e podem iniciar uma instância pronta para produção a partir de US$ 65 por mês ou usar a avaliação gratuita de 90 dias
Melhoria de desempenho por preço do Cloud Spanner
- O Google Cloud aumentou a taxa de processamento em até 50% e ampliou em 2,5 vezes a capacidade de armazenamento por nó do Cloud Spanner, sem alterar o preço
- Com essa melhoria, a empresa afirma que, na maioria das cargas de trabalho, o Spanner pode ser usado por metade do custo do Amazon DynamoDB
- O Spanner oferece, ao mesmo tempo, alta taxa de processamento, escalabilidade praticamente ilimitada, latência de um dígito em milissegundos, SLA de disponibilidade de 99,999% e semântica de forte consistência externa
- As mudanças serão aplicadas a todos os clientes do Spanner ao longo dos próximos meses, sem necessidade de reprovisionamento, indisponibilidade ou ação do usuário
Mudanças em computação e armazenamento
- No aspecto de computação, a taxa de processamento melhorou 50%, aumentando a eficiência de custo em cargas de trabalho relacionais e de chave-valor
- No aspecto de armazenamento, a capacidade suportada por um único nó do Spanner aumenta de 4 TB para 10 TB
- Mesmo com o aumento do limite de capacidade, o cliente paga apenas pelo armazenamento efetivamente utilizado
- Isso amplia a flexibilidade para otimizar o ambiente do Spanner
- Com base em cargas de trabalho semelhantes, a empresa afirma que o Spanner entrega até 2 vezes mais taxa de leitura por dólar do que o Amazon DynamoDB
Características de desempenho e cargas de trabalho aplicáveis
- O Spanner oferece latência previsível de um dígito em milissegundos para leituras e gravações com forte consistência em várias zonas de disponibilidade dentro da mesma região
- Também oferece SQL familiar, nenhuma indisponibilidade para manutenção, SLA de disponibilidade de 99,999%, sendo adequado não apenas para dados relacionais, mas também para cargas de trabalho de chave-valor centradas em leitura
- Internamente no Google, o Spanner é usado em serviços como Ads, Gmail e Photos
- Segundo a postagem de blog do Prime Day da Amazon, o DynamoDB processa 126 milhões de consultas por segundo no pico
- O Spanner, segundo a empresa, processa 3 bilhões de consultas por segundo no pico e gerencia mais de 12 exabytes de dados
Casos de clientes e cronograma de disponibilização
- A Uber afirmou que o Spanner é um componente importante de operações essenciais, com valor em escalabilidade e baixo custo operacional
- Antes da adoção do Spanner, o framework de gerenciamento de dados exigia muita supervisão e esforço operacional, aumentando a complexidade e os gastos
- Soluções tradicionais como sharding e consistência eventual criavam barreiras para a velocidade de desenvolvimento
- Após a adoção do Spanner, os custos operacionais foram simplificados, a estabilidade melhorou e foi possível obter melhor taxa de processamento e desempenho pelo mesmo preço
- A CERC melhorou a eficiência operacional com o aumento da taxa de processamento e da capacidade de armazenamento por nó
- A melhoria de desempenho por preço está atualmente disponível em algumas configurações de instância regionais e multirregionais, e as demais configurações serão contempladas em seguida
- O upgrade de armazenamento será distribuído ao longo dos próximos meses
- Os usuários podem usar a avaliação gratuita de 90 dias ou iniciar uma instância pronta para produção a partir de US$ 65 por mês
1 comentários
Opiniões no Hacker News
Recentemente migramos a infraestrutura do GCP para a AWS. Transferimos tudo: clusters Kubernetes, balanceadores de carga, armazenamento, Lambda e até KMS
O Google dá a impressão de operar sua stack tecnológica como uma startup querendo montar currículo, com muitas partes imaturas, hacks e recursos sem documentação. Ao usar o GKE, novas versões e funcionalidades continuavam surgindo, e precisávamos ficar refazendo workarounds essenciais que tínhamos colocado na infraestrutura por causa de falhas do lado do Google
O tempo da equipe de infraestrutura acabava sendo metade gasto se preparando para problemas do Google e metade no trabalho de infraestrutura originalmente planejado, sem nunca acabar. Depois da migração para a AWS, a fatura de 3 clusters Kubernetes ficou em cerca de 60% do que era no GCP
O suporte da AWS foi inacreditavelmente bom, e o suporte do Google foi horrível. Um bug que reportei em 2020 foi fechado recentemente como stale sem nenhuma ação, com a justificativa de que a API havia mudado tanto que aquilo já nem fazia sentido. Todo mês, no dia da cobrança, eu era lembrado de que estava pagando desenvolvedores que não conseguiam fazer coisas que outras empresas fazem muito melhor, e não sinto nenhuma saudade disso
Trabalho com videogames na Europa e, quando estava na Ubisoft, a AWS deixou uma impressão muito ruim. Depois que fui para a Tencent/Sharkmob, tentei gostar da AWS por ser o padrão do setor, mas a maior parte parecia um lixo inconsistente coberto por funções Lambda
Chamávamos essas armadilhas estranhas de assuntos das 3 da manhã. Eram problemas para os quais você não tem sanidade mental às 3 da manhã, então convenci o estúdio a migrar para o GCP, e até hoje sou muito grato por essa decisão
Já o Azure, que tem uma participação muito maior que o GCP, é horrível e, no geral, uma bagunça completa. Mesmo pagando por suporte, é difícil conseguir contato com alguém da engenharia, enquanto a AWS é excelente
Usamos Enterprise Support, então os responsáveis entram nos canais do Slack, e os TAMs também são bons. Se precisamos falar com alguém do Route53, uma chamada é marcada naquela semana; para uma solicitação de recurso do EKS, conseguimos conversar com o gerente de produto na mesma tarde. O Azure é uma confusão desde a base
Quando desenvolvia serviços da AWS, eu atendia diretamente as ligações de suporte ao cliente, sem intermediários. Eram conversas diretas entre pessoas técnicas; às vezes fazíamos promessas ao cliente na hora, e havia clientes que praticamente faziam o gerenciamento de projeto do nosso trabalho
Quando eles conversaram com o GAE, viram que o downtime que observavam de fato tinha correlação com o downtime do GAE. Por um tempo, a disponibilidade do GAE melhorou, mas nós também usamos AWS hoje
Por outro lado, o suporte do GCP é nota F, e parece que você precisa praticamente implorar para receber qualquer nível de ajuda
A comparação de que “segundo o blog do Amazon Prime Day, o DynamoDB processa 126 milhões de consultas por segundo no pico. Já o Spanner processa 3 bilhões de consultas por segundo no pico, mais de 20 vezes mais, e gerencia mais de 12 exabytes de dados” não parece exatamente justa
Os 126 milhões de consultas por segundo da Amazon parecem se referir à carga gerada no DynamoDB pelos serviços relacionados à Amazon que processam o Prime Day, não pela AWS inteira
Uma comparação mais justa seria compartilhar o pico de carga gerado pelos serviços do Google no Cloud Spanner, não somar todos os serviços Spanner rodando em toda a GCP e na infraestrutura interna não GCP do Google
Se disserem que Photos, Gmail e Ads dependem bastante da infraestrutura da GCP, isso seria um forte sinal de confiança, mas para mim é uma informação nova. Especialmente porque, neste texto, normalmente se fala em “Cloud Spanner”, mas ao mencionar Gmail, Ads e Photos usa-se apenas “Spanner”, o que deixa confuso se eles usam a infraestrutura do Cloud Spanner ou rodam Spanner em infraestrutura própria
Na Amazon, praticamente todos os serviços são construídos sobre a AWS, então isso parece um voto de confiança claro; já a GCP historicamente me passava a impressão de ser bem menos usada pelos serviços internos do 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.”
A Amazon deixou isso muito claro. Se o Google usou esse número sem esse contexto, é uma comparação totalmente baixa e desonesta. A pessoa que escreveu esse texto parece carecer de honestidade
https://www.youtube.com/watch?v=268jdNwH6AM
O blog diz: “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” Mas o Spanner interno do Google e o Spanner da GCP são distintos. O fato de um serviço do Google usar Spanner não significa necessariamente que ele usa GCP
Ainda assim, pelo que entendo, Spanner e GCP Spanner são muito mais parecidos entre si do que Borg e Kubernetes
Mesmo somando todo o uso da AWS, se o uso próprio da Amazon no Prime Day é de 126 milhões de consultas por segundo, é bastante duvidoso que o DynamoDB supere o Spanner
Pesquise por “Database as a Queue” para sentir o clima. Na verdade, na AWS é realmente difícil usar um banco de dados relacional, e uma equipe precisa até passar por aprovação do CEO para obter uma exceção, o que mostra a solidez do DDB
Para muitos projetos, Postgres ainda é mais barato que os dois. Já usei ambos, mas prefiro muito mais adaptar um projeto ao Postgres/CockroachDB do que usar Spanner ou DynamoDB
Spanner e DynamoDB têm muito mais armadilhas, picos repentinos de custo, lock-in de fornecedor e outros problemas. AWS, GCP, Azure, Oracle Cloud e até implantações baseadas em operadores Kubernetes dão suporte muito bom a Postgres, então é só usar Postgres
Se você consegue operar Postgres corretamente, é claro que deve usá-lo. Se consegue colocar todos os seus dados em um Postgres em uma única máquina, não há motivo para usar um banco de dados de escala global de nível P
Se eu estiver criando um app de chat com milhões de mensagens e quase nenhuma “relação”, fico sinceramente curioso se deveria usar Postgres ou alguma família de NoSQL
Lidando com funções distribuídas e código rodando em Lambda, o gerenciamento de conexões SQL virou um pesadelo, e perdas de requisições começaram a acontecer por toda parte
PostgreSQL é excelente, e, embora eu trabalhe no Google, concordo 100%. Use simplesmente PG até ele não dar mais. Só quando você chega ao território do Spanner e do DynamoDB é que essa discussão passa a fazer sentido
Se bastasse ser algo totalmente diferente, mas um pouco mais barato, daria para dizer “use simplesmente” qualquer coisa. Por exemplo, armazenar registros como commits em um repositório do GitHub é gratuito e barato o suficiente para projetos pequenos, mas não é a mesma coisa
O GCP Spanner custa “a partir de US$ 65 por mês”, enquanto o nível gratuito da AWS oferece “25 GB de armazenamento de dados, 2,5 milhões de solicitações de leitura de streams” etc.
https://aws.amazon.com/dynamodb/pricing/
Em algum momento as linhas do gráfico vão se cruzar, mas o título do Google parece induzir a erro
A menos que seja para fins educacionais, quase não há razão para usá-lo em projetos pequenos; clientes do Spanner são, por exemplo, lugares para os quais nem o CockroachDB é suficiente. Se o banco de dados não for tão gigantesco, PostgreSQL basta
Hoje em dia há muitos aplicativos que chegam a mais de 100 milhões de usuários em um mês, então não é uma situação de lidar com 50 QPS. Além disso, deixaram de fora o limite de bytes do DynamoDB. Se passar de 1 KB por apenas 1 byte, são cobradas 2 unidades de leitura
Dizer que “o Google também deveria oferecer um desconto de entrada” é muito razoável, mas isso não diz se o produto real é mais caro ou mais barato
Eu gostaria de brincar com o Spanner em um projeto pessoal ou paralelo, mas uma instância pronta para produção começa em US$ 65 por mês. O DynamoDB pode ser operado por praticamente US$ 0 por mês com cobrança por requisição
Mas a cobrança por requisição também só é gratuita enquanto você ficar dentro do nível gratuito. É preciso verificar os limites; se passar deles, deixa de ser gratuito
A arquitetura do CRDB, em essência, é internamente próxima do Spanner
https://www.cockroachlabs.com/get-started-cockroachdb/
Antigamente eu gostava bastante dos produtos do Google, então fico dividido. Estou bem preso ao Gmail e já rodo várias coisas no GCP
Mas também sinto que estou ficando cada vez mais queimado pelo fato de o Google encerrar serviços de repente. Eu tinha todos os meus domínios no Google Domains e estava tudo indo bem, mas recentemente ele foi vendido de repente para a Squarespace, e não quero fazer negócio com essa empresa
Uso um Google Pixel e também usava o app Google Podcasts, mas ouvi dizer que ele também será encerrado e migrado para o YouTube Music. Experimentei o YouTube Music, mas detestei de verdade, então preciso encontrar uma alternativa
No longo prazo, podem ser serviços menores, mas fico inseguro de confiar novamente serviços importantes ao Google. Antes de investir tempo, acabo perguntando: “e se um dia o Google vender ou encerrar o Cloud Spanner? Eu ficaria em apuros?”
Registro de domínios pode ser um campo minado em termos de regulamentação e reputação, mas outros produtos de nuvem, incluindo distribuição de conteúdo, também são. Ainda não acho que isso mostre um grande padrão de encerramento de serviços do Google Cloud, mas pelo menos acendeu uma luz amarela
O fim de produtos do Google é irritante, mas não tem relação com produtos e serviços do Google Cloud. O Google Cloud tem clientes pagantes, então não acredito que vá anunciar de repente o encerramento de produtos e serviços
Google Domains é um produto do Google, e o produto correspondente do lado do Google é o Google Cloud Domains, oferecido a clientes do Google Cloud
“Organizações de todos os portes e de todos os setores têm uma demanda crescente para acelerar a transformação digital e impulsionar a inovação baseada em IA”; como foi que o Google chegou a esse ponto?
Se o Spanner não tiver uma versão sob demanda que cobre por unidade de trabalho em vez de por nó, fica difícil compará-lo ao DynamoDB em muitos casos de uso
Como a vazão média é muito menor que o pico, tenho dúvidas se seria possível ver economia de custos no Spanner
Por outro lado, acho que o desenvolvimento no Spanner seria muito mais fácil do que no DynamoDB
O Google tem histórico de aumentar drasticamente o custo de serviços. Dependência de fornecedor é perigosa
Fico curioso se aconteceu em outros serviços. Em serviços de nuvem corporativa, onde está bem atrás da AWS, em segundo ou terceiro lugar, isso parece muito menos provável
Embora seja um exemplo antigo, conheço um caso em que reduziram custos: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
Até onde sei, a AWS, por exemplo, só reduziu preços de serviços
Se você colocar um banco Postgres em um Droplet, sai praticamente de graça e o desempenho também é bem bom
Com US$ 65 por mês, dá para conseguir um servidor muito potente na Hetzner. É preciso atravessar a selva insana que é o menu de produtos de nuvem, e, depois de olhar uma vez, concluí que seria melhor aprender o básico de administração Linux e usar isso pelo resto da vida
Comparar Postgres com Spanner é parecido com comparar uma van de entregas com um trem. O trem sempre tem um custo fixo mais alto
Administração Linux é uma habilidade útil, mas minha capacidade de administrar Linux não consegue competir com a confiabilidade, disponibilidade e escalabilidade de sistemas de nuvem como Dynamo, S3 e Spanner
Tempo demais é gasto em configurações e troubleshooting específicos de cada serviço, que não têm muito significado em outros lugares
Usando por um mês 1 GB de armazenamento, itens de 1 KB, 100 mil gravações e 100 mil leituras, sai US$ 0,39 no DynamoDB sob demanda. Mesmo aumentando gravações e leituras para 1 milhão cada, fica US$ 1,63. Com leituras de consistência forte, vai para US$ 1,75; se usar também gravações transacionais, chega a US$ 3,00