ScyllaDB - Um Banco de Dados NoSQL para Big Data

ScyllaDB: um banco de dados NoSQL para Big Data.

ScyllaDB é um sistema gerenciador de banco de dados NoSQL, realtime, voltado para o ambiente de Big Data. É uma solução robusta de banco de dados utilizada pela Samsung SDS, Intel e outras empresas da Fortune Global 500 (uma classificação das 500 maiores corporações do mundo). Mas, quando se fala na adoção de qualquer solução tecnológica, é importante que as partes interessadas na tecnologia entendam suas vantagens, desvantagens e onde se aplica para que a escolha seja condizente com as necessidades de negócio. Esta discussão ficará para o fim do artigo. E neste artigo você será introduzido a uma visão geral do ScyllaDB, sua arquitetura, conceitos importantes, também colocará as mãos na massa e verá algumas das vantagens e desvantagens de seu uso.

SQL e NoSQL

A primeira característica a ser observada no ScyllaDB é a sua qualidade como NoSQL. SQL significa Structured Query Language, que é uma linguagem estruturada de consulta, utilizada pela maioria dos Sistemas Gerenciadores de Banco de Dados Relacional (SGBDR) e é fortemente padronizada pela American National Standards Institute (ANSI).

Bancos de dados relacionais consideram a possibilidade de uma tabela ter relação com outra através da associação de chaves, em que uma chave estrangeira, de uma tabela B, pode referenciar a chave primária de uma tabela A.

Tabela Pessoa e Tabela Consulta

Exemplo de relação entre tabelas estabelecida pela chave estrangeira "id_pessoa".

NoSQL significa "no SQL" (sem uso de SQL para consultas) ou "not only SQL" (que implica no uso de métodos SQL e NoSQL para consultas). Métodos NoSQL são geralmente utilizados em bancos de dados não-relacionais — bancos que não são projetados para suportar chaves estrangeiras e união entre tabelas.

Ao contrário do SQL, não há um órgão padronizador para o NoSQL; bancos de dados NoSQL diferem em como são construídos, quais são os tipos de dados suportados e também como armazenam dados e realizam consultas. Bancos de dados não-relacionais possuem uma certa variedade de tipos, dentre os quais o ScyllaDB é classificado como colunar.

Classificação genérica para tipos de bancos de dados NoSQL.

A imagem abaixo ilustra alguns bancos de dados NoSQL, classificados de acordo com o seu tipo.

Bancos de dados NoSQL classificados por tipo.

Bancos de dados colunares são otimizados para recuperação rápida de coluna de dados. Veja a tabela a seguir como um exemplo para ilustrar esse comportamento. A tabela contém a lista de estados brasileiros, ordenados por IDHM (Índice de Desenvolvimento Humano Municipal). Agora, considere uma query que retorna o IDHM médio do Brasil por estado.

ID	ESTADO	IDHM
1	Distrito Federal	0.824
2	São Paulo	0.783
3	Santa Catarina	0.774
4	Rio de Janeiro	0.761
5	Paraná	0.749
6	Rio Grande do Sul	0.746
7	Espírito Santo	0.740
8	Goiás	0.735
9	Minas Gerais	0.731
10	Mato Grosso do Sul	0.729
11	Mato Grosso	0.725
12	Amapá	0.708
13	Roraima	0.707
14	Tocantins	0.699
15	Rondônia	0.690
16	Rio Grande do Norte	0.684
17	Ceará	0.682
18	Amazonas	0.674
19	Pernambuco	0.673
20	Sergipe	0.665
21	Acre	0.663
22	Bahia	0.660
23	Paraíba	0.658
24	Piauí	0.646
24	Pará	0.646
26	Maranhão	0.639
27	Alagoas	0.631

(Fonte: Programa das Nações Unidas para o Desenvolvimento - PNUD, 2010)

Consulta por linha em um banco de dados SQL genérico:

Carrega cada uma das 27 linhas em memória

Carrega todas as colunas de cada linha

Aplica AVG() na coluna IDHM
Retorna o resultado

Consulta por coluna em um banco de dados NoSQL colunar:

Carrega a coluna IDHM
Aplica AVG() na coluna IDHM
Retorna o resultado

Resultado: 0,705

Caso a tabela contivesse o IDMH de todos os municípios do Brasil e também outras colunas — como IDHM de Renda, Longevidade e Educação — então seria necessário, em um banco de dados orientado a linhas, carregar 5.565 registros, desde São Caetano do Sul (SP) até Melgaço (PA). Já no banco de dados colunar, bastava carregar a coluna desejada em memória.

Abordagem orientada a linha vs abordagem orientada a coluna
Exemplo fictício, IDHM de SP

A rapidez torna-se um fator importante para consultas analíticas, pois ela diminui operações de I/O e traz a vantagem de ter que carregar menos dados do disco em memória. Esse agrupamento homogêneo de dados também facilita o uso de algoritmos de compressão para armazenamento, que faz com que os dados ocupem menos espaço em disco do que em um banco relacional genérico.

Arquitetura do Scylla

Em Big Data trabalha-se com um grande volume de dados na casa dos terabytes (1.000 gigabytes) ou petabytes (1.000 terabytes). Armazenar toda essa quantidade de dados em um único local pode ser perigoso devido vários motivos, sendo alguns deles:

Indisponibilidade: se o sistema de banco de dados falhar ou ficar inacessível, todos os sistemas dependentes serão afetados.
Crescimento vegetativo: dependendo da volumetria de dados, em algum momento o armazenamento poderá chegar a sua capacidade máxima. Caso seja possível, o escalonamento vertical pode oferecer mais recursos de hardware para o banco e resolver esse problema (mas somente enquanto for possível escalonar).

Para resolver problemas de armazenamento como esses que foram citados, o ScyllaDB foi funcionalmente projetado para trabalhar dentro de uma arquitetura com nós distribuídos e garantir a disponibilidade do dado. O Scylla encontra-se entre dois pilares do Teorema do CAP: disponibilidade e tolerância de partição.

ScyllaDB no Teorema do CAP
(Foto: Divulgação / Scylla)

De acordo com o Teorema do CAP, a consistência, disponibilidade e tolerância de partição são mutuamente dependentes em um sistema distribuído. Aumentar qualquer um desses dois fatores implica na redução de um terceiro. Sobre o CAP:

(C) Consistência: garante que todos os nós contenham o mesmo dado.
(A) Disponibilidade: toda requisição será atendida e retornará com sucesso ou erro.
(P) Tolerância de partição: o sistema continua a trabalhar mesmo que parte esteja indisponível, pois ele está distribuído em nós independentes (abordagem conhecida como shared-nothing).

Há três categorias descritas pelo CAP. A primeira reflete o nosso problema-exemplo, em que há o CA. Ou seja, há a garantia da consistência do dado, pois ele é o mais recente e também há a disponibilidade para ser consultado. Sistemas Gerenciadores de Bancos de Dados Relacionais são classificados como CA, como o MySQL, PostgreSQL etc.

O Scylla trabalha em cluster com uma Arquitetura de Anel (Ring Architecture).

Ring Architecture do ScyllaDB
(Foto: Divulgação / Scylla)

Um cluster é um agrupamento de nós que trabalham em conjunto. Um nó representa uma instância do ScyllaDB.

Essa abordagem arquitetural adotada pelo ScyllaDB foi herdada do Cassandra, banco de dados na qual o ScyllaDB é análogo. Para um melhor entendimento de como essa arquitetura trabalha, vamos a um exemplo simples.

Supondo que existem 5 nós (nó 0, 1, 2, 3 e 4), toda vez que houver uma requisição de gravação, será necessário gravar o dado em um dos cinco nós do cluster. Um exemplo bem simples e fictício usando mod (resto da divisão) seria:

requisição 1 mod 5 = 1, então grava o dado no segundo nó (nó 1)
requisição 2 mod 5 = 2, então grava o dado no terceiro nó (nó 2)
requisição 3 mod 5 = 3, então grava o dado no quarto nó (nó 3)
requisição 4 mod 5 = 4, então grava o dado no quinto nó (nó 4)
requisição 5 mod 5 = 0, então grava o dado no primeiro nó (nó 0)
requisição 6 mod 5 = 1, então grava o dado no segundo nó (nó 1)
requisição 7 mod 5 = 2, então grava o dado no terceiro nó (nó 2)
...

Neste exemplo fictício, o operador mod retorna o resto da divisão, que determina em qual nó será gravado o dado. Então, para determinar onde um dado será gravado, temos três elementos importantes:

A entrada: um valor para se efetuar um cálculo.
O cálculo: que neste exemplo é o resto da divisão do número da requisição pelo total de nós.
A saída: obtida pelo cálculo que determina onde dado será gravado.

Saindo deste exemplo ficcional e indo para a forma como o banco trabalha:

Distribuição de dados dentro dos nós do cluster.
(Foto: Divulgação / Scylla)

No lugar do número da requisição, a entrada utilizada para o cálculo é a chave da partição. Esse valor é obtido da chave-primária do registro a ser inserido.
O cálculo consiste em uma função hash que retorna um valor entre -2⁶³ e +2⁶³-1.
O valor obtido do cálculo é um token que indica onde o dado será gravado.

Um dado pode ser gravado em um nó e replicado em outros. A quantidade de nós em que o dado será gravado depende do fator de replicação (RF - replication factor). O fator de replicação é configurado na keyspace, nome usado para designar um contêiner de tabelas, análoga a uma database em termos de bancos de dados relacionais.

Observação: o nó que recebeu a requisição de gravação não necessariamente gravará o dado em si. Ele é chamado de "coordinator" e pode reencaminhar a requisição para outros nós disponíveis gravarem o dado. Após reencaminhar a solicitação, ele aguarda a confirmação da gravação. O número de nós necessários para confirmar a gravação determina o nível de consistência (CL - consistence level).

Exemplo de escrita com replicação no ScyllaDB.
(Foto: Divulgação / Scylla)

No Scylla também não há nó mestre/líder ou escravo/slave, portanto a requisição pode ser atendida por qualquer nó.

Hands-on

O ScyllaDB está disponível em versões open source, enterprise e cloud based. Utilizaremos a versão open source em Docker como exemplo.

Configurando o cluster

Criando uma instância do Scylla:

docker run --name No_Z -d scylladb/scylla:3.0.10
docker ps

Quando o nó estiver disponível (up), através da ferramenta nodetool é possível ver informações da instância:

docker exec -ti No_Z nodetool status

Resultado:

Instância do ScyllaDB em execução na "máquina" 172.17.0.2.

Agora, criaremos mais 4 instâncias do ScyllaDB que formarão o cluster.

docker run --name No_V -d scylladb/scylla:3.0.10 --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' No_Z)"
docker run --name No_W -d scylladb/scylla:3.0.10 --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' No_Z)"
docker run --name No_X -d scylladb/scylla:3.0.10 --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' No_Z)"
docker run --name No_Y -d scylladb/scylla:3.0.10 --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' No_Z)"

Para que uma instância ache o cluster é preciso configura-lá para encontrar um nó no primeiro momento em que é inicializada. O nó escolhido foi o Z, que estava UP. Seu IP foi recuperado via docker inspect e passado para o parâmetro "seed". Leia mais aqui para entender como é feita a configuração de seeds em um cluster sem o Docker.

Ao executar o utilitário nodetool em qualquer nó, é possível ver que há cinco máquinas conectadas, cada uma com seu IP e executando uma instância do ScyllaDB.

Cluster com cinco nós de ScyllaDB

Criando keyspace e tabela

A interface shell do ScyllaDB se chama CQLSH. Nela, criaremos keyspaces e tabelas como exemplo.

docker exec -ti No_V cqlsh

No shell do Scylla, execute:

CREATE KEYSPACE produtos WITH REPLICATION = {'class': 'SimpleStrategy', 'replication_factor': 3};
USE produtos;
CREATE TABLE frutas (
 id_fruta INT,
 nome TEXT,
 valor DECIMAL,
 PRIMARY KEY (id_fruta)
);

Note que o fator de replicação é igual a 3. Isso significa que o dado inserido em um nó A será replicado também no nó B e C. Para consultar todas as informações da keyspace produtos, basta usar o comando CQL "desc produtos;".

Inserindo e consultando registros

Insira esses registros:

INSERT INTO frutas (id_fruta, nome, valor) VALUES (1, 'Maçã', 5.41);
INSERT INTO frutas (id_fruta, nome, valor) VALUES (2, 'Pera', 7.50);
INSERT INTO frutas (id_fruta, nome, valor) VALUES (3, 'Limão', 2.10);

Depois, consulte-os com SELECT * FROM frutas;. Esse é o resultado esperado:

Inserindo e consultando registros no ScyllaDB

Testando a replicação de dados

A tabela a seguir mostra a relação entre os nós criados e os IPs que foram atribuídos para este exemplo:

Nó	IP
Z	172.17.0.2
V	172.17.0.3
W	172.17.0.4
X	172.17.0.5
Y	172.17.0.6

Nota: você pode realizar a consulta de IP usando o comando:
docker inspect --format="{{ .NetworkSettings.IPAddress }}" NOME_DO_CONTÊINER

No exemplo deste artigo, quando a tabela e a keyspace foram criadas, a conexão foi estabelecida com o nó V (IP 172.17.0.3), logo, ele é o coordinator.

Como sabemos, a partir da chave-primária de cada registro é gerada uma partition key, em que é aplicada uma função hash e a partir dela é criado um token. Esse token determina onde um dado gerá gravado (cada nó possui um range de tokens, conforme já mencionado). Isso significa que não necessariamente nossos registros foram gravados no nó V.

Consulte o token dos registros:

SELECT token(id_fruta), id_fruta FROM produtos.frutas;

Resultado esperado:

Consultando os tokens de cada registro inserido

Através desses tokens é possível usar o utilitário nodetool para descobrir onde cada dado foi gravado. Abra uma nova aba em seu terminal e execute os seguintes comandos:

docker exec -ti No_V /bin/bash
nodetool getendpoints produtos frutas TOKEN_1o_REGISTRO
nodetool getendpoints produtos frutas TOKEN_2o_REGISTRO
nodetool getendpoints produtos frutas TOKEN_3o_REGISTRO

O comando "getendpoints", do nodetool, recebe três argumentos: keyspace, tabela e token. Note, na imagem abaixo, que cada registro foi inserido e replicado em mais outros dois nós. E que coincidentemente nenhum registro foi gravado no nó V (172.17.0.3), que recebeu a requisição. O registro que contém a Maçã, por exemplo, foi inserido e replicado nos nós Z, W e X (consulte a tabela anterior para conferir).

Consultando os nós onde cada dado foi replicado

Isso significa que quando executamos o SELECT * FROM produtos.frutas; os registros foram recuperados, coluna por coluna, de outros nós.

Testando tolerância de partição e disponibilidade

Se por algum motivo alguns nós caírem, e dois deles forem onde o nosso dado está armazenado, há pelo menos mais uma cópia no outro. Tomemos como exemplo os nós onde o registro "Maçã" foi gravado.

No terminal, execute os seguintes comandos:

docker stop NOME_DO_No_1 NOME_DO_No_2 # nome dos contêineres onde o dado foi replicado
docker exec -ti NOME_DE_UM_No_UP nodetool status # verificando o status do cluster
docker exec -ti NOME_DE_UM_No_UP cqlsh # executando o shell do Scylla

No shell do Scylla, execute:

SELECT * FROM produtos.frutas; -- verificando a disponibilidade dos dados

Como resultado, duas máquinas deverão estar com status de DOWN, mas mesmo assim devemos ter acesso aos nossos dados, como os do registro da "Maçã":

O registro Maçã continua disponível mesmo após a queda de dois nós

Vantagens e desvantagens do ScyllaDB

O ScyllaDB é um banco de dados NoSQL voltado para o ambiente de Big Data. Seu uso traz vantagens e desvantagens, se aplica em alguns cenários e em outros não.

Vantagens

O ScyllaDB foi inspirado no Apache Cassandra, que é escrito em Java e roda sobre uma JVM. Apesar da inspiração, o ScyllaDB foi reimplementado em C++. A sua performance em relação ao Cassandra é contrastante e também é uma boa opção para redução de custo em nós, diminuição de latência e melhor aproveitamento do poder computacional do hardware. O Scylla também oferece um ótimo suporte para migração de dados.

Uma de suas vantagens é a velocidade, performance para trabalhar
com grandes volumes de dados e lidar com alto TPS (transações por segundo)
(Foto: Divulgação / Scylla)

Uma vantagem que se mostrou nítida nesse artigo, também, é o escalonamento horizontal. É possível criar um cluster e replicar os dados de um nó para outros, garantindo sua alta disponibilidade.

Desvantagens

Não é um banco de dados relacional, então seu uso como tal deve ser cuidadosamente pensado para que não haja problemas na modelagem de dados e arquitetura do projeto. Não é possível usar união de tabelas, pois não há integridade referencial por não suportar o uso de chaves estrangeiras.

Uma outra desvantagem é a consistência eventual. De acordo com o Teorema do CAP, como o Scylla está mais próximo da disponibilidade e partição de tolerância, um dado estar disponível não necessariamente significa que ele será o mais atualizado. É possível consultar um dado desatualizado caso alguns cuidados não sejam tomados e por isso existe o repair (um processo para sincronizar os dados entre os nós do cluster) para evitar e corrigir esse tipo de indesejável.

Conclusão

Discorremos um pouco sobre o mundo não-relacional, seus tipos e então estudamos o básico da arquitetura do ScyllaDB, suas principais características e aplicamos os conceitos através de seu uso por meio de contêineres Docker. O objetivo do artigo não foi aprofundar sobre o banco, por isso muitos temas foram superficialmente tratados como consistence level, multi-datacenter e tópicos avançados. Porém, estes mesmo assuntos podem ser consultados na documentação da referência bibliográfica.

O ScyllaDB é uma boa solução como banco de dados NoSQL para se trabalhar com Big Data. Como qualquer tecnologia, seu uso implica em algumas vantagens e desvantagens, embora aqui não seja tratadas todas elas. Mas cabe aos interessados estudar e alinhar o uso da tecnologia às necessidades de negócio e viabilidade no projeto.

Referência Bibliográfica

ATLAS DO DESENVOLVIMENTO HUMANO NO BRASIL. Ranking: todo o Brasil em 2010. Disponível em <http://www.atlasbrasil.org.br/2013/pt/ranking/>. Acesso em 17 jan. 2020.

AWS. O que é um banco de dados em colunas?. Disponível em <https://aws.amazon.com/pt/nosql/columnar/>. Acesso em 17 jan. 2020.

DEHDOUH, Khaled et al. Using the column oriented NoSQL model for implementing big data warehouses. In: Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA). The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp), 2015. p. 469.

DZONE. Understanding the CAP Theorem. Disponível em <https://dzone.com/articles/understanding-the-cap-theorem>. Acesso em 17 jan. 2020.

NEO4J. Graph Databases for Beginners: Why We Need NoSQL Databases. Disponível em <https://neo4j.com/blog/why-nosql-databases/>. Acesso em 17 jan. 2020.

SCYLLA. SQL vs NoSQL Difference. Disponível em <https://www.scylladb.com/resources/nosql-vs-sql/> . Acesso em 17 jan. 2020.

SCYLLA UNIVERSITY. NoSQL and Scylla. Disponível em <https://university.scylladb.com/courses/scylla-essentials-overview/lessons/introduction/topic/nosql-and-scylla/>. Acesso em 17 jan. 2020.

SCYLLA. Scylla Architecture: Fault Tolerance. Disponível em <https://docs.scylladb.com/architecture/architecture-fault-tolerance/>. Acesso em 17 jan. 2020.

SCYLLA. Scylla Ring Architecture: Overview. Disponível em <https://docs.scylladb.com/architecture/ringarchitecture/>. Acesso em 17 jan. 2020.

SCYLLA DOCS. Create a Scylla Cluster: Single Data Center (DC). Disponível em <https://docs.scylladb.com/operating-scylla/procedures/cluster-management/create_cluster/#example>. Acesso em 17 jan. 2020.

SCYLLA. New Benchmark: Scylla 2.2 (i3.Metal x 4-nodes) vs Cassandra 3.11 (i3.4xlarge x 40-nodes). Disponível em <https://www.scylladb.com/2018/07/06/scylla-vs-cassandra-ec2/>. Acesso em 17 jan. 2020.

Para citar esse artigo:

Autociência

Pesquisar este blog