Cassandra CQL-NoSQL ou SQL

Sou muito nova para a Cassandra, comecei a aprender Cassandra há uma semana. Eu li pela primeira vez, que era um NoSQL, mas quando comecei a usar CQL, Comecei a perguntar-me se a Cassandra é uma NoSQL ou SQL DB.

alguém pode explicar porque é que o CQL é mais ou menos como o SQL?

Author: Danny Varod, 2012-06-22

3 answers

Para todos os efeitos, o CQL é SQL, por isso, no sentido mais estrito, a Cassandra é uma base de dados SQL. No entanto, a maioria das pessoas associa o SQL às bases de dados relacionais às quais é normalmente aplicado. Sob esta interpretação (mis), Cassandra não deve ser considerada uma "base de dados SQL", uma vez que não é relacional, e não suporta propriedades ácido.

 3
Author: jericevans, 2012-06-22 15:05:40

O CQL é declarativo como o SQL e a estrutura muito básica do componente de consulta da linguagem (selecione coisas onde a condição) é a mesma. Mas há diferenças suficientes que não se deve abordar usando-o da mesma forma que o SQL convencional.

Os itens óbvios: 1. Não há ligações ou subquadrias. 2. Sem transacções

Menos óbvio, mas igualmente importante de notar:

  1. à excepção da chave primária, só se pode aplicar uma condição quando uma coluna se criou um índice nessa coluna. Em SQL, você não tem que indexar uma coluna para filtrá-la, mas em CQL a instrução selecionada irá falhar completamente.
  2. não existem ou não operadores lógicos, apenas e. É muito importante modelar seus dados para que você não vai precisar destes dois; é muito fácil de esquecer acidentalmente.
  3. a manipulação da data é profundamente diferente. O CQL permite apenas o operador equal para datas tão extremamente comuns e expressões úteis como esta não trabalho: where dateField > TO_TIMESTAMP('2013-01-01','YYYY-MM-DD') também, o CQL não permite a inserção de strings de datas precisas a millis ( apenas segundos) -- mas permite a entrada de millis desde a época como um int longo -- que a maioria dos outros motores DB não permite. Por último, o fuso-horário (como deslocamento GMT) é invisivelmente capturado tanto para os formatos de millis longos e string sem um fuso-horário. Isso pode levar a confusão para os sistemas que deliberadamente não conflate tempo local + deslocamento GMT.
  4. só pode actualizar uma tabela com base na chave primária (ou uma Na lista de chaves primárias). Você não pode atualizar com base em outros dados da coluna, nem pode fazer uma atualização de massa como esta: update table set field = value; o CQL exige uma cláusula onde com a chave primária.
  5. gramática para e não permite pais. Para ser justo, não é necessário por causa da falta do operador ou, mas isso significa retritores SQL tradicionais que adicionam pais" protetores " em torno de expressões não vai funcionar com CQL, por exemplo: select * from www where (str1 = 'foo2') and (dat1 = 12312442);
Em geral, é melhor usar a Cassandra como uma grande, resistente. permastore de dados para os quais um pequeno número de consultas de alto nível, muito alto desempenho pode ser aplicado para arrastar um subconjunto de dados para trabalhar com a camada de Aplicação. Esse subconjunto pode ser um milhão de linhas, sim. O CQL e o modelo Cassandra não são projetados para declarações de seleção de 2 páginas com casos embutidos, agregações, etc. etc.
 31
Author: Buzz Moschetti, 2013-10-02 15:21:43

Documentos para CQLV3.0

CQL descrever para obter esquemas de keyspace, column family, cluster

O CQL não suporta algumas coisas que conheci em SQL como joins group by triggers cursors procedure transactions stored procedures

O Cql3.0 suporta ORDER BY

O CQL Suporta todas as funcionalidades DML e DDL

Suporte de CQL BATCH

BATCH is not an analogue for SQL ACID transactions.

Apenas o documento acima mencionado é a melhor referência:)

 4
Author: Tamil, 2012-06-22 11:18:27