Get best of the week

Google Cloud Spanner: bom, ruim, mau

Olá, Habrovsk. Tradicionalmente, continuamos a compartilhar material interessante em antecipação ao lançamento de novos cursos. Hoje, especialmente para você, publicamos um artigo sobre o Google Cloud Spanner, programado para coincidir com o lançamento do curso da AWS para desenvolvedores .



Originalmente publicado no blog Lightspeed HQ .

Como uma empresa que oferece muitas soluções de PDV baseadas na nuvem para varejistas, restauradores e varejistas on-line em todo o mundo, a Lightspeed usa vários tipos diferentes de plataformas de banco de dados para uma variedade de casos transacionais, analíticos e de pesquisa. Cada uma dessas plataformas de banco de dados tem suas próprias forças e fraquezas. Consequentemente, quando o Google lançou o Cloud Spanner no mercado, recursos promissores sem precedentes no mundo dos bancos de dados relacionais, como escalabilidade horizontal praticamente ilimitada e um SLA (99,999% de nível de serviço), - não poderíamos perder a oportunidade de colocá-lo em nossas mãos!

Para fornecer uma visão geral abrangente de nossa experiência com o Cloud Spanner, bem como os critérios de avaliação que usamos, abordaremos os seguintes tópicos:

  1. Nossos critérios de avaliação
  2. Chave inglesa da nuvem em poucas palavras
  3. Nossa classificação
  4. Nossas descobertas



1. Nossos critérios de avaliação


Antes de nos aprofundarmos nos recursos do Cloud Spanner, suas semelhanças e diferenças com outras soluções no mercado, vamos falar primeiro dos principais casos de usuários que tínhamos em mente ao considerar onde implantar o Cloud Spanner em nossa infraestrutura:

  • Como substituto da solução de banco de dados SQL tradicional (predominante)
  • Como uma solução OLTP com suporte a OLAP

Nota: Para simplificar e facilitar a comparação, este artigo compara o Cloud Spanner com a família de soluções MySQL GCP Cloud SQL e Amazon AWS RDS.

Usando o Cloud Spanner como um substituto para uma solução tradicional de banco de dados SQL


Em um ambiente de banco de dados tradicional , quando o tempo de resposta a uma consulta ao banco de dados se aproxima ou até excede os limites predefinidos do aplicativo (principalmente devido a um aumento no número de usuários e / ou consultas), existem várias maneiras de reduzir o tempo de resposta para níveis aceitáveis. No entanto, a maioria dessas soluções inclui intervenção manual.

Por exemplo, a primeira etapa que você precisa executar é examinar os vários parâmetros do banco de dados relacionados ao desempenho e configurá-los para melhor corresponder aos padrões de uso do aplicativo. Se isso não for suficiente, você pode optar por dimensionar o banco de dados verticalmente ou horizontalmente.

Escalar o aplicativo implica atualizar a instância do servidor, geralmente adicionando mais processadores / núcleos, mais RAM, armazenamento mais rápido etc. A adição de mais recursos de hardware leva a um aumento no desempenho do banco de dados, medido principalmente nas transações em segundo e atraso de transação para sistemas OLTP. Os sistemas de bancos de dados relacionais (que usam uma abordagem multithread), como o MySQL, escalam bem verticalmente.

Essa abordagem tem várias desvantagens, mas a mais óbvia é o tamanho máximo do servidor no mercado. Quando o limite da maior instância do servidor é atingido, existe apenas uma maneira: dimensionamento horizontal.

A escala horizontal é uma abordagem na qual mais servidores são adicionados ao cluster para aumentar linearmente o desempenho idealmente com a adição do número de servidores. A maioria dos sistemas de banco de dados tradicionais não se dimensiona bem horizontalmente ou não é dimensionada. Por exemplo, o MySQL pode escalar horizontalmente para operações de leitura adicionando leitores escravos, mas não pode escalar horizontalmente para operações de gravação.

Por outro lado, devido à sua natureza, o Cloud Spanner pode ser facilmente escalado horizontalmente com o mínimo de interferência. DBMS

completo como um serviçodeve ser avaliado sob diferentes ângulos. Como base, adotamos o DBMS mais popular da nuvem - para Google, GCP Cloud SQL e para Amazon, AWS RDS. Em nossa avaliação, focamos nas seguintes categorias:

  • Mapeamento de recursos: extensão SQL, DDL, DML; bibliotecas / conectores de conexão, suporte a transações e assim por diante.
  • Suporte ao desenvolvimento: facilidade de desenvolvimento e teste.
  • Suporte administrativo: gerenciamento de instâncias - por exemplo, aumento / redução de escala e atualização de instâncias; SLA, backup e restauração; segurança / controle de acesso.

Usando o Cloud Spanner como OLTP com suporte a OLAP


Embora o Google não afirme explicitamente que o Cloud Spanner é para processamento analítico, ele compartilha alguns atributos com outros mecanismos, como Apache Impala & Kudu e YugaByte, projetados para cargas de trabalho OLAP.

Mesmo que houvesse apenas uma pequena chance de o Cloud Spanner incluir um mecanismo HTAP (processamento transacional / analítico híbrido) escalável horizontalmente consistente com um conjunto (mais ou menos) utilizável de recursos OLAP, achamos que isso merece nossa atenção.

Com isso em mente, examinamos as seguintes categorias:

  • Suporte para carregamento de dados, índices e particionamento
  • Desempenho da consulta e DML

2. Cloud Spanner em poucas palavras


O Google Spanner é um sistema de gerenciamento de banco de dados relacional em cluster (RDBMS) que o Google usa para vários de seus próprios serviços. O Google disponibilizou publicamente para os usuários do Google Cloud Platform no início de 2017.

Aqui estão alguns dos atributos do Cloud Spanner:

  • Cluster RDBMS escalável altamente consistente: usa sincronização de tempo do hardware para garantir a consistência dos dados.
  • Suporte a transações entre tabelas: as transações podem abranger várias tabelas - não necessariamente limitadas a uma tabela (diferente do Apache HBase ou Apache Kudu).
  • : (), . , . , .
  • : . . , , , -.
  • : Cloud Spanner . . . . , , , . , .

«Cloud Spanner . , Cloud Spanner , - , ».


: Apache Tephra Apache HBase ( Apache Phoenix -).

3.


Portanto, todos lemos as declarações do Google sobre os benefícios do Cloud Spanner - escala horizontal praticamente ilimitada, mantendo alta consistência e SLA muito alto. Embora esses requisitos sejam, de qualquer forma, extremamente difíceis de alcançar, nosso objetivo não era refutá-los. Em vez disso, vamos nos concentrar em outras coisas que a maioria dos usuários de banco de dados se preocupa: paridade e usabilidade.

Classificamos o Cloud Spanner como um substituto para o Sharded MySQL


O Google Cloud SQL e o Amazon AWS RDS, os dois DBMSs OLTP mais populares no mercado de nuvem, têm um conjunto de recursos muito grande. No entanto, para dimensionar esses bancos de dados além do tamanho de um único nó, é necessário executar o particionamento de aplicativos. Essa abordagem cria complexidade adicional para aplicativos e administração. Vimos como o Spanner se encaixa no cenário de combinar vários segmentos em uma instância e quais recursos (se houver) podem ter que ser sacrificados.

Suporte para SQL, DML e DDL, bem como conectores e bibliotecas?


Primeiro, ao iniciar com qualquer banco de dados, você deve criar um modelo de dados. Se você acha que pode conectar o JDBC Spanner à sua ferramenta SQL favorita, descobrirá que pode consultar seus dados com ele, mas não poderá usá-lo para criar uma tabela ou alteração (DDL) ou qualquer operação de inserção / atualização / exclusão ( DML). O JDBC oficial do Google também não é compatível.
"Atualmente, os drivers não suportam DML ou DDL."
Documentação da chave inglesa

Com o console do GCP, a situação não é melhor - você pode enviar apenas consultas SELECT. Felizmente, existe um driver JDBC com suporte a DML e DDL da comunidade, incluindo transações github.com/olavloite/spanner-jdbc . Embora esse driver seja extremamente útil, a falta do driver JDBC do Google é surpreendente. Felizmente, o Google oferece suporte bastante amplo para bibliotecas de clientes (baseadas em gRPC): C #, Go, Java, node.js, PHP, Python e Ruby.

O uso quase obrigatório de interfaces de usuário do Cloud Spanner (devido à falta de DDL e DML no JDBC) leva a algumas restrições para áreas de código relacionadas, como conjuntos de conexões ou estruturas de ligação de banco de dados (por exemplo, Spring MVC). Como regra, ao usar o JDBC, você pode selecionar livremente seu conjunto de conexões favorito (por exemplo, HikariCP, DBCP, C3PO etc.), que é testado e funciona bem. No caso de APIs personalizadas do Spanner, devemos confiar nas estruturas / conjuntos de associações / sessões que criamos.

O design da chave primária (PC) permite que o Cloud Spanner seja muito rápido ao acessar dados via PC, mas também gera alguns problemas de consulta.

  • ; . ( / .)
  • UPDATE DELETE WHERE, , DELETE all — , : UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • - , . , .

?


O Google Cloud Spanner oferece suporte interno para índices secundários. Esse é um recurso muito bom, que nem sempre está presente em outras tecnologias. Atualmente, o Apache Kudu não suporta índices secundários e o Apache HBase não suporta índices diretamente, mas pode adicioná-los através do Apache Phoenix.

Os índices no Kudu e HBase podem ser modelados como uma tabela separada com composição diferente de chaves primárias, mas a atomicidade das operações executadas na tabela pai e nas tabelas de índices relacionadas deve ser executada no nível do aplicativo e não é trivial na implementação correta.

Como mencionado na revisão do Cloud Spanner, seus índices podem diferir dos índices do MySQL. Portanto, deve-se tomar um cuidado especial ao criar consultas e criar perfis para garantir que o índice adequado seja usado onde for necessário.

Representação?


Um objeto muito popular e útil no banco de dados são as visualizações. Eles podem ser úteis para um grande número de casos de usuários; meus dois favoritos são o nível de abstração lógica e o nível de segurança. Infelizmente, o Cloud Spanner NÃO suporta envios. No entanto, isso nos limita apenas parcialmente, porque para permissões de acesso, não há granularidade no nível da coluna em que representações podem ser uma solução aceitável.

A documentação do Cloud Spanner possui uma seção que detalha cotas e restrições ( chave / cotas), em particular, existe um que pode ser problemático para alguns aplicativos: o Cloud Spanner pronto para uso tem um limite de no máximo 100 bancos de dados por instância. Obviamente, isso pode ser um obstáculo sério para um banco de dados projetado para ser dimensionado para mais de 100 bancos de dados. Felizmente, depois de conversar com nosso representante técnico do Google, descobrimos que esse limite pode ser aumentado para quase qualquer valor através do suporte do Google.

Suporte ao desenvolvimento?


O Cloud Spanner oferece suporte bastante decente para linguagens de programação para trabalhar com sua API. As bibliotecas oficialmente suportadas estão nas áreas de C #, Go, Java, node.js, PHP, Python e Ruby. A documentação é bastante detalhada, mas, como em outras tecnologias avançadas, a comunidade é muito pequena em comparação com as tecnologias de banco de dados mais populares, o que pode levar a um aumento no tempo gasto na solução de casos ou problemas de uso menos comuns.

E o apoio ao desenvolvimento local?


Não encontramos uma maneira de criar uma instância do Cloud Spanner no ambiente local. O mais próximo que chegamos é da imagem do CockroachDB Docker , que em princípio é semelhante, mas na prática é muito diferente. Por exemplo, o CockroachDB pode usar o PostgreSQL JDBC. Como o ambiente de desenvolvimento deve estar o mais próximo possível do ambiente de trabalho, o Cloud Spanner não é ideal, pois você precisa contar com uma instância completa do Spanner. Para economizar custos, você pode escolher uma instância para uma região.

Suporte administrativo?


Criar uma instância do Cloud Spanner é fácil. Você só precisa escolher entre criar uma instância multi-regional ou para uma região, especificar a (s) região (ões) e o número de nós. Em menos de um minuto, a instância estará em funcionamento.

Várias métricas básicas estão disponíveis diretamente na página da chave inglesa no console do Google. Visualizações mais detalhadas estão disponíveis no Stackdriver, onde você também pode definir métricas de limite e políticas de alerta.

Acesso a recursos?


O MySQL oferece permissões de usuário / configurações extensas e muito detalhadas. Você pode configurar facilmente o acesso a uma tabela específica ou até apenas um subconjunto de suas colunas. O Cloud Spanner usa a ferramenta IAM (Gerenciamento de acesso e identidade do Google), que permite definir políticas e permissões apenas em um nível muito alto. A opção mais detalhada é uma resolução no nível do banco de dados que não se encaixa na maioria dos casos de produção. Essa restrição obriga a adicionar medidas de segurança adicionais ao seu código, infraestrutura ou ambas, para impedir o uso não autorizado dos recursos do Spanner.

Backups?


Em termos simples, não há backups no Cloud Spanner. Embora os altos requisitos do SLA do Google possam garantir que você não perderá dados devido a falhas de hardware ou banco de dados, erros humanos, defeitos de aplicativos etc. Todos conhecemos a regra: a alta disponibilidade não substitui uma estratégia de backup razoável. No momento, a única maneira de fazer backup de dados é transmiti-los programaticamente do banco de dados para um ambiente de armazenamento separado.

Query performance?


Usamos o Yahoo! para baixar dados e testar consultas. Referência de serviço em nuvem. A tabela abaixo mostra a carga de trabalho YCSB B com uma taxa de leitura de 95% e uma taxa de gravação de 5%.



* O teste de carga foi realizado no mecanismo computacional n1-standard-32 (CE) (32 vCPU, 120 GB de memória) e a instância de teste nunca foi um gargalo nos testes.
** O número máximo de encadeamentos em uma instância do YCSB é 400. No total, seis instâncias paralelas dos testes do YCSB precisaram ser executadas para obter um total de 2400 encadeamentos.

Olhando para os resultados do teste, em particular a combinação de carga do processador e TPS, vemos claramente que o Cloud Spanner é muito bom. A grande carga criada por um grande número de encadeamentos é compensada pelo grande número de nós no cluster do Cloud Spanner. Embora o atraso pareça bastante alto, especialmente ao trabalhar com 2400 threads, pode ser necessário testar novamente com 6 instâncias menores do mecanismo computacional para obter números mais precisos. Cada instância executará um teste YCSB em vez de uma instância CE grande com 6 testes paralelos. Assim, será mais fácil distinguir entre atrasos na solicitação do Cloud Spanner e atrasos adicionados pela conexão de rede entre o Cloud Spanner e a instância do CE na qual o teste está sendo executado.

Como o Cloud Spanner lida com OLAP?


Particionamento?


Dividir dados em segmentos fisicamente e / ou logicamente independentes, chamados partições, é um conceito muito popular inerente à maioria dos mecanismos OLAP. As partições podem melhorar significativamente o desempenho da consulta e o suporte ao banco de dados. Um aprofundamento adicional na partição surgiria em um artigo separado, então vamos apenas mencionar a importância de ter um esquema de particionamento e subdivisão. A capacidade de particionar dados em partições e ainda mais em subpartições é essencial para o desempenho de consultas analíticas.

O Cloud Spanner não suporta partições por si só. Ele divide os dados internamente na chamada divisãos com base em intervalos de chave primária. A separação é realizada automaticamente para equilibrar a carga no cluster do Cloud Spanner. Um recurso muito conveniente do Cloud Spanner é dividir a carga base da tabela pai (uma tabela que não se alterna com outra). O Spanner determina automaticamente se a divisão contém dados que são lidos com mais frequência do que os dados de outras divisões e pode decidir uma separação adicional. Assim, mais nós podem estar envolvidos na solicitação, o que também aumenta efetivamente a taxa de transferência.

Carregando dados?


O método Cloud Spanner para dados em massa é o mesmo que para downloads regulares. Para alcançar o desempenho máximo, você precisa seguir algumas recomendações, incluindo:

  • Classifique seus dados por chave primária.
  • Divida-os por 10 * o número de nós de seções individuais.
  • Crie um conjunto de tarefas de trabalho que carregam dados em paralelo.

Com esse download de dados, todos os nós do Cloud Spanner são usados.

Usamos a carga de trabalho A YCSB para gerar um conjunto de dados de 10 milhões de linhas.



* O teste de carga foi realizado no mecanismo computacional n1-standard-32 (32 vCPU, 120 GB de memória) e a instância de teste nunca foi um gargalo nos testes.
** Uma configuração de 1 nó não é recomendada para qualquer carga de produção.

Como mencionado acima, o Cloud Spanner processa automaticamente os split-s, dependendo da carga, para que os resultados melhorem após várias repetições sucessivas do teste. Os resultados apresentados aqui são os melhores resultados que recebemos. Observando os números acima, podemos ver como o Cloud Spanner é escalado (bem) com um aumento no número de nós no cluster. Os números que se destacam são atrasos médios extremamente baixos que contrastam com os resultados de cargas de trabalho mistas (95% para leitura e 5% para escrita), conforme descrito na seção acima.

Dimensionamento?


Aumentar e diminuir o número de nós do Cloud Spanner é uma tarefa com um clique. Se você deseja carregar dados rapidamente, considere aumentar a instância ao máximo (no nosso caso, eram 25 nós na região US-EAST) e reduza o número de nós adequados para sua carga regular após todos os dados no banco de dados tendo em mente a limitação de 2 TB / nó.

Fomos lembrados desse limite, mesmo com um banco de dados muito menor. Após várias execuções de testes de carga, nosso banco de dados tinha cerca de 155 GB de tamanho e, quando reduzido para uma instância de 1 nó, obtivemos o seguinte erro:



Conseguimos reduzir a escala de 25 para 2 instâncias, mas estávamos presos em dois nós.

Aumentar e diminuir o número de nós em um cluster do Cloud Spanner pode ser automatizado usando a API REST. Isso pode ser especialmente útil para reduzir o aumento de carga no sistema durante o horário de pico.

Desempenho da consulta OLAP?


Inicialmente, planejamos dedicar um tempo considerável à nossa avaliação do Spanner para esta parte. Depois de várias SELECT COUNTs, percebemos imediatamente que o teste seria curto e que o Spanner NÃO seria um mecanismo OLAP. Independentemente do número de nós no cluster, uma simples seleção do número de linhas em uma tabela de 10 milhões de linhas levou de 55 a 60 segundos. Além disso, qualquer solicitação que exigisse mais memória para armazenar resultados intermediários falhou com um erro de OOM.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Alguns números para solicitações de TPC-H podem ser encontrados no artigo de Todd Lipcon Nosql-kudu-spanner-slides.html , slides 42 e 43. Esses números são consistentes com nossos próprios resultados (infelizmente).



4. Nossas descobertas


Dado o estado atual dos recursos do Cloud Spanner, é difícil imaginá-lo como um simples substituto para uma solução OLTP existente, especialmente quando suas necessidades a superam. Uma quantidade significativa de tempo seria gasta na construção de uma solução que levasse em consideração as falhas do Cloud Spanner.

Quando começamos a avaliar o Cloud Spanner, esperávamos que seus recursos de gerenciamento estivessem no ou pelo menos não tão longe de outras soluções do Google SQL. Mas ficamos surpresos com a completa falta de backups e o controle muito limitado do acesso aos recursos. Sem mencionar a falta de visualizações, a falta de um ambiente de desenvolvimento local, sequências não suportadas, JDBC sem suporte a DML e DDL e assim por diante.

Então, para onde vai quem precisa escalar o banco de dados transacional? Parece que não existe uma solução única no mercado que seja adequada para todos os casos de uso. Existem muitas soluções de código aberto e fechado (algumas das quais mencionadas neste artigo), cada uma com suas próprias vantagens e desvantagens, mas nenhuma delas oferece SaaS com um SLA de 99,999% e um alto grau de consistência. Se um SLA alto é seu objetivo principal e você não deseja criar sua própria solução para vários ambientes de nuvem, o Cloud Spanner pode ser a solução que você está procurando. Mas você deve estar ciente de todas as suas limitações.

Para ser justo, deve-se notar que o Cloud Spanner não foi divulgado ao público apenas na primavera de 2017, por isso é razoável esperar que algumas de suas deficiências atuais possam eventualmente desaparecer (espero) e, quando isso acontecer, poderá mudar o jogo. Afinal, o Cloud Spanner não é apenas um projeto de terceiros para o Google. O Google usa-o como base para outros produtos do Google. E quando o Google substituiu recentemente a Megastore no Google Cloud Storage pelo Cloud Spanner, permitiu que o Google Cloud Storage fosse estritamente consistente para listagens de objetos em todo o mundo (o que ainda não se aplica ao S3 da Amazon ). Então, ainda há esperança ... nós esperamos.



Isso é tudo. Como o autor do artigo, também continuamos esperando, mas o que você acha disso? Escreva nos comentários.

Convidamos todos a visitar nosso seminário on-line gratuito, no âmbito do qual falaremos detalhadamente sobre o curso OTUS AWS for Developers .

More articles:


All Articles