Group Discussion: NoSQL and CAP Theorem
Requisitos de finalización
Students will work in groups to create a Wiki comparing major NoSQL databases. If you did not work before with Moodle Wikis, see this small video (3:36 min.) on the Wiki activity page.
Student Groups
Our goal here is to understand the CAP Theorem and to know the advantages and disadvantages of some NoSQL solutions. There will be four groups. All the wikis will have the following content:
- DB Name
- Student List (with name and USP id)
- Main DB Features
- Does It Implement CA, CP, or AP? Why?
- DB Advantages
- DB Disadvantages
- Application Niches
They will also make a 22 minutes presentation of their work to the class.
Each group has to choose:
- Coordinator: To coordinate the discussions and group activities. He also has to control the time to make sure the group will post its results on time.
- Editor: To write down the group's contents to the wiki.
- Three Presenters: To present the work to the class
A group may divide the work among subgroups, but, in this case, it is recommended that you plan some time to join the work of each subgroup.
Tip: If you use Google Docs or Slides to create your work, you may just link it to the group's wiki page. But remember to make it readable by everyone and copy its text to the wiki (just as a backup).
Atrás
Cassandra DB
Viendo la versión de página #2
(Restaurar esta versión)
(Restaurar esta versión)
Modificado: 13 de junio de 2025, 09:45 Usuario: Felipe Carneiro Machado → FC
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Cassandra DB</title>
</head>
<body>
<h1>Cassandra DB</h1>
<h2>O que é o Apache Cassandra e como funciona sua arquitetura?</h2>
<p>O Apache Cassandra é um banco de dados NoSQL de colunas largas concebido para lidar com petabytes de dados em clusters distribuídos, oferecendo latências muito baixas tanto para leitura quanto para escrita. O projeto nasceu no Facebook entre 2007 e 2008 para suportar o sistema de busca de mensagens internas; foi liberado como código aberto em julho de 2008, transferido à Apache Software Foundation em 2009 e promovido a projeto de primeiro nível em março de 2010. Desde então, tornou-se referência para workloads que exigem escalabilidade horizontal praticamente ilimitada, zero downtime e suporte nativo a múltiplos datacenters.
<br>
Seu grande diferencial está na arquitetura “masterless”: todos os nós de um cluster Cassandra são iguais (peer-to-peer) e podem atender leituras ou gravações diretamente, eliminando qualquer ponto único de falha. Os dados são particionados através de consistent hashing em um anel lógico de tokens; isso faz com que a adição ou remoção de servidores exija pouquíssimo rebalanceamento e permita escalabilidade linear — adicionar um nó comum equivale, em média, a multiplicar a capacidade agregada disponível. A combinação de design descentralizado e distribuição uniforme de dados sustenta o alto rendimento que tornou Cassandra popular em empresas como Netflix, Uber e Apple.
<br>
Para garantir resiliência, o sistema oferece replicação configurável por keyspace: o desenvolvedor escolhe o fator de réplica e quais datacenters devem receber cópias, obtendo tolerância a falhas de rack, zona ou região. O estado do cluster é mantido pelo protocolo Gossip, no qual, a cada segundo, cada nó troca informações de saúde e esquema com alguns pares, propagando rapidamente qualquer mudança. Em caso de indisponibilidade transitória, mecanismos como hinted handoff e reparos anti-entropia recuperam as réplicas divergentes, assegurando consistência eventual sem sacrificar disponibilidade. Essa combinação de replicação elástica, monitoramento distribuído e recuperação automática consolida Cassandra como solução de escolha para serviços que precisam permanecer online mesmo diante de falhas de rede ou equipamentos.
<br>
</p>
<h2></h2>
</body>
</ht