Interface do Cassandra

Esta página compara a arquitetura do Apache Cassandra e do Spanner, além de ajudar a compreender as capacidades e as limitações da interface do Spanner Cassandra. Parte do princípio de que está familiarizado com o Cassandra e quer migrar aplicações existentes ou criar novas aplicações enquanto usa o Spanner como base de dados.

O Cassandra e o Spanner são bases de dados distribuídas em grande escala criadas para aplicações que requerem elevada escalabilidade e baixa latência. Embora ambas as bases de dados possam suportar cargas de trabalho NoSQL exigentes, o Spanner oferece funcionalidades avançadas para modelagem de dados, consultas e operações transacionais. Para mais informações sobre como o Spanner cumpre os critérios de base de dados NoSQL, consulte o artigo Spanner para cargas de trabalho não relacionais.

Conceitos principais

Esta secção compara os principais conceitos do Cassandra e do Spanner.

Terminologia

Cassandra Spanner
Cluster Instância

Um cluster do Cassandra é equivalente a uma instância do Spanner, ou seja, uma coleção de servidores e recursos de armazenamento. Uma vez que o Spanner é um serviço gerido, não tem de configurar o hardware nem o software subjacente. Só tem de especificar a quantidade de nós que quer reservar para a sua instância ou usar a escalabilidade automática para dimensionar automaticamente a instância. Uma instância funciona como um contentor para as suas bases de dados. Também escolhe a topologia de replicação de dados (regional, de duas regiões ou multirregional) ao nível da instância.
Keyspace Base de dados

Um keyspace do Cassandra é equivalente a uma base de dados do Spanner, que é uma coleção de tabelas e outros elementos do esquema (por exemplo, índices e funções). Ao contrário de um espaço de chaves, não precisa de configurar a localização da replicação. O Spanner replica automaticamente os seus dados para a região designada na sua instância.
Tabela Tabela

Tanto no Cassandra como no Spanner, as tabelas são uma coleção de linhas identificadas por uma chave principal especificada no esquema da tabela.
Partição Dividir

O Cassandra e o Spanner são dimensionados através da divisão dos dados. No Cassandra, cada fragmento é denominado partição, enquanto no Spanner, cada fragmento é denominado divisão. O Cassandra usa a partição por hash, o que significa que cada linha é atribuída independentemente a um nó de armazenamento com base num hash da chave primária. O Spanner é dividido em partições por intervalo, o que significa que as linhas contíguas no espaço de chaves da chave principal também são contíguas no armazenamento (exceto nos limites de divisão). O Spanner encarrega-se da divisão e da união com base na carga e no armazenamento, e isto é transparente para a aplicação. A principal implicação é que, ao contrário do Cassandra, as análises de intervalos sobre um prefixo da chave primária são uma operação eficiente no Spanner.
Linha Linha

Tanto no Cassandra como no Spanner, uma linha é uma coleção de colunas identificadas exclusivamente por uma chave principal. Tal como o Cassandra, o Spanner suporta chaves primárias compostas. Ao contrário do Cassandra, o Spanner não faz distinção entre a chave de partição e as colunas de agrupamento, porque os dados são divididos por intervalo. Pode considerar que o Spanner tem apenas colunas de clustering, com a partição gerida nos bastidores.
Coluna Coluna

Tanto no Cassandra como no Spanner, uma coluna é um conjunto de valores de dados que têm o mesmo tipo. Existe um valor para cada linha de uma tabela. Para mais informações sobre a comparação dos tipos de colunas do Cassandra com o Spanner, consulte o artigo Tipos de dados.

Arquitetura

Um cluster do Cassandra consiste num conjunto de servidores e armazenamento localizados juntamente com esses servidores. Uma função de hash mapeia linhas de um espaço de chaves de partição para um nó virtual (vnode). Em seguida, é atribuído aleatoriamente um conjunto de vnodes a cada servidor para publicar uma parte do espaço de chaves do cluster. O armazenamento dos vnodes está anexado localmente ao nó de serviço. Os controladores de cliente ligam-se diretamente aos nós de publicação e processam o equilíbrio de carga e o encaminhamento de consultas.

Uma instância do Spanner consiste num conjunto de servidores numa topologia de replicação. O Spanner fragmenta dinamicamente cada tabela em intervalos de linhas com base na utilização da CPU e do disco. Os fragmentos são atribuídos a nós de computação para publicação. Os dados são armazenados fisicamente no Colossus, o sistema de ficheiros distribuído da Google, separado dos nós de computação. Os controladores de cliente ligam-se aos servidores front-end do Spanner, que realizam o encaminhamento de pedidos e o equilíbrio de carga. Para saber mais, consulte o Livro branco sobre a duração das leituras e escritas do Spanner.

Em termos gerais, ambas as arquiteturas são dimensionadas à medida que são adicionados recursos ao cluster subjacente. A separação de computação e armazenamento do Spanner permite que a carga entre os nós de computação seja reequilibrada mais rapidamente em resposta às alterações da carga de trabalho. Ao contrário do Cassandra, as movimentações de fragmentos não envolvem movimentações de dados, uma vez que os dados permanecem no Colossus. Além disso, a partição baseada em intervalos do Spanner pode ser mais natural para aplicações que esperam que os dados sejam ordenados pela chave de partição. A desvantagem da partição baseada em intervalos é que as cargas de trabalho que escrevem num dos extremos do espaço de chaves (por exemplo, tabelas com chaves baseadas na data/hora atual) podem ter pontos críticos se não forem considerados designs de esquemas adicionais. Para mais informações sobre técnicas para superar pontos ativos, consulte as Práticas recomendadas de criação de esquemas.

Consistência

Com o Cassandra, tem de especificar um nível de consistência para cada operação. Se usar o nível de consistência de quórum, a maioria dos nós de réplica tem de responder ao nó coordenador para que a operação seja considerada bem-sucedida. Se usar um nível de consistência de um, o Cassandra precisa de um único nó de réplica para responder para que a operação seja considerada bem-sucedida.

O Spanner oferece uma consistência forte. A API Spanner não expõe réplicas ao cliente. Os clientes do Spanner interagem com o Spanner como se fosse uma base de dados de uma única máquina. Uma gravação é sempre escrita numa maioria das réplicas antes de o Spanner comunicar o respetivo êxito ao utilizador. Todas as leituras subsequentes refletem os dados recém-escritos. As aplicações podem optar por ler uma imagem instantânea da base de dados num momento anterior, o que pode ter vantagens de desempenho em relação às leituras fortes. Para mais informações sobre as propriedades de consistência do Spanner, consulte a vista geral das transações.

O Spanner foi criado para suportar a consistência e a disponibilidade necessárias em aplicações de grande escala. O Spanner oferece consistência forte em grande escala e com alto desempenho. Para exemplos de utilização que o exijam, o Spanner suporta leituras de instantâneos (obsoletas) que relaxam os requisitos de atualização.

Interface do Cassandra

A interface do Cassandra permite-lhe tirar partido da infraestrutura totalmente gerida, escalável e altamente disponível do Spanner através de ferramentas e sintaxe do Cassandra familiares. Esta página ajuda a compreender as capacidades e as limitações da interface do Cassandra.

Vantagens da interface Cassandra

  • Portabilidade: a interface do Cassandra oferece acesso à amplitude das funcionalidades do Spanner, através de esquemas, consultas e clientes compatíveis com o Cassandra. Isto simplifica a mudança de uma aplicação criada no Spanner para outro ambiente do Cassandra ou vice-versa. Esta portabilidade oferece flexibilidade de implementação e suporta cenários de recuperação de desastres, como uma saída forçada.
  • Familiaridade: se já usa o Cassandra, pode começar rapidamente a usar o Spanner com muitas das mesmas declarações e tipos de CQL.
  • Spanner sem compromissos: uma vez que é criada com base na fundação existente do Spanner, a interface do Cassandra oferece todas as vantagens existentes do Spanner em termos de disponibilidade, consistência e desempenho/preço sem ter de comprometer nenhuma das capacidades disponíveis no ecossistema GoogleSQL complementar.

Compatibilidade com CQL

  • Suporte do dialeto CQL: o Spanner oferece um subconjunto do dialeto CQL, incluindo a linguagem de consulta de dados (DQL), a linguagem de manipulação de dados (DML), as transações simples (LWT), as funções agregadas e de data/hora.

  • Funcionalidade do Cassandra suportada: a interface do Cassandra suporta muitas das funcionalidades do Cassandra mais usadas. Isto inclui partes essenciais do esquema e do sistema de tipos, muitas formas de consulta comuns, uma variedade de funções e operadores, e os aspetos principais do catálogo do sistema do Cassandra. As aplicações podem usar muitos clientes ou controladores do Cassandra através da ligação à implementação do protocolo de rede do Cassandra do Spanner.

  • Suporte de protocolo de cliente e de rede: o Spanner suporta as capacidades de consulta principais do protocolo de rede do Cassandra v4 através do adaptador do Cassandra, um cliente simples que é executado juntamente com a sua aplicação. Isto permite que muitos clientes do Cassandra funcionem tal como estão com uma base de dados da interface do Cassandra do Spanner, ao mesmo tempo que tiram partido do ponto final global e da gestão de ligações do Spanner, bem como da autenticação da IAM.

Tipos de dados do Cassandra suportados

A tabela seguinte mostra os tipos de dados do Cassandra suportados e mapeia cada tipo de dados para o tipo de dados do GoogleSQL do Spanner equivalente.

Tipos de dados do Cassandra suportados Tipo de dados do GoogleSQL do Spanner
Tipos numéricos tinyint (número inteiro com sinal de 8 bits) INT64 (número inteiro assinado de 64 bits)

O Spanner suporta um único tipo de dados de 64 bits de largura para números inteiros com sinal.
smallint (número inteiro com sinal de 16 bits)
int (32-bit signed integer)
bigint (número inteiro assinado de 64 bits)
float (ponto flutuante IEEE-754 de 32 bits) FLOAT32 (ponto flutuante IEEE-754 de 32 bits)
double (valor flutuante IEEE-754 de 64 bits) FLOAT64 (valor flutuante IEEE-754 de 64 bits)
decimal Para números decimais de precisão fixa, use o tipo de dados NUMERIC (precisão 38, escala 9).
varint (número inteiro de precisão variável)
Tipos de strings text STRING(MAX)

Ambos os elementos text e varchar armazenam e validam strings UTF-8. No Spanner, as colunas STRING têm de especificar o respetivo comprimento máximo. Não existe impacto no armazenamento. Isto destina-se a fins de validação.
varchar
ascii STRING(MAX)
uuid STRING(MAX)
timeuuid STRING(MAX)
inet STRING(MAX)
blob BYTES(MAX)

Para armazenar dados binários, use o tipo de dados BYTES.
Tipos de data e hora date DATE
time INT64

O Spanner não suporta um tipo de dados de tempo dedicado. Use INT64 para armazenar a duração em nanosegundos.
timestamp TIMESTAMP
duration STRING(MAX)

O Spanner não suporta um tipo de duração armazenado. Use STRING para armazenar a duração.

Tipos de contentores set ARRAY

O Spanner não suporta um tipo de dados set dedicado. Use colunas ARRAY para representar um set.
list ARRAY

Use ARRAY para armazenar uma lista de objetos escritos.
map JSON

O Spanner não suporta um tipo de mapa dedicado. Use colunas JSON para representar mapas.
Outros tipos boolean BOOL
counter INT64

Anotações de tipo de dados

A opção de coluna cassandra_type permite-lhe definir mapeamentos entre os tipos de dados do Cassandra e do Spanner. Quando cria uma tabela no Spanner com a qual pretende interagir através de consultas compatíveis com o Cassandra, pode usar a opção cassandra_type para especificar o tipo de dados do Cassandra correspondente para cada coluna. Este mapeamento é usado pelo Spanner para interpretar e converter corretamente os dados quando os transfere entre os dois sistemas de base de dados.

Por exemplo, se existir uma tabela no Cassandra com o seguinte esquema:

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  score frozen<set<int>>
  ....
  PRIMARY KEY(albumId)
)

No Spanner, usa anotações de tipo para mapear os tipos de dados do Cassandra, conforme mostrado no seguinte:

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

No exemplo anterior, a cláusula OPTIONS mapeia o tipo de dados do Spanner para o tipo de dados do Cassandra correspondente.

  • albumId (Spanner STRING(MAX)) está mapeado para uuid no Cassandra.
  • title (Spanner STRING(MAX)) está mapeado para varchar no Cassandra.
  • artists (Spanner ARRAY<STRING(MAX)>) está mapeado para set<varchar> no Cassandra.
  • tags (Spanner JSON) está mapeado para map<varchar,varchar> no Cassandra.
  • numberOfSongs (Spanner INT64) está mapeado para tinyint no Cassandra.
  • releaseDate (Spanner DATE) está mapeado para date no Cassandra.
  • copiesSold (Spanner INT64) está mapeado para bigint no Cassandra.
  • score (Spanner ARRAY<INT64>) está mapeado para frozen<set<int>> no Cassandra.
Modifique a opção cassandra_type

Pode usar a declaração ALTER TABLE para adicionar ou modificar a opção cassandra_type em colunas existentes.

Para adicionar uma opção cassandra_type a uma coluna que ainda não a tem, use a seguinte declaração:

ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');

Neste exemplo, a coluna uuid na tabela Albums é atualizada com a opção cassandra_type definida como uuid.

Para modificar uma opção cassandra_type existente, use a declaração ALTER TABLE com o novo valor cassandra_type. Por exemplo, para alterar o cassandra_type da coluna numberOfSongs na tabela Albums de tinyint para bigint, use a seguinte declaração:

ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');

Só tem permissão para modificar os seguintes tipos:

De Para
tinyint smallint, int, bigint
smallint int, bigint
int bigint
flutuante dupla
texto varchar
ascii varchar, text
Mapeamentos diretos e detalhados

Em muitos casos, o mapeamento entre os tipos de dados do Spanner e do Cassandra é simples. Por exemplo, um Spanner STRING(MAX) é mapeado para um Cassandra varchar e um Spanner INT64 é mapeado para um Cassandra bigint.

No entanto, existem situações em que o mapeamento requer mais consideração e ajuste. Por exemplo, pode ter de mapear um Cassandra smallint para um Spanner INT64.

Funções do Cassandra suportadas

Esta secção apresenta uma lista das funções do Cassandra suportadas no Spanner.

A lista seguinte mostra o suporte do Spanner para funções do Cassandra.

Tempo de vida (TTL)

Quando migrar do Cassandra, adicione uma política de eliminação de linhas à sua tabela do Spanner para usar a opção USING TTL nas declarações INSERT ou UPDATE ou o TTL do Spanner.

A lógica do TTL do Spanner opera ao nível da linha, ao contrário do Cassandra, onde a lógica do TTL pode ser aplicada ao nível da célula. Para usar o TTL do Spanner, tem de incluir uma coluna de data/hora e um intervalo de tempo na política de eliminação de linhas. O Spanner elimina a linha após esta exceder a duração especificada relativamente à data/hora.

A eliminação do TTL do Spanner não é instantânea. Um processo assíncrono em segundo plano elimina as linhas expiradas e as eliminações podem demorar até 72 horas.

Para mais informações, consulte o artigo Ative o TTL nos dados do Cassandra.

Funcionalidades do Cassandra não suportadas no Spanner

É importante compreender que a interface do Cassandra oferece as capacidades do Spanner através de esquemas, tipos, consultas e clientes compatíveis com o Cassandra. Não suporta todas as funcionalidades do Cassandra. A migração de uma aplicação Cassandra existente para o Spanner, mesmo usando a interface Cassandra, requer provavelmente alguma reformulação para acomodar capacidades Cassandra não suportadas ou diferenças no comportamento, como a otimização de consultas ou o design da chave principal. No entanto, depois de migrados, as suas cargas de trabalho podem tirar partido da fiabilidade e das capacidades multimodelos únicas do Spanner.

A lista seguinte fornece mais informações sobre as funcionalidades do Cassandra não suportadas:

  • Algumas funcionalidades da linguagem CQL não são suportadas: tipos e funções definidos pelo utilizador, data/hora de gravação.
  • Spanner e Google Cloud plano de controlo: as bases de dados com interfaces Cassandra usam o Spanner e Google Cloud ferramentas para aprovisionar, proteger, monitorizar e otimizar instâncias. O Spanner não suporta ferramentas, como nodetool, para atividades administrativas.

Compatibilidade com DDL

As declarações DDL de CQL não são suportadas diretamente através da interface do Cassandra. Para alterações de DDL, tem de usar a consola do Spanner Google Cloud , o comando gcloud ou as bibliotecas de cliente.

Conetividade

  • Suporte do cliente Cassandra

    O Spanner permite-lhe estabelecer ligação a bases de dados a partir de vários clientes:

Controlo de acesso com a gestão de identidade e de acesso

Tem de ter as autorizações spanner.databases.adapt, spanner.databases.select e spanner.databases.write para realizar operações de leitura e escrita no ponto final do Cassandra. Para mais informações, consulte a vista geral da IAM.

Para mais informações sobre como conceder autorizações de IAM do Spanner, consulte o artigo Aplique funções de IAM.

Monitorização

O Spanner fornece as seguintes métricas para ajudar a monitorizar o adaptador do Cassandra:

  • spanner.googleapis.com/api/adapter_request_count: captura e expõe o número de pedidos de adaptadores que o Spanner executa por segundo ou o número de erros que ocorrem no servidor do Spanner por segundo.
  • spanner.googleapis.com/api/adapter_request_latencies: captura e expõe a quantidade de tempo que o Spanner demora a processar pedidos do adaptador.

Pode criar um painel de controlo personalizado do Cloud Monitoring para apresentar e monitorizar métricas do adaptador do Cassandra. O painel de controlo personalizado contém os seguintes gráficos:

  • Latências de pedidos P99: a distribuição do percentil 99 das latências de pedidos do servidor por message_type para a sua base de dados.

  • Latências de pedidos P50: a distribuição do 50.º percentil das latências de pedidos do servidor por message_type para a sua base de dados.

  • Contagem de pedidos da API por tipo de mensagem: a contagem de pedidos da API por message_type para a sua base de dados.

  • Número de pedidos da API por tipo de operação: o número de pedidos da API por op_type para a sua base de dados.

  • Taxas de erro: as taxas de erro da API para a sua base de dados.

Google Cloud consola

  1. Transfira o ficheiro cassandra-adapter-dashboard.json. Este ficheiro tem as informações necessárias para preencher um painel de controlo personalizado na monitorização.

  2. Na Google Cloud consola, aceda à página  Painéis de controlo:

    Aceda a Painéis de controlo

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  3. Na página Vista geral dos painéis de controlo, clique em Criar painel de controlo personalizado.
  4. Na barra de ferramentas do painel de controlo, clique no ícone Definições do painel de controlo. Em seguida, selecione JSON e, depois, Editor de JSON.
  5. No painel Editor JSON, copie o conteúdo do ficheiro cassandra-adapter-dashboard.json que transferiu e cole-o no editor.
  6. Para aplicar as alterações ao painel de controlo, clique em Aplicar alterações. Se não quiser usar este painel de controlo, navegue novamente para a página Vista geral dos painéis de controlo.
  7. Depois de criar o painel de controlo, clique em Adicionar filtro. Em seguida, selecione project_id ou instance_id para monitorizar o adaptador do Cassandra.

CLI gcloud

  1. Transfira o ficheiro cassandra-adapter-dashboard.json. Este ficheiro tem as informações necessárias para preencher um painel de controlo personalizado na monitorização.

  2. Para criar um painel de controlo num projeto, use o comando gcloud monitoring dashboards create:

    gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json

    Para mais informações, consulte a gcloud monitoring dashboards create referência.

Além disso, as seguintes métricas do Spanner são úteis para monitorizar o adaptador do Cassandra:

Para ver uma lista completa das estatísticas do sistema, consulte o artigo Monitorize instâncias com estatísticas do sistema. Para saber mais sobre a monitorização dos seus recursos do Spanner, consulte o artigo Monitorize instâncias com o Cloud Monitoring.

Preços

Não existe qualquer custo adicional pela utilização do ponto final do Cassandra. É-lhe cobrado o preço padrão do Spanner pela quantidade de capacidade de computação que a sua instância usa e a quantidade de armazenamento que a sua base de dados usa.

Para mais informações, consulte os preços do Spanner.

O que se segue?