Cassandra cql

688 views

Published on

Apresentação sobre uso do Thrift e CQL no Adserver

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
688
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cassandra cql

  1. 1. Cassandra Thrift e CQL KEEP CALM AND COME TO THE DARK SIDE
  2. 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. 3. Thrift API
  4. 4. Thrift API COMO RAIOS EU FAÇO UMA PESQUISA NISSO????
  5. 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. 6. Thrift API
  7. 7. Thrift API
  8. 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. 9. CQL API
  10. 10. CQL API
  11. 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. 12. CQL API
  13. 13. CQL API
  14. 14. CQL API
  15. 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. 16. Os detalhes maléficos do Cassandra  Collections Columns  TTL  UUID  Indexes  Compound Keys
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. Chaves RowKey: 27 => (column=8:2013:, value=, timestamp=1377636632488000) => (column=8:2013:compromisso, value=707265706172616e646f2061756c61, timestamp=1377636632488000)
  28. 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. 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. 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. 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. 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. 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. 34. Dashboard
  35. 35. Dashboard
  36. 36. Dashboard
  37. 37. OBRIGADO!

×