Existem 4 categorias principais de bancos NoSQL: chave-valor, documento, grafo e família de colunas. O Apache Cassandra é um banco de dados NoSQL altamente escalável e tolerante a falhas que armazena dados no formato de famílias de colunas e oferece eventual consistência.
2. Existem 4 categorias de Bancos NoSQL
• ChaveValor
o A categoria mais simples de bancos, armazena os dados no formato chave valor
ou chave e hash.
o Ex.: Riak, Redis
• Documento
o Armazena dados em forma de documentos, na maioria das vezes JSON.
o Ex.:CouchDB, MongoDB
• Grafo
o Dados armazenados no formato de grafo, permitindo alto nível de
relacionamento .
o Ex.: Neo4J
• Família de Colunas
o Dados armazenados no formato de linhas e colunas múltiplias, como uma
planilha de texto.
o Ex.:Cassandra
3. OApache cassandra é um banco de dados altamente escalável, sem ponto único de
falha, elástico, eventualmente consistente.
É o AP do CAP
Não é ACID ( Atomicidade, Consistência, Isolamento, Durabilidade)
Mas é BASE (BasicallyAvailable, Soft state, Eventual consistency)
• BasicallyAvailable – Se um nó falhar, uma parte da informação pode não ficar
disponível
• Soft state – Informação será deletada caso não seja necessária.
• Eventual consistency – Informação atualizada pode não estar replicada em todos
os nós do cluster
4.
5. OApache Cassandra tem formas de minimizar seus “problemas”
• Consistência customizada:
o ONE
o QUORUM (Métade da replicação necessária + 1)
o ALL
Porém quanto maior a consistência, maior a latência.
• Replicação
o Uma informação é replicada em N nós diferentes para no caso de uma
possível falha em um nó, aquela informação não fique indisponível.
• Controle de consistência de escrita
o Se o fator de replicação for maior que o número de nós ativos, a leitura se
mantém mas todas as escrita serão rejeitadas.
14. Crash JVM
• Lentidão
• Marcação de ocupado
•Bola de neve com Hinted Handoff
•Causado pelos outros problemas
15. HEAP
• Nó morria frequentemente
• Bola de neve com Hinted Handoff
•Migração das máquinas para Xlarge
• Reconfiguração do pool
16. OutOfMemoryException só que não!
• Nó morria
•OutOfMemory mesmo não usando toda a memória
• Aumento do número de processos
17. HSHA E SYNC
• Documentação recomenda usar hsha para economizar
memória e possibilitar mais conexões
• Sync gasta muita memória com conexões, hsha causa falha nas conexões
• Utilizar sync mesmo a documentação dizendo o contrário
• Reconfiguração do pool
18. Excesso de conexões abertas
• Utilização de sync
• Nós morriam sempre que ligavamos a contabilização de impressões
• Reconfiguração do pool
19. Hot Spot
• Apenas 3 servidores eram utilizados por hora
• Nós morriam sempre que ligavamos a contabilização de impressões
• Reconfiguração da chave
22. Thrift Lock
• Mais novo erro do Cassandra !!!!!!
• Comunicação entre máquinas e clientes travada
•Cassandra isolado
• Restart do thrift
• Causa raíz desconhecida!!
23. Nodetool
ring
move <new token>
join
drain
decommission
flush [keyspace] [cfnames]
repair [keyspace] [cfnames]
refresh <keyspace> <cf-name>
cleanup [keyspace] [cfnames]
compact [keyspace] [cfnames]
getendpoints <keyspace> <cf> <key>
Address DC Rack Status State Load Effective-Ownership Token
141784319550391026443072753096570088106
10.100.16.61 sa-east 1a Up Normal 2.19 GB 0,00%0
10.100.17.61 sa-east 1b Up Normal 2.15 GB 0,00%28356863910078205288614550619314017621
10.100.16.62 sa-east 1a Up Normal 2.16 GB 0,00%56713727820156410577229101238628035242
10.100.17.62 sa-east 1b Up Normal 2.15 GB 0,00%85070591730234615865843651857942052864
10.100.16.63 sa-east 1a Up Normal 2.17 GB 0,00%113427455640312821154458202477256070485
10.100.17.63 sa-east 1b Up Normal 2.18 GB 0,00%141784319550391026443072753096570088106
disablegossip
enablegossip
gossipinfo
disablethrift
enablethrift
statusthrift