Upload
distbp
View
445
Download
1
Embed Size (px)
Citation preview
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
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
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
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
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;
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.
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: SetListMap
campanha | categoria | loja | ofertas----------+-----------+------+--------------------------------------------------------------
6637 | 6424 | 50 | {2013-08-27 02:00:00-0300: 30, 2013-08-27 03:00:00-0300: 50}
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
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
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 (universallyunique 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();
Í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, zipint, PRIMARY KEY (userID, zip) );
CREATE INDEX users_state ON users (state)
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”
ChavesCREATE 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
ChavesSELECT * 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
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
Chaves
RowKey: 27=> (column=8:2013:, value=, timestamp=1377636632488000)=> (column=8:2013:compromisso,
value=707265706172616e646f2061756c61, timestamp=1377636632488000)
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
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
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
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
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?
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 chavesprimarias 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?