O documento discute as APIs Thrift e CQL do Cassandra, explicando que a Thrift era mais complexa e difícil de usar, enquanto a CQL foi desenvolvida para simplificar o acesso ao Cassandra, trazendo uma sintaxe semelhante ao SQL. A CQL tornou-se a API padrão para comunicação com o Cassandra a partir da versão 1.2, sendo usada no projeto Adsever para armazenamento de dados.

1. Cassandra Thrift e CQL
KEEP
CALM
AND
COME TO THE
DARK SIDE

2. Thrift API
 Primeira API para comunicação
com o Cassandra
 Mostrava vários detalhes internos do Cassandra,
deixando os comandos verborrágicos e perigosos
 Interface difícil de se trabalhar
 Muitas transformações devem ser feitas via código

3. Thrift API

4. Thrift API
COMO RAIOS EU FAÇO UMA
PESQUISA NISSO????

5. Thrift API
 Por impossibilidade de se usar o CQL quando começamos a
trabalhar com o Cassandra escolhemos um cliente chamado
Astyanax porém a complexidade era alta, daí tivemos que criar
uma camada de abstração, surgiu o Cassandree.
 O uso do Cassandree no Adsever está no
nosso log de impressão e controle de cliques
através do Tracker e Batches

6. Thrift API

7. Thrift API

8. CQL API
 Evolução para uma API mais robusta
 CQL3 (Cassandra Query Language) foi criada para abstrair a
complexidade do Cassandra e permitir que sua utilização seja
muito mais simples, poderosa e segura.
 Até a versão 1.1.X do Cassandra, o CQL3 ainda era beta, com a
versão 1.2.X ele se tornou estável e passou a ser chamado em
muitos lugares apenas por CQL.
 Sintaxe semelhante ao SQL para facilitar aprendizado

9. CQL API

10. CQL API

11. CQL API
 Quando atualizamos o Cassandra para a versão 1.2.1 estávamos
prontos para usar o CQL 3 e o cluster já estava estabilizado
 Utilizamos o cliente Datastax Java Driver para conexão. Esse
cliente se assemelha em muito a JDBC, isso facilita muito
 Utilizamos o Java Driver dentro do
Dashboard para armazenamento do histórico
de ofertas e como base de dados principal

12. CQL API

13. CQL API

14. CQL API

15. CQL API
CREATE KEYSPACE demodb WITH REPLICATION = {'class' :
'SimpleStrategy', 'replication_factor': 3};
CREATE TABLE users (
user_name varchar,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint,
PRIMARY KEY (user_name));
INSERT INTO emp (empID, deptID, first_name, last_name)
VALUES (104, 15, 'jane', 'smith');
SELECT * FROM emp WHERE empID IN (130,104)
ORDER BY deptID DESC;

16. Os detalhes maléficos do
Cassandra
 Collections Columns
 TTL
 UUID
 Indexes
 Compound Keys

17. Collections Columns
 O cassandra é schemaless, ou seja, coluna
existe ou não, pra mim tanto faz
 Mas no CQL é necessário uma formalidade
nas colunas para que eu consiga fazer
buscas.

18. Collections Columns
CREATE TABLE conta_oferta (
campanha int,
categoria int,
loja bigint,
ofertas map<timestamp,bigint>,
PRIMARY KEY ((campanha,categoria), loja) );
 O CQL trás um novo tipo de coluna, a coluna de
coleção.
 Existem 3 tipos de coleções permitidas:
Set
List
Map
campanha | categoria | loja | ofertas
----------+-----------+------+--------------------------------------------------------------
6637 | 6424 | 50 | {2013-08-27 02:00:00-0300: 30, 2013-08-27 03:00:00-0300: 50}

19. Collections Columns
 Uma collection column permite guardar
valores dinâmicos, traduzindo a forma
schemaless do cassandra para um mundo
mais schemafull
 Cada item de uma collection column pode ter
um TTL específico

20. TTL
 Cada coluna na CF pode ter uma data para
expirar ou um Time To Live próprio. Assim
mantemos sempre dados válidos no
servidor, não há a necessidade de criar rotinas
complexas de expurgo ou pedir para a Infra
apagar os destinations =P
 No Dashboard cada item da coluna de ofertas
tem um TTL de 30 dias

21. UUID
 Em uma base relacional o ID pode ser um número
inteiro com incremento continuo já que a base fica
em apenas em um computador
 Já que o Cassandra é clusterizado, para evitar
choque de ids é necessário uma estratégia mais
avançada e para isso é usado o UUID (universally
unique id). Esse id é tem o formato hexadecimal e é
criado baseado na hora e em outros fatores, como
MAC address
Exemplo: ff63a295-e425-4773-9358-dd717039c1c2
No Java:
java.util.UUID.randomUUID();

22. Índices
 A busca no cassandra é feita apenas por
chaves, nunca por colunas
 Para fazer buscas por colunas é necessário
transformá-las em chaves, ou seja, criar índices
CREATE TABLE users ( userID uuid, frame text, lname text, state text, zip
int, PRIMARY KEY (userID, zip) );
CREATE INDEX users_state ON users (state)

23. Chaves
 As chaves em uma CF servem para separar
os dados entre os nós, ordená-los e buscá-los.
 Buscas devem ser feitas respeitando as
chaves e suas prioridades
 Buscas devem ser da “esquerda para a
direita”

24. Chaves
CREATE TABLE calendario (
dia int,
mes int,
ano int,
compromisso text,
PRIMARY KEY (dia,mes,ano) );
INSERT INTO calendario (dia,mes,ano,compromisso) VALUES
(27,08,2013,'preparando apresentacao');
SELECT * FROM calendario WHERE dia = 27;
dia | mes | ano | compromisso
-----+-----+------+-----------------
27 | 8 | 2013 | preparando aula

25. Chaves
SELECT * FROM calendario WHERE mes = 8;
Bad Request: Cannot execute this query as it might involve data filtering
and thus may have unpredictable performance. If you want to execute
this query despite the performance unpredictability, use ALLOW
FILTERING
Ordem: dia > mês > ano
 Uma Clustering Key não pode ser
usada sem sua Partition Key

26. Chaves
 Partition Key
 Chave responsável por espalhar os dados entre os nós do cluster
 É a linha da Colum Family
 Clustering Key
 Ordena os dados dentro de cada
separação feita pela Partition Key
 É o prefixo das colunas
 Compound Key
 Uma chave composta pela
Partition Key e Clustering Key
CREATE TABLE calendario ( dia int, mes int, ano int, compromisso text,
PRIMARY KEY (dia,mes,ano) );
Partition
Key
Clustering Key
Compound Key

27. Chaves
RowKey: 27
=> (column=8:2013:, value=, timestamp=1377636632488000)
=> (column=8:2013:compromisso,
value=707265706172616e646f2061756c61,
timestamp=1377636632488000)

28. Chaves
 Mas por que isso existe?
 Para garantir performance.
 Sem isso o Cassandra deve buscar a informação em todos os nós do
cluster
 ALLOW FILTERING
 Caso performance não seja o meu problema, eu posso avisar o
Cassandra disso através da sintax ALLOW FILTERING
SELECT * FROM calendario WHERE mes = 8 ALLOW FILTERING;
dia | mes | ano | compromisso
-----+-----+------+-----------------
27 | 8 | 2013 | preparando aula

29. Lógica para busca
1) O campo a ser procurado deve ser um índice
1) A ordem dos índices deve ser respeitada
1)Pense na Query antes de criar sua CF
1)Use ao máximo chaves naturais
1)Pense na query antes!
1)Lembre-se que em 95% o seu sistema usará as mesmas queries, então
pense antes na query

30. Normalização
 Facilita a atualização de dados
 Permite que eu contenha apenas informações
consistentes, sem campos NULL
 Permite informações em lista (com ajuda de
uma tabela de relacionamento), como por
exemplo, múltiplos telefones

31. Normalização
 Criação mais coerente de
queries complexas
Os publishers beta testers, com
campanhas ativas, da categoria
moda, que sejam do signo de
Virgem e com ascendente em Áries

32. Novo paradigma
 Mas por que devemos usar apenas esse tipo
de paradigma?
 Quanto de meta informação nós precisamos
para guardar informações normalizadas?
 Quantas primary keys com auto increment
(chaves não naturais), quantas foreign
keys, quantas tabelas de relacionamentos
precisamos para normalizar as informações?

33. Dashboard
 O Dashboard em 99% do tempo procura
informações, por que eu quero facilidade
para atualizar uma informação se isso vai
prejudicar minha busca?
 Por que eu não posso ter um campo nulo?
Para economizar espaço? Mas e as chaves
primarias e estrangeiras que eu vou
precisar, para ter essa economia?
 Quantas vezes eu vou precisar saber
sobre os publishers de Virgem
com ascendente em Áries?

34. Dashboard

35. Dashboard

36. Dashboard

37. OBRIGADO!