Distributed SQL 2.4

Distributed SQL

cqP8BDbUJvCjkkE_hcAkl71WWIIgllyfMRV2wvHRHG8__PBZ9dOjBIfrJrTxqJ0ymt4GOpZLjyrGfcIhUZ9wtba0LsNUMZzzuZ6cX4csU7gUcjjRrYFlx2_cth3urIJti6D5LQVkYUJY8Ex-JoE

Grupo

Vítor Beneti Martins - 11877635

Breno Alves de Sousa - 11345555

Alexandre Lima Palles Rocha - 11797038

Pedro Lucas de Moliner de Castro - 11795784

Johnny Batista da Silva - 11371350

Pedro Martelleto Bressane Rezende - 11795641

André Luís Mendes Fakhoury - 4482145

David Cairuz da Silva - 10830061

Erick Patrick Andrade Barcelos - 11345562

Antonio Rodrigues Rigolino - 11795791

João Guilherme Jarochinski Marinho - 10698193

Slides

Link

Principais Features 

Em relação ao Spanner em específico, temos as seguintes features principais:.

  • A replicação é síncrona e "quase 100%" consistente (veja seção sobre CAP).

  • As leituras são fortemente consistentes e os dados são versionados - é possível ler versões anteriores de dados, que são auto deletadas depois de um período.

  • As transações podem ser aplicadas em em qualquer dado dentro um universo Spanner (que nada mais é do que uma instância do Spanner).

  • Controle sobre replicação e localização dos dados por meio de failover automático e definições sobre a replicação

Em geral, bancos de dados distribuídos baseados em SQL possuem as seguintes features:

  • Usa, na implementação subjacente, dados guardados baseados em pares key, value. Porém, a estrutura "front-end" apresentada ao usuário é de tabelas com linhas e colunas, similar à Bancos de Dados Relacionais.

  • Conformidade com o ACID: ATOMICITY, CONSISTENCY, ISOLATION e DURABILITY. Assim, garante-se:

    • Atomicidade:  As transações geralmente são compostas de várias instruções. A atomicidade garante que cada transação seja tratada como uma única "unidade", que ou é bem-sucedida ou falha completamente: se qualquer uma das instruções que constituem uma transação não for concluída, toda a transação falhará e o banco de dados permanecerá inalterado.

    • Consistência: A consistência garante que uma transação só possa trazer o banco de dados de um estado válido para outro, mantendo invariantes do banco de dados: quaisquer dados gravados no banco de dados devem ser válidos de acordo com todas as regras definidas, incluindo restrições, cascatas, gatilhos e qualquer combinação deles.

    • Isolamento: As transações geralmente são executadas simultaneamente (por exemplo, várias transações lendo e gravando em uma tabela ao mesmo tempo). O isolamento garante que a execução simultânea de transações deixe o banco de dados no mesmo estado que teria sido obtido se as transações fossem executadas sequencialmente.

    • Durabilidade: A durabilidade garante que, uma vez que uma transação tenha sido confirmada, ela permanecerá confirmada mesmo no caso de uma falha do sistema (por exemplo, queda de energia ou falha).

  • Fragmentação automática do armazenamento de dados (processo de sharding): o dataset é divido em partes (shards), e cada subconjunto/parte é guardado em uma máquina separada.

  • Implementação SQL nativa.

  • Replicação síncrona: permite copiar os dados sobre a rede, replicando-os e garantindo que haja cópias atualizadas.

  • Para garantir consistência, é comum a necessidade de sincronização temporal entre nós.

https://cloud.google.com/blog/products/databases/inside-cloud-spanner-and-the-cap-theorem

dir="ltr">Does it implement CA, CP or AP? Why?

O Google Cloud Spanner sempre fornece consistência dos dados, faltando apenas optar por disponibilidade (CA) ou particoes (CP).

O Google Cloud Spanner comenta que pode ser assumido que é utilizado CA, já que o usuário pode ignorar interrupções do serviço, dado que a disponibilidade é muito alta, por isso o sistema pode ser assumido como CA.

Tecnicamente ele é CP, tanto por ser um sistema distribuído e partições podem acontecer, tanto que já aconteceram, porém como as partições acontecem raramente, a Google comenta que as partições são quase que ignoradas.

rFfdxvVYCgGZBOM0UCyD_I5Vp2xMx1I4IpG5lkQldtOczah6GbL323GgxVZdUMp9W1pkZWr3MjmfKe-ncWI6S-ICeQ6_kPD4eRcUfF_QPPDUV89y8LP0Ey5waKalFUzmstWo6Wp4QkFnI4o-quo

Vantagens 

As principais vantagens e benefícios do Spanner são:

  • Suporte SQL: por ser um serviço “Distributed SQL”, é possível utilizar uma interface nativa SQL para leitura e escrita de dados;

  • Replicação síncrona e fortemente consistente: o Google Spanner combina a utilização de queries SQL com dados relacionais com uma forte consistência e alta disponibilidade para os dados, com replicação síncrona;

  • Versionamento de Dados: os dados são versionados, o que permite com que os clientes possam realizar leituras em versões antigas (sujeitas a janelas de garbage collection);

  • Fácil utilização: por ser uma ferramenta mais simples de ser utilizada, as funcionalidades são facilmente acessadas;

  • Escalonamento: Uma escala ilimitada é disponível no Google Cloud (Cloud Spanner), o que permite um escalonamento sem limites, de acordo com as necessidades que surgem com o passar do tempo;

  • Preço de acordo com a utilização: o Cloud Spanner possui uma precificação realizada de acordo com a utilização mensal de nós, armazenamento e rede, e apenas o que for utilizado será somado no valor final do mês.

rFfdxvVYCgGZBOM0UCyD_I5Vp2xMx1I4IpG5lkQldtOczah6GbL323GgxVZdUMp9W1pkZWr3MjmfKe-ncWI6S-ICeQ6_kPD4eRcUfF_QPPDUV89y8LP0Ey5waKalFUzmstWo6Wp4QkFnI4o-quo

Desvantagens 

O sistema Spanner da Google apresenta algumas desvantagens, como:

Um dos principais problemas do Spanner é a alta latência em níveis inaceitáveis para alguns tipos de aplicações, com transações comumente de 100ms. Isso ocorre pela necessidade de sincronizar os dados utilizando a API TrueTime, responsável por atribuir “carimbos” de data/hora em todas as transações no banco de dados.

O Spanner apresenta, também, um SQL proprietário que não é compatível com a API de nenhum dos outros softwares Open Source equivalentes e é diferente, inclusive, de SQL tradicional não tendo construtores como Foreign Keys, tornando a curva de aprendizado lenta e o aproveitamento de mão de obra baixo.

Sendo proprietária e fechada, a plataforma exige a integração especificamente com a Cloud da Google, limitando as opções de desenvolvimento e dificultando possíveis mudanças de arquitetura no futuro.

O alto custo também é uma grande desvantagem. Isso acontece porque o Spanner roda em máquinas de alta performance, com relógios específicos para dados OLTP.

rFfdxvVYCgGZBOM0UCyD_I5Vp2xMx1I4IpG5lkQldtOczah6GbL323GgxVZdUMp9W1pkZWr3MjmfKe-ncWI6S-ICeQ6_kPD4eRcUfF_QPPDUV89y8LP0Ey5waKalFUzmstWo6Wp4QkFnI4o-quo

Nichos de aplicação 

Por se tratar de uma tecnologia famosa e confiável, está bem disseminada no mercado, com diversas implementações diferentes. Dito isso, não é possível apontar uma única área que utiliza em massa, já que o mercado como um todo a utiliza amplamente.

  • Trading/Mercado de Ações
  • Seguradoras
  • Telecomunicação/Call centers
  • Sistemas de Faturas
  • E-commerce de alta disponibilidade


  rFfdxvVYCgGZBOM0UCyD_I5Vp2xMx1I4IpG5lkQldtOczah6GbL323GgxVZdUMp9W1pkZWr3MjmfKe-ncWI6S-ICeQ6_kPD4eRcUfF_QPPDUV89y8LP0Ey5waKalFUzmstWo6Wp4QkFnI4o-quo