Gadget Lateral

Como chegamos as bases de dados NoSQL?

Partilhar
dePublicado em

Durante décadas, os bancos de dados relacionais é que dominavam o mundo das aplicações empresariais, financeiras, académicas e até das primeiras plataformas web. MySQL, Oracle, PostgreSQL e SQL Server eram praticamente as únicas escolhas possíveis e, na maioria dos casos, funcionavam bem. Já tinham algumas décadas de maturidade, possuiam ferramentas robustas, e cumpriam com aquilo que prometiam, a ideia de armazenar dados de forma estruturada, com consistência e segurança.

Mas a tecnologia não ficou parada. A internet expandiu-se numa velocidade que ninguém previa, novas empresas começaram a lidar com escala global, e a forma como os dados eram gerados mudou radicalmente.

E é aqui que começa a história do NoSQL.

1. Antes do NoSQL

Para entender o nascimento do NoSQL, precisamos de lembrar o contexto.

Durante muitos anos, as aplicações tinham:

  • Bases de dados relativamente pequenas (comparadas com hoje)
  • Padrões de escrita previsíveis
  • Um tráfego que podia ser suportado por um único servidor
  • Esquemas rígidos que faziam sentido para aplicações de negócio tradicionais

Tudo isto se encaixava perfeitamente no modelo relacional. Mas, a partir dos anos 2000, surgiram novas necessidades:

  • Redes sociais
  • Plataformas de streaming
  • E-commerce global
  • Jogos massivos online
  • Big Data
  • Sensores IoT
  • Dispositivos móveis a gerar dados 24/7

De repente, um único servidor já não era suficiente, as escritas aumentaram de forma exponencial e para manter as transações ACID estritas tornou-se caro demais para sistemas com milhões de requisições por segundo. Com isso, o modelo relacional continuava funcional, mas já não servia para tudo.

2. O Surgimento do termo NoSQL

Um facto curioso é que NoSQL não nasceu como uma tecnologia e nem sequer nasceu como um manifesto técnico (como aquelas ideias dos manifestos ágeis), nem como uma forma de acabar com aos bancos de dados relacionais, mas sim NoSQL nasceu como um hashtag no X (o antigo Twitter).

Em 2009, um engenheiro chamado Johan Oskarsson organizou um meetup sobre novos bancos open-source, distribuídos e não-relacionais. Na altura, estes sistemas ainda eram pouco conhecidos e usados sobretudo por grandes empresas como Google e Amazon.

Para divulgar o evento, utilizaram o hashtag: 

#NoSQL

Não havia nenhuma intenção filosófica profunda só queriam apenas uma palavra curta e chamativa para usar no Twitter.

Mas o termo pegou, causou impacto, e começou a circular rapidamente na comunidade de startups, de repente, NoSQL deixou de ser apenas um hashtag e passou a ser uma tendência tecnológica mundial. Devido ao sucesso que teve, o nome foi reinterpretado de forma mais amigável:

NoSQL → Not Only SQL

Ou seja, não se trata de rejeitar SQL, mas sim de expandir o leque de opções.

3. Porque se precisava de algo além de SQL?

Existem quatro motivos que explicam porque o NoSQL ganhou tanta força tão rapidamente.

3.1 A necessidade de escalabilidade massiva

Os bancos de dados relacionais foram idealizados numa época em que:
  • O hardware era caro
  • Os dados eram relativamente pequenos
  • O tráfego era limitado
A arquitetura típica era:
  • Escala vertical (scale-up) - Comprar um servidor maior, com mais CPU, mais RAM, mais disco.
Só que na era da Web 2.0 (a mudança na forma como a internet é utilizada, passando de sites estáticos para plataformas interativas onde os usuários criam e compartilham conteúdo), esse modelo simplesmente parou de funcionar, porque as empresas começaram a lidar com:
  • Bilhões de registos
  • Petabytes de dados
  • Milhões de escritas por segundo
  • Necessidade de replicar dados globalmente
E aumentar o servidor indefinidamente simplesmente não era viável seja financeiramente e nem tecnicamente.
Enquanto que o NoSQL trouxe um modelo oposto:
  • Escala horizontal (scale-out)
  • Usar muitos servidores simples, baratos, distribuindo os dados entre eles
Tecnologias como Cassandra, MongoDB, Riak e HBase especializaram-se nisso.

3.2 Preferência crescente por software livre

As startups começaram a evitar soluções caras como Oracle e SQL Server, porque haviam várias opções de soluções gratuitas ou seja open-source, por exemplo:
  • MongoDB → gratuito
  • Cassandra → gratuito
  • Redis → gratuito
  • CouchDB → gratuito
Isso tornou o NoSQL muito atraente para empresas jovens, que precisavam escalar sem gastar milhões.

3.3 Novos tipos de aplicações exigiam novas formas de consulta

O esquema de bancos relacionais é excelente para consultas estruturadas, pois une tabelas, o que ajuda a manter a consistência transacional, etc. Mas muitos cenários modernos não se encaixam nesse modelo. Por exemplo:
  • Redes sociais precisam de grafos (amizades, conexões, relações)
  • Motores de recomendação precisam de consultas por proximidade
  • Indexação de texto exige busca full-text
  • Dados semi-estruturados (JSON) mudam com frequência
  • O NoSQL ofereceu modelos especializados:
  • Documentos (MongoDB)
  • Chave-valor (Redis)
  • Colunas largas (Cassandra, HBase)
  • Grafos (Neo4j, ArangoDB)
Ou seja:
Para certas aplicações, estes modelos são simplesmente melhores do que o modelo dos bancos tradicionais relacionais.

3.4 Banco de dados menos flexível

Num banco de dados relacional, qualquer alteração exige, migrar tabelas, parar a aplicação, ajustar constraints, alterar várias camadas do sistema, enquanto que num ambiente onde a inovação deve flexível, isto acaba criando um atraso no desenvolvimento, por outro lado o modelo de documentos por exemplo, permite, guardar registos que não têm exactamente os mesmos campos, você pode também evoluir o formato dos dados conforme a aplicação cresce, e experimentar tudo de forma rápida.

4. O que realmente significa NoSQL?

É comum pensar que NoSQL é uma tecnologia ou um tipo específico de banco de dados. Mas a verdade é que NoSQL é como um guarda-chuva com várias categorias de armazenamento, cada uma desenhada para problemas específicos.

As principais categorias:

1. Key-Value Stores
  • Simples, extremamente rápido
  • Usados para caches, sessões e filas
  • Ex.: Redis, Amazon DynamoDB
2. Document Stores
  • Armazenam dados em JSON
  • Perfeitos para aplicações web e mobile
  • Ex.: MongoDB, CouchDB
3. Wide Column Stores
  • Escalam absurdamente bem
  • Ideais para Big Data e analytics distribuído
  • Ex.: Apache Cassandra, HBase
4. Graph Databases
  • Excelente para relações complexas
  • Ex.: Neo4j, ArangoDB, JanusGraph
Cada categoria resolve um problema específico.
Daí o termo ter evoluído para:
Not Only SQL, pois isso que actualmente usamos SQL e NoSQL como complementares.

5. A ideia de Polyglot Persistence

Uma das conclusões mais importantes do movimento NoSQL é que:
Não existe um tipo de banco de dados que seja perfeito para tudo.
E isso levou ao conceito de persistência poliglota, o que significa, usar vários bancos de dados diferentes na mesma aplicação, cada um para o seu propósito específico.
Exemplo de uma aplicação moderna:

Subsystem                             Melhor tecnologia
      Sessões de login                             Redis (Key-Value)
      Catálogo de produtos                             MongoDB (Documentos)
      Inventário                             PostgreSQL (Relacional)
      Sistema de recomendação                             Neo4j (Grafos)
      Log de eventos                                     Cassandra (Colunas largas)

Com isso é fácil perceber que nenhum banco sozinho consegue atender a todas estas necessidades com a mesma eficiência.



Enviar um comentário
Labels, ,

Comentários