Olá, residentes de Khabrovsk. Como sempre, continuamos a compartilhar materiais interessantes antes do início de novos cursos. Hoje, especialmente para você, publicamos um artigo sobre o Google Cloud Spanner para coincidir com o lançamento do curso .
Publicado originalmente em .
Como uma empresa que oferece uma variedade de soluções de PDV baseadas em nuvem para varejistas, donos de restaurantes e vendedores on-line em todo o mundo, a Lightspeed usa vários tipos diferentes de plataformas de banco de dados para uma variedade de casos de uso transacionais, analíticos e de pesquisa. Cada uma dessas plataformas de banco de dados tem seus próprios pontos fortes e fracos. Portanto, quando o Google introduziu o Cloud Spanner no mercado - recursos promissores inéditos no mundo dos bancos de dados relacionais, como escalabilidade horizontal praticamente ilimitada e um acordo de nível de serviço (SLA) de 99,999%. — não podíamos perder a oportunidade de colocar as mãos nele!
Para fornecer uma visão abrangente de nossa experiência com o Cloud Spanner, bem como os critérios de avaliação que usamos, abordaremos os seguintes tópicos:
- Nossos critérios de avaliação
- Cloud Spanner em poucas palavras
- Nossa avaliação
- Nossas descobertas
1. Nossos critérios de avaliação
Antes de nos aprofundarmos nas especificidades do Cloud Spanner, suas semelhanças e diferenças com outras soluções do mercado, vamos primeiro falar sobre os principais casos de uso que tínhamos em mente ao considerar onde implantar o Cloud Spanner em nossa infraestrutura:
- Como um substituto para a solução de banco de dados SQL tradicional (predominante)
- Como fazer solução OLTP com suporte OLAP
Nota: Para simplificar e facilitar a comparação, este artigo compara o Cloud Spanner com as variantes MySQL das famílias de soluções GCP Cloud SQL e Amazon AWS RDS.
Usar o Cloud Spanner como substituto de uma solução de banco de dados SQL tradicional
No meio ambiente tradicional bancos de dados, quando o tempo de resposta da 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 solicitações), existem várias maneiras de reduzir o tempo de resposta a níveis aceitáveis. No entanto, a maioria destas soluções envolve intervenção manual.
Por exemplo, a primeira etapa a ser tomada é examinar os vários parâmetros do banco de dados relacionados ao desempenho e ajustá-los para melhor corresponder aos padrões de caso de uso do aplicativo. Se isso não for suficiente, você pode optar por dimensionar o banco de dados verticalmente ou horizontalmente.
O dimensionamento vertical de um aplicativo envolve a atualização da instância do servidor, normalmente adicionando mais processadores/núcleos, mais RAM, armazenamento mais rápido, etc. Adicionar mais recursos de hardware resulta em maior desempenho do banco de dados, medido principalmente em transações por segundo, e latência de transação para sistemas OLTP. Sistemas de banco de dados relacionais (que usam uma abordagem multithread), como o MySQL, são bem dimensionados verticalmente.
Existem várias desvantagens nesta abordagem, mas a mais óbvia é o tamanho máximo do servidor no mercado. Uma vez atingido o limite da maior instância de servidor, resta apenas uma opção: escalabilidade horizontal.
O escalonamento horizontal é uma abordagem em que mais servidores são adicionados a um cluster, aumentando de maneira ideal o desempenho linearmente à medida que o número de servidores é adicionado. Maioria tradicional Os sistemas de banco de dados não escalam bem horizontalmente ou nem escalam. Por exemplo, o MySQL pode escalar horizontalmente para operações de leitura adicionando leitores escravos, mas não pode escalar horizontalmente para escritas.
Por outro lado, devido à sua natureza, o Cloud Spanner pode ser facilmente dimensionado horizontalmente com intervenção mínima.
Totalmente caracterizado SGBD como serviço deve ser avaliada sob diferentes ângulos. Tomamos como base o SGBD mais popular na nuvem - para Google, GCP Cloud SQL e para Amazon, AWS RDS. Em nossa avaliação, nos concentramos 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: fácil desenvolvimento e teste.
- Suporte administrativo: gerenciamento de instâncias - por exemplo, aumento/redução e atualização de instâncias; SLA, backup e recuperação; segurança/controle de acesso.
Usando o Cloud Spanner como uma solução OLTP habilitada para OLAP
Embora o Google não afirme explicitamente que o Cloud Spanner foi projetado 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 híbrido transacional/analítico) de expansão consistente com um conjunto de recursos OLAP (mais ou menos) utilizável, achamos que seria digno de nossa atenção.
Com isso em mente, analisamos as seguintes categorias:
- Carregamento de dados, índices e suporte a particionamento
- Desempenho de consulta e DML
2. Cloud Spanner em poucas palavras
O Google Spanner é um sistema de gerenciamento de banco de dados relacional clusterizado (RDBMS) que o Google usa para vários de seus próprios serviços. O Google disponibilizou-o 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 de 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 única tabela (ao contrário do Apache HBase ou Apache Kudu).
- Tabelas baseadas em chave primária: todas as tabelas devem ter uma chave primária (PC) declarada, que pode consistir em várias colunas na tabela. Os dados tabulares são armazenados na ordem do PC, tornando-os muito eficientes e rápidos para pesquisa no PC. Como outros sistemas baseados em PC, a implementação deve ser modelada com casos de uso pré-concebidos em mente para alcançar .
- Tabelas distribuídas: as tabelas podem ter dependências físicas umas das outras. As linhas de uma tabela filha podem ser comparadas com as linhas de uma tabela pai. Essa abordagem agiliza a busca por relacionamentos que possam ser identificados durante a fase de modelagem de dados, como a co-localização de clientes e suas faturas.
- Índices: o Cloud Spanner oferece suporte a índices secundários. O índice consiste nas colunas indexadas e em todas as colunas do PC. Se desejar, o índice também pode conter outras colunas não indexadas. O índice pode ser intercalado com a tabela pai para acelerar as consultas. Várias restrições se aplicam aos índices, como o número máximo de colunas adicionais armazenadas no índice. Além disso, as consultas através de índices podem não ser tão simples como em outros RDBMSs.
“O Cloud Spanner seleciona um índice automaticamente apenas em casos raros. Especificamente, o Cloud Spanner não seleciona automaticamente um índice secundário se uma consulta solicitar colunas que não estejam armazenadas em ".
- Acordo de Nível de Serviço (SLA): Implantação em uma região com SLA de 99,99%; implantações multirregionais com SLA de 99,999%. Embora o SLA em si seja apenas um acordo e não uma garantia de qualquer tipo, acredito que o pessoal do Google tenha alguns dados concretos para fazer uma afirmação tão forte. (Para referência, 99,999% significa 26,3 segundos de indisponibilidade do serviço por mês.)
- Mais:
Nota: O projeto Apache Tephra adiciona suporte aprimorado a transações ao Apache HBase (agora também implementado no Apache Phoenix como beta).
3. Nossa avaliação
Então, todos nós lemos as afirmações do Google sobre os benefícios do Cloud Spanner: escalonamento horizontal praticamente ilimitado, mantendo alta consistência e um SLA muito alto. Embora estes requisitos sejam, em qualquer caso, extremamente difíceis de alcançar, o nosso objectivo não foi refutá-los. Em vez disso, vamos nos concentrar em outras coisas que preocupam a maioria dos usuários de banco de dados: paridade e usabilidade.
Avaliamos o Cloud Spanner como um substituto para o Sharded MySQL
Google Cloud SQL e Amazon AWS RDS, dois dos DBMSs OLTP mais populares no mercado de nuvem, possuem um conjunto muito grande de recursos. 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 combinação de vários fragmentos em uma única instância e quais recursos (se houver) podem precisar ser sacrificados.
Suporte SQL, DML e DDL, bem como conectores e bibliotecas?
Primeiro, ao iniciar qualquer banco de dados, você precisa 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 pode usá-lo para criar uma tabela ou modificar (DDL) ou qualquer inserção/atualização/exclusão. operações (DML). O JDBC oficial do Google não oferece suporte a nenhum deles.
"Os drivers atualmente não suportam instruções DML ou DDL."
Documentação da chave inglesa
A situação não é melhor com o console do GCP – você só pode enviar consultas SELECT. Felizmente existe um driver JDBC com suporte para DML e DDL da comunidade, incluindo transações . Embora esse driver seja extremamente útil, a falta do driver JDBC do próprio Google é surpreendente. Felizmente, o Google oferece suporte bastante amplo para bibliotecas clientes (baseadas em gRPC): C#, Go, Java, node.js, PHP, Python e Ruby.
O uso quase obrigatório de APIs personalizadas do Cloud Spanner (devido à falta de DDL e DML no JDBC) resulta em algumas limitações para áreas de código relacionadas, como pools de conexões ou estruturas de vinculação de banco de dados (por exemplo, Spring MVC). Normalmente, ao usar JDBC, você pode escolher seu pool de conexões favorito (por exemplo, HikariCP, DBCP, C3PO, etc.) que foi testado e funciona bem. No caso de APIs Spanner personalizadas, temos que contar com estruturas/pools de ligação/sessões que nós mesmos criamos.
O design centrado na chave primária (PC) permite que o Cloud Spanner seja muito rápido ao acessar dados via PC, mas também apresenta alguns problemas de consulta.
- Você não pode atualizar o valor da chave primária; Você deve primeiro excluir a entrada do PC original e inseri-la novamente com o novo valor. (Isso é semelhante a outros mecanismos de banco de dados/armazenamento orientados para PC.)
- Quaisquer instruções UPDATE e DELETE devem especificar PC no WHERE, portanto não pode haver instruções DELETE todas vazias - sempre deve haver uma subconsulta, por exemplo: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Falta de opção de incremento automático ou algo semelhante que defina a sequência do campo PC. Para que isso funcione, o valor correspondente deve ser criado no lado da aplicação.
Índices secundários?
O Google Cloud Spanner tem suporte integrado para índices secundários. Esse é um recurso muito interessante que nem sempre está presente em outras tecnologias. Atualmente, o Apache Kudu não oferece suporte a índices secundários e o Apache HBase não oferece suporte a índices diretamente, mas pode adicioná-los por meio do Apache Phoenix.
Os índices no Kudu e no HBase podem ser modelados como uma tabela separada com uma composição diferente de chaves primárias, mas a atomicidade das operações executadas na tabela pai e nas tabelas de índices associadas deve ser feita no nível do aplicativo e não é trivial para implementar corretamente.
Conforme mencionado na análise do Cloud Spanner, seus índices podem ser diferentes dos índices do MySQL. Portanto, deve-se tomar cuidado especial ao construir consultas e criar perfis para garantir que o índice adequado seja usado onde for necessário.
Representação?
Um objeto muito popular e útil em um banco de dados são as visualizações. Eles podem ser úteis para um grande número de casos de uso; meus dois favoritos são a camada de abstração lógica e a camada de segurança. Infelizmente, o Cloud Spanner NÃO oferece suporte a visualizações. No entanto, isso nos limita apenas parcialmente porque não há granularidade para permissões de acesso no nível da coluna onde as visualizações podem ser uma solução viável.
Consulte a documentação do Cloud Spanner para ver uma seção que detalha cotas e restrições (), há um em particular 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 grande gargalo para um banco de dados projetado para escalar mais de 100 bancos de dados. Felizmente, depois de falar com o nosso representante técnico do Google, descobrimos que esse limite pode ser aumentado para quase qualquer valor através do Suporte do Google.
Apoio ao desenvolvimento?
O Cloud Spanner oferece suporte de linguagem de programação bastante decente 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 acontece com outras tecnologias avançadas, a comunidade é bastante pequena em comparação com as tecnologias de banco de dados mais populares, o que pode levar a mais tempo gasto na resolução de casos de uso ou problemas menos comuns.
Então, que tal apoiar o desenvolvimento local?
Não encontramos uma maneira de criar uma instância do Cloud Spanner no local. A coisa mais próxima que conseguimos foi uma imagem do Docker. , que é semelhante em princípio, mas muito diferente na prática. Por exemplo, CockroachDB pode usar PostgreSQL JDBC. Como o ambiente de desenvolvimento deve ser o mais próximo possível do ambiente de produção, o Cloud Spanner não é ideal, pois deve contar com uma instância completa do Spanner. Para economizar custos, você pode selecionar uma instância de região única.
Apoio administrativo?
Criar uma instância do Cloud Spanner é muito simples. Você só precisa escolher entre criar uma instância multirregional ou única, especificar a(s) região(ões) e o número de nós. Em menos de um minuto, sua instância estará instalada e funcionando.
Várias métricas rudimentares podem ser acessadas diretamente na página do Spanner no Google Console. Visualizações mais detalhadas estão disponíveis no Stackdriver, onde você também pode definir limites de métricas e políticas de alerta.
Acesso a recursos?
O MySQL oferece configurações extensas e muito granulares para permissões/funções de usuário. Você pode configurar facilmente o acesso a uma tabela específica ou até mesmo a um subconjunto de suas colunas. O Cloud Spanner usa a ferramenta Identity & Access Management (IAM) do Google, que só permite definir políticas e permissões em um nível muito alto. A opção mais granular é a resolução em nível de banco de dados, que não se enquadra na maioria dos casos de uso de produção. Essa limitação força você a adicionar medidas de segurança adicionais ao seu código, infraestrutura ou ambos para evitar o uso não autorizado dos recursos do Spanner.
Cópias de segurança?
Simplificando, não há backups no Cloud Spanner. Embora os altos requisitos de SLA do Google possam garantir que você não perca nenhum dado devido a falhas de hardware ou banco de dados, erros humanos, defeitos de aplicativos, etc. Todos nós conhecemos a regra: a alta disponibilidade não substitui uma estratégia de backup sólida. Atualmente, a única maneira de fazer backup dos dados é transmiti-los programaticamente de um banco de dados para um ambiente de armazenamento separado.
Desempenho da consulta?
Usamos o Yahoo! para carregar dados e testar consultas. Referência de serviço em nuvem. A tabela abaixo mostra a carga de trabalho B do YCSB com uma proporção de leitura de 95% para gravação de 5%.
* O teste de carga foi executado no Compute Engine (CE) n1-standard-32 (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 threads em uma única instância YCSB é 400. Um total de seis instâncias paralelas de testes YCSB tiveram que ser executadas para obter um total de 2400 threads.
Observando os resultados do benchmark, especialmente a combinação de carga de CPU e TPS, podemos ver claramente que o Cloud Spanner é muito bem dimensionado. A carga pesada criada pelo grande número de threads é compensada pelo grande número de nós no cluster do Cloud Spanner. Embora a latência pareça bastante alta, especialmente ao executar com 2400 threads, pode ser necessário testar novamente com 6 instâncias menores do mecanismo de computação 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. Dessa forma, será mais fácil diferenciar entre a latência de solicitação do Cloud Spanner e a latência adicionada pela conexão de rede entre o Cloud Spanner e a instância CE que executa o teste.
Qual é o desempenho do Cloud Spanner como OLAP?
Particionamento?
Dividir dados em segmentos fisicamente e/ou logicamente independentes, chamados partições, é um conceito muito popular encontrado na maioria dos mecanismos OLAP. As partições podem melhorar significativamente o desempenho da consulta e a capacidade de manutenção do banco de dados. Aprofundar-se no particionamento seria um artigo separado, então vamos apenas mencionar a importância de ter um esquema de particionamento e subparticionamento. A capacidade de dividir os dados em partições e ainda mais em subpartições é fundamental para o desempenho da consulta analítica.
O Cloud Spanner não oferece suporte a partições propriamente ditas. Ele divide os dados internamente nos chamados divisão-s com base em intervalos de chaves primárias. O particionamento é executado automaticamente para equilibrar a carga em um cluster do Cloud Spanner. Um recurso muito útil do Cloud Spanner é a divisão da carga base da tabela pai (uma tabela que não está intercalada com outra). O Spanner detecta automaticamente se contém divisão dados que são lidos com mais frequência do que dados em outros divisão-ah, e pode decidir sobre uma maior separação. Dessa forma, mais nós podem estar envolvidos em uma solicitação, o que também aumenta efetivamente o rendimento.
Carregando dados?
O método do Cloud Spanner para dados em massa é o mesmo do carregamento normal. Para alcançar o desempenho máximo, você precisa seguir algumas diretrizes, incluindo:
- Classifique seus dados por chave primária.
- Divida-os por 10*número de nós seções separadas.
- Crie um conjunto de tarefas de trabalho que carregam dados em paralelo.
Esse carregamento de dados usa todos os nós do Cloud Spanner.
Usamos a carga de trabalho A do YCSB para gerar um conjunto de dados de 10 milhões de linhas.
* O teste de carga foi executado no mecanismo de computação n1-standard-32 (32 vCPU, 120 GB de memória) e a instância de teste nunca foi um gargalo nos testes.
**A configuração de nó único não é recomendada para nenhuma carga de trabalho de produção.
Conforme mencionado acima, o Cloud Spanner processa automaticamente as divisões com base em sua carga, de modo que os resultados melhoram após várias repetições consecutivas de testes. Os resultados aqui apresentados são os melhores resultados que obtivemos. Observando os números acima, podemos ver como o Cloud Spanner é dimensionado (bem) à medida que o número de nós no cluster aumenta. Os números que se destacam são as latências médias extremamente baixas, que contrastam com os resultados para cargas de trabalho mistas (95% de leitura e 5% de gravação), conforme descrito na seção acima.
Dimensionamento?
Aumentar e diminuir o número de nós do Cloud Spanner é uma tarefa de um clique. Se quiser carregar dados rapidamente, considere aumentar sua instância ao máximo (no nosso caso, foram 25 nós na região US-EAST) e, em seguida, reduzir o número de nós elegíveis para sua carga normal quando todos os dados estiverem em o banco de dados, referente ao limite 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 e, quando reduzido para uma instância de 1 nó, recebemos o seguinte erro:
Conseguimos reduzir de 25 para 2 instâncias, mas ficamos 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 da carga do sistema durante horários de trabalho intensos.
Desempenho de consultas OLAP?
Originalmente, planejamos gastar uma quantidade significativa de tempo em nossa avaliação do Spanner nesta parte. Após vários SELECT COUNTs, percebemos imediatamente que os testes seriam curtos e que o Spanner NÃO seria um mecanismo adequado para OLAP. Independentemente do número de nós no cluster, a simples seleção do número de linhas em uma tabela de 10 milhões de linhas levava entre 55 e 60 segundos. Além disso, qualquer consulta que exigisse mais memória para armazenar resultados intermediários falhava com um erro OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Alguns números para consultas TPC-H podem ser encontrados no artigo de Todd Lipcon , slides 42 e 43. Esses números são consistentes com nossos próprios resultados (infelizmente).
4. Nossas conclusões
Dado o estado atual dos recursos do Cloud Spanner, é difícil imaginar que ele seja um simples substituto para sua solução OLTP existente, especialmente quando suas necessidades a superam. Uma quantidade significativa de tempo teria que ser gasta na construção de uma solução em torno das deficiências do Cloud Spanner.
Quando começamos a avaliar o Cloud Spanner, esperávamos que seus recursos de gerenciamento estivessem no mesmo nível, ou pelo menos não muito distantes, de outras soluções SQL do Google. Mas ficamos surpresos com a total falta de backups e o controle muito limitado sobre o acesso aos recursos. Sem mencionar nenhuma visualização, nenhum ambiente de desenvolvimento local, sequências sem suporte, JDBC sem suporte DML e DDL e assim por diante.
Então, para onde vai alguém que precisa dimensionar um banco de dados transacional? Não parece haver uma solução única no mercado que atenda a todos os casos de uso. Existem muitas soluções fechadas e de código aberto (algumas das quais são mencionadas neste artigo), cada uma com seus pontos fortes e fracos, mas nenhuma delas oferece SaaS com SLA de 99,999% e alta consistência. Se um SLA alto é seu objetivo principal e você não está disposto a criar uma solução multinuvem personalizada, o Cloud Spanner pode ser a solução que você procura. Mas você deve estar ciente de todas as suas limitações.
Para ser justo, o Cloud Spanner só foi lançado ao público 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á ser uma virada de jogo. Afinal, o Cloud Spanner não é apenas um projeto paralelo do Google. O Google o utiliza como base para outros produtos do Google. E quando o Google substituiu recentemente o Megastore no Google Cloud Storage pelo Cloud Spanner, permitiu que o Google Cloud Storage se tornasse altamente consistente para listas de objetos em escala global (o que ainda não é o caso para ).
Então, ainda há esperança... nós esperamos.
Isso é tudo. Assim como o autor do artigo, também continuamos esperançosos, mas o que você acha disso? Escreva nos comentários
Convidamos a todos a visitarem o nosso dentro do qual iremos informá-lo em detalhes sobre o curso de OTUS.
Fonte: habr.com