Bancos de dados relacionais versus NoSQL para tráfego de APIs

O consumo da API é o que conduz a importância do tráfego da API. Sem informações sobre como uma APIs está sendo consumida, o desenvolvedor é incapaz de obter os dados de clientes e de uso da API.

Os dados de tráfego da API possuem algumas características; alta frequência, tamanhos de carga útil, estrutura de dados, tabelas, volume e objetos. A persistência no tráfego da API é importante porque a maioria dos serviços possui algum tipo de limitação de taxa e de níveis de cobrança diferente para clientes com base em seu uso. Geralmente, há um limite para alerta e escala, por isso, se alguém está usando mais chamadas de API do que deveria, é possível simplesmente particioná-las. O desenvolvedor também quer ser capaz de fornecer dados para a sua organização interna das diferentes APIs/recursos que estiver expondo. Se existem clientes expondo uma API, é provável que estejam fazendo a integração com outros serviços também, o que lhes permite fatiar e cortar os dados com outros dados que estão consumindo de um determinado produto.

Existem diferenças entre requisições de payloads típicas de uma API e payloads de resposta. Os dados solicitados versus dados de resposta podem alterar o formato da estratégia persistente. Com solicitações de payloads, geralmente o que se obtém são payloads de tamanhos grandes a moderados. Cerca de 80% das solicitações de API são solicitações GET, sendo que as solicitações POST também podem ser grandes. As payloads de resposta também são tipicamente grandes em tamanho. As estruturas de dados são indeterminadas, o que significa que quando o desenvolvedor tenta executar análises de dados, a tabela pode ser grande e o fatiamento das respostas de dados também pode ser variável.

Estabelecendo que a persistência dos dados é a melhor opção, muitos vão olhar para algum banco de dados SQL, considerando que já estão usando um. A questão é se um banco de dados NoSQL deve ser considerado. O SQL, tendo mais de 40 anos de idade, é a interface primária para o RDMBS e, possuindo implementações comerciais e de código aberto, é uma consideração forte.

O NoSQL, por outro lado, existe desde a década de 1960 e foi o mecanismo de armazenamento primário antes do SQL tornar-se popular. E ganhou mais tração nos últimos 10 anos.

Tendo a comparação das duas tecnologias nos tópicos abaixo, os principais fatores no processo de tomada de decisão são: o volume de crescimento dos dados, dados online versus dados arquivados, flexibilidade dos filtros de pesquisa, o desempenho da pesquisa, clustering e sharding. Ao decidir qual é melhor para você, considere a medida do tráfego de entrada da API atual, a política de retenção de dados, a estimativa do volume de crescimento desses dados, e se seus clientes precisam de um forte fatiamento.

Características principais

 

SQL

– Modelo relacional com os dados organizados em uma estrutura tabular
– Estrutura de esquema pré-definido
– Em geral, é verticalmente escalável  – o que acarreta custo mais elevado das VMs
– Interface query poderosa e padronizada
– A maioria das implementações são ACID-compliant 

NoSQL

– Modelo diferente – documento, grafo, chave-valor
– Estrutura de esquema dinâmico
– Horizontalmente escalável  – menor custo das VMs
– Interface query varia conforme o fornecedor
– Segue o CAP (Consistência, Disponibilidade, Particionamento) 

É possível usar o armazenamento de dados SQL para:

– Tamanhos gerenciável de de dados
– Período de tempo baixo ou políticas de retenção baseadas em tamanho
– Baixa frequência de uso
– Analytics leve
– Interface query que precisa de padrões

É possível usar NoSQL quando/para:

– Escala e volume são importantes
– Analytics em profundidade se faz necessário
– Queries rápidas são fundamentais
– Você pode viver com uma interface query não padronizada

Fonte: DZone.com

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.