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?
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.