# Apache Cassandra

- Classificação: Banco de dados (Linux)
- Objetivos: Solucionar problemas encontrados quando se manipula grandes quantidades de dados com alta taxa de crescimento.
- Classificação: Distribuído (2a. geração), híbrido, não-relacional, altamente escalável.
- Construído em Java sobre a tecnologia Amazon Dynamo e o modelo de dados do Google BigTable.
- Criado pela Fecebook em 2008 e agora sob desenvolvimento da Apache.
- Usado por: Digg, Facebook, Twitter, Reddit, Rackspace, Cloudkick, Cisco, SimpleGeo, Ooyala, OpenX, etc.
- Tolerância a falhas: replicação de dados em multiplos nós e entre data centers. Nós retirados e adicionados on-th-fly.
- Descentralizado: todo nó é idêntico, sem "ponto crítico de falha" (SPOF).
- Replicação síncrona ou assíncrona.
- Modelo de dados: além do key/value.
  - Mais rico que o Dynomite mas possui menor capacidade de busca que MongoDB
- Elasticidade: aumento do throughput através da escalabilidade horizontal.
- Durabilidade: voltado para que não haja perda de dados mesmo que um data-center inteiro seja danificado.
- Comunidade consolidada.
- Modelo de dados:
  - Every row is identified by a unique key.
  - The key is a string and there is no limit on its size.
  - An instance of Cassandra = one table of one or more column families (user defined).
- Column Families:
  - The unlimited qtd and the name must be fixed cluster start.
  - Can contain one of two unlimited dynamicaly created structures: supercolumns or columns.
  - Columns are constructs that have a name, a value and a user-defined timestamp.
  - There could be a variable number of columns per key, p.e. K1 could have 1024 columns/super columns while key K2 could have 64.
  - "Supercolumns” = unlimited constructs with a name and unlimited columns.
- Features:
  - Flexible schema: with Cassandra, like a document store, you don't have to decide what fields you need in your records ahead of time. You can add and remove arbitrary fields on the fly. This is an incredible productivity boost, especially in large deployments.
  - True scalability: Cassandra scales horizontally in the purest sense. To add more capacity to a cluster, turn on another machine. You don't have restart any processes, change your application queries, or manually relocate any data.
  - Multi-datacenter awareness: you can adjust your node layout to ensure that if one datacenter burns in a fire, an alternative datacenter will have at least one full copy of every record.
  - Range queries: unlike most key/value stores, you can query for ordered ranges of keys.
  - List datastructures: super columns add a 5th dimension to the hybrid model, turning columns into lists. This is very handy for things like per-user indexes.
  - Distributed writes: you can read and write any data to anywhere in the cluster at any time. There is never any single point of failure.

Fontes:

http://cassandra.apache.org

http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/

Entrevista com Ryan King (Twitter)

- Quais os motivos que levaram o Twitter a procurar uma solução noSQL?
  - Grande qtd de dados com taxa de crescimento em aceleração.
  - Solução atual com MySQL distribuído + memcache tornou-se proibitiva em relação ao custo de operação humana
  - Necessidade de sistema que possa crescer mais automaticamente e altamente disponível.
- Quais soluções foram consideradas?
  - setup mais automatizado do MySQL.
  - HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, HyperTable e outros.
- Quais testes foram feitos nestes sistemas?
  - Verificação da arquitetura:
    - Como novas máquinas são adicionadas?
    - Existe algum SPOF (Single Point Of Failure)?
    - A escrita tem boa escalabilidade?
    - Como é a administração do sistema?
    - É open source? Tem comunidade estabelecida?
    - Quanto tempo e esforço será gasto para aplicar a solução?
    - Consegue-se trabalhar com a tecnologia empregada?
    - Conseguimos modelar nossos dados no sistema?
  - Todos, exceto Cassandra, foram previamente eliminados após estas questões.
- Como vc resumiria o Cassandra?
  - Sem SPOF.
  - Alta escalabilidade de escrita.
  - Comunidade consolidada.
- Cassandra substituirá totalmente a solução atual?
  - Com o tempo, sim.

Artigo de Avinash Lakshman (Facebook Engineering Team), Oct, 2008 - Cassandra: A structured storage system on a P2P Network

- Necessidade de resolver o Inbox Search problem (criação dos índices de busca das mensagens dos usuários).
- Desafios: qtd de dados, taxa de crescimento, manter o SLA (Service Level Agreement).
- Situação inevitável: nova solução de armazenamento que resolvesse não só o Inbox Search problem mas outros de mesma natureza.
- Requisitos: scale incrementally and in a cost effective fashion
- Começaram a desenvolver o Cassandra (Lakshman + Prashant)
- Características:
  - distributed storage system for managing structured data
  - designed to scale to a very large size across many commodity servers
  - no single point of failure
  - projetada para rodar sobre milhres de nós distribuídos
  - lembra estratégias de banco de dados mas não suporta o modelo relacional completo
  - possui modelo de dados simples de formato e layout dinâmicos
- Modelo de dados:
  - Every row is identified by a unique key.
  - The key is a string and there is no limit on its size.
  - An instance of Cassandra = one table of one or more column families (user defined).
  - Column Families:
    - The unlimited qtd and the name must be fixed cluster start.
    - Can contain one of two unlimited dynamicaly created structures: supercolumns or columns.
    - Columns are constructs that have a name, a value and a user-defined timestamp.
    - There could be a variable number of columns per key, p.e. K1 could have 1024 columns/super columns while key K2 could have 64.
    - “Supercolumns” = unlimited constructs with a name and unlimited columns.
- Distribution, Replication and Fault Tolerance
  - Data is distributed across the nodes in the cluster.
  - There are range scans over the data for analysis at some later point.
  - Cluster membership is maintained via Gossip style membership algorithm.
  - Failures of nodes within the cluster are monitored using an Accrual Style Failure Detector.
  - High availability is achieved using replication and we actively replicate data across data centers.
  - Replication and data repairing is done in the background for increasing read throughput.
  - Incremental scalability is achieved dropping nodes and having them automatically bootstrapped with data.
- Cenário em 2008:
  - cluster de mais de 600 nós
  - 120 TB de dados

Artigo de John Quinn (VP Engineering at Digg) - Saying Yes to NoSQL; Going Steady with Cassandra

- Estão fazendo um refactoring do código para uma nova arquitetura cliente/servidor.
- Abandonando o LAMP (Linux, Apache, MySQL e PHP|Perl|Python).
- Maior desafio: passar do MySQL para algo noSQL
- Motivação: increasing difficulty of building a HP and write intensive app on a data set that is growing quickly, with no end in sight.
- Continuar investindo na elasticidade vertical e horizontal do sistema baseado em RDBMS continuará ser problemático.
- Modelo de dados tratado (notícias) não precisa de alta consistência.
- De acordo com o Teorema de Brewer ao relaxar os requisitos de consistência ganha-se em disponibilidade e tolerância a perdas.