Cassandra atualiza as opções de estratégia do espaço de chaves

Cassandra - Crie o Keyspace.
Criando um espaço de teclas usando Cqlsh.
Um espaço de chaves no Cassandra é um espaço de nomes que define a replicação de dados nos nós. Um cluster contém um espaço de chaves por nó. Dada a seguir é a sintaxe para criar um espaço de chaves usando a instrução CREATE KEYSPACE.
A instrução CREATE KEYSPACE possui duas propriedades: replicação e durable_writes.
Replicação.
A opção de replicação é especificar a estratégia de Posicionamento da réplica e o número de réplicas desejadas. A tabela a seguir lista todas as estratégias de veiculação de réplica.
Usando essa opção, você pode instruir o Cassandra a usar o commitlog para atualizações no KeySpace atual. Esta opção não é obrigatória e, por padrão, é definida como true.
Dada a seguir é um exemplo de criação de um KeySpace.
Aqui estamos criando um KeySpace chamado TutorialsPoint.
Estamos usando a primeira estratégia de veiculação de réplica, ou seja, estratégia simples.
E estamos escolhendo o fator de replicação para 1 réplica.
Verificação.
Você pode verificar se a tabela é criada ou não usando o comando Descrever. Se você usar este comando sobre os espaços de chaves, ele exibirá todos os espaços de chaves criados conforme mostrado abaixo.
Aqui você pode observar o novo tutorialspoint do KeySpace.
Durable_writes.
Por padrão, as propriedades durable_writes de uma tabela são configuradas como true, mas podem ser configuradas como false. Você não pode definir essa propriedade para a estratégia simplex.
Dada a seguir é o exemplo demonstrando o uso da propriedade de gravações duráveis.
Verificação.
Você pode verificar se a propriedade durable_writes do keySpace de teste foi configurada como false consultando o System Keyspace. Esta consulta fornece todos os KeySpaces junto com suas propriedades.
Aqui você pode observar que a propriedade durable_writes do teste KeySpace foi configurada como false.
Usando um espaço de teclas.
Você pode usar um KeySpace criado usando a palavra-chave USE. Sua sintaxe é a seguinte:
No exemplo a seguir, estamos usando o tutorialspoint do KeySpace.
Criando um espaço de teclas usando a API Java.
Você pode criar um Keyspace usando o método execute () da classe Session. Siga as etapas abaixo para criar um espaço de chaves usando a API Java.
Etapa 1: criar um objeto de cluster.
Primeiro de tudo, crie uma instância da classe Cluster. builder do pacote com. datastax. driver. core como mostrado abaixo.
Adicione um ponto de contato (endereço IP do nó) usando o método addContactPoint () do objeto Cluster. Builder. Este método retorna o Cluster. Builder.
Usando o novo objeto de construtor, crie um objeto de cluster. Para fazer isso, você tem um método chamado build () na classe Cluster. Builder. O código a seguir mostra como criar um objeto de cluster.
Você pode criar um objeto de cluster em uma única linha de código, conforme mostrado abaixo.
Etapa 2: criar um objeto de sessão.
Crie uma instância do objeto Session usando o método connect () da classe Cluster, conforme mostrado abaixo.
Este método cria uma nova sessão e inicializa-a. Se você já tem um espaço de chaves, você pode configurá-lo para o existente, passando o nome do espaço de chaves no formato de string para este método, como mostrado abaixo.
Etapa 3: executar consulta.
Você pode executar consultas CQL usando o método execute () da classe Session. Passe a consulta no formato de string ou como um objeto de classe Statement para o método execute (). Tudo o que você passar para este método em formato de string será executado no cqlsh.
Neste exemplo, estamos criando um KeySpace chamado tp. Estamos usando a primeira estratégia de veiculação de réplica, ou seja, Estratégia simples, e estamos escolhendo o fator de replicação como 1 réplica.
Você precisa armazenar a consulta em uma variável de string e passá-la ao método execute () como mostrado abaixo.
Passo 4: Use o KeySpace.
Você pode usar um KeySpace criado usando o método execute () como mostrado abaixo.
Dada a seguir é o programa completo para criar e usar um espaço de chaves no Cassandra usando a API Java.
Salve o programa acima com o nome da classe seguido por. java, navegue até o local onde ele está salvo. Compile e execute o programa conforme mostrado abaixo.
Em condições normais, produzirá a seguinte saída:

Utilitário Cassandra-CLI (descontinuado)
Atributos de configuração obsoletos. Será removido no Cassandra 3.0.
Atributos do espaço de chaves.
O Cassandra armazena atributos de configuração de armazenamento no espaço de chaves do sistema. Você pode definir os atributos de configuração do mecanismo de armazenamento em uma base por teclado ou por tabela na linha de comando usando o utilitário Cassandra-CLI. Um espaço de chaves deve ter um nome definido pelo usuário, uma estratégia de posicionamento de réplica e opções que especifiquem o número de cópias por datacenter ou nó.
nome obrigatório. O nome do espaço de chaves. placement_strategy Obrigatório. Determina como o Cassandra distribui réplicas para um espaço de chaves entre nós no anel. Os valores são: SimpleStrategy ou org. apache. cassandra. locator. SimpleStrategy NetworkTopologyStrategy ou org. apache. cassandra. locatorworkTopologyStrategy.
O NetworkTopologyStrategy requer um pomo para determinar os locais do rack e do datacenter de um nó. Para obter mais informações sobre a estratégia de veiculação de replicação, consulte Replicação de dados.
strategy_options Especifica opções de configuração para a classe de estratégia de replicação escolhida. A opção do fator de replicação é o número total de réplicas no cluster. Um fator de replicação de 1 significa que há apenas uma cópia de cada linha em um nó. Um fator de replicação de 2 significa que há duas cópias de cada linha, em que cada cópia está em um nó diferente. Todas as réplicas são igualmente importantes; não há réplica principal ou principal. Como regra geral, o fator de replicação não deve exceder o número de nós no cluster. No entanto, você pode aumentar o fator de replicação e, em seguida, adicionar o número desejado de nós.
Quando o fator de replicação excede o número de nós, as gravações são rejeitadas, mas as leituras são atendidas desde que o nível de consistência desejado possa ser atendido.
Para obter mais informações sobre como configurar a estratégia de posicionamento de replicação para um cluster e datacenters, consulte Escolhendo opções de replicação de espaço de teclas.
durable_writes (Padrão: true) Quando definido como false, os dados gravados no espaço de chaves ignoram o log de confirmação. Tenha cuidado ao usar essa opção porque você corre o risco de perder dados.
Tópicos para iniciar e parar o Cassandra.
Instalar tópicos de localização.
Definir variáveis ​​de ambiente (cassandra. in. sh).
Atributos de configuração obsoletos. Será removido no Cassandra 3.0.
Atributos por tabela.
DataStax é uma marca registrada da DataStax, Inc. e suas subsidiárias nos Estados Unidos e / ou outros países.
Apache Cassandra, Apache, Tomcat, Lucene, Solr, Hadoop, Spark, TinkerPop e Cassandra são marcas comerciais da Apache Software Foundation ou de suas subsidiárias no Canadá, nos Estados Unidos e / ou em outros países.

CRIE O KEYSPACE.
Defina um novo espaço de chaves e sua estratégia de posicionamento de réplica.
Defina um novo espaço de chaves e sua estratégia de posicionamento de réplica.
map é uma coleção de mapas, uma matriz de literais estilo JSON:
Maiúscula significa literal Minúscula significa não literal Itálico significa opcional O símbolo de pipe (|) significa OR ou AND / OR Reticências (.) Significa repetível.
Um ponto e vírgula que termina instruções CQL não está incluído na sinopse.
Descrição.
CREATE KEYSPACE cria um namespace de nível superior e define o nome do espaço de chaves, a classe de estratégia de colocação de réplica, o fator de replicação e as opções de DURABLE_WRITES para o espaço de chaves. Para obter informações sobre a estratégia de veiculação de réplica, consulte Estratégia de veiculação de réplica do Apache Cassandra ™ 2.1 ou Estratégia de veiculação de réplica do Apache Cassandra 2.0.
Ao configurar o NetworkTopologyStrategy como estratégia de replicação, você configura um ou mais data centers virtuais. Como alternativa, você usa o data center padrão. Use os mesmos nomes para centros de dados que os usados ​​pelo pomo. Para obter informações sobre o pomo, consulte a documentação do pechinchamento do Apache Cassandra 2.1 ou a documentação do pechinchamento do Apache Cassandra 2.0.
Você designa diferentes nós, dependendo do tipo de carga de trabalho, para separar os centros de dados. Por exemplo, atribua nós do Hadoop a um datacenter e os nós do Cassandra em tempo real a outro. Segregar as cargas de trabalho garante que apenas um tipo de carga de trabalho esteja ativo por data center. A segregação evita problemas de incompatibilidade entre cargas de trabalho, como requisitos de lotes diferentes que afetam o desempenho.
Um mapa de propriedades e valores define os dois tipos diferentes de espaços de chaves:
As chaves do mapa de propriedades CQL devem estar em minúsculas. Por exemplo, class e replication_factor estão corretos. Os nomes de espaço de chaves têm 48 caracteres ou menos caracteres alfanuméricos e sublinhados, o primeiro dos quais é um caractere alfa. Os nomes do espaço de chaves são insensíveis a maiúsculas e minúsculas. Para tornar um nome sensível a maiúsculas e minúsculas, coloque-o entre aspas duplas.
Você pode usar o alias CREATE SCHEMA em vez de CREATE KEYSPACE. A tentativa de criar um espaço de chaves já existente retornará um erro, a menos que a opção IF NOT EXISTS seja usada. Se a opção for usada, a instrução não funcionará se o espaço de chaves já existir.
Exemplo de configuração da classe SimpleStrategy.
Para construir a instrução CREATE KEYSPACE, primeiro declare o nome do espaço de chaves, seguido pelas palavras-chave WITH REPLICATION e o símbolo de igual. O nome do espaço de chaves não diferencia maiúsculas de minúsculas, a menos que esteja entre aspas duplas. Em seguida, para criar um espaço de chaves que não seja otimizado para vários datacenters, use SimpleStrategy para o valor da classe no mapa. Defina as propriedades replication_factor, separadas por dois pontos e colocadas entre chaves. Por exemplo:
Usando SimpleStrategy é bom para avaliar Cassandra. Para uso em produção ou para uso com cargas de trabalho mistas, use NetworkTopologyStrategy.
Exemplo de configuração da classe NetworkToplogyStrategy.
O uso do NetworkTopologyStrategy também é bom para avaliar o Cassandra. Para usar o NetworkTopologyStrategy para fins de avaliação usando, por exemplo, um cluster de nó único, especifique o nome do centro de dados padrão do cluster. Para determinar o nome do datacenter padrão, use o status nodetool.
Para usar o NetworkTopologyStrategy com datacenters em um ambiente de produção, é necessário alterar o padrão, SimpleSnitch, para um pomo que reconhece a rede, definir um ou mais nomes de data center no arquivo de propriedades do pomo e usar esses nomes definir o espaço de chaves; caso contrário, o Cassandra não conseguirá encontrar um nó para concluir uma solicitação de gravação, como inserir dados em uma tabela.
Depois de configurar o Cassandra para usar um conetor com reconhecimento de rede, como o PropertyFileSnitch, você define os nomes do data center e do rack no arquivo cassandra-topology. properties.
Construa a instrução CREATE KEYSPACE usando NetworkTopologyStrategy para o valor de classe no mapa. Defina um ou mais pares de valores-chave que consistem no nome do centro de dados e no número de réplicas por data center, separados por dois pontos e colocados entre chaves. Por exemplo:
Este exemplo define três réplicas para um datacenter chamado dc1 e duas réplicas para um datacenter denominado dc2. O nome do datacenter que você usa depende do que você está usando. Existe uma correlação entre o nome do datacenter definido no mapa e o nome do datacenter, conforme reconhecido pelo informante que você está usando. O comando de status do nodetool imprime nomes de data centers e localizações de rack de seus nós, caso você não tenha certeza de quais são.
Definindo DURABLE_WRITES.
Você pode definir a opção DURABLE_WRITES após a especificação do mapa do comando CREATE KEYSPACE. Quando definido como false, os dados gravados no espaço de chaves ignoram o log de confirmação. Tenha cuidado ao usar essa opção porque você corre o risco de perder dados. Não defina esse atributo em um espaço de chaves usando o SimpleStrategy.
Verificando os espaços de chaves criados.
Verifique se os espaços de chaves foram criados:
A Cassandra converteu o keyspace do excelsior em minúsculas porque aspas não foram usadas para criar o espaço de chaves e reteve a letra maiúscula inicial do Excalibur porque aspas foram usadas.

Opções de estratégia de espaço de chaves de atualização do Cassandra
Eu instalei e iniciei o Cassandra em duas máquinas linux no Amazon EC2. Eu também configurei o cassandra. yaml para usar um arquivo de propriedades e configurei o arquivo cassandra-topology. properties como o seguinte:
Em seguida, criou um espaço de chaves como o seguinte:
Então criei uma família de colunas e tentei inserir uma linha. No entanto, estou recebendo um nulo de volta da CLI quando tento inserir. Eu senti falta de algo na configuração?
Como posso descobrir o que está acontecendo?
Além disso, o Cassandra só lê a topologia de cassandra na inicialização?

[Cassandra-user] RESOLVIDO: Problema ao atualizar para 0.8.3 - & quot; replication_factor é uma opção para SimpleStrategy, não NetworkTopologyStrategy & quot;
Causado por: org. apache. cassandra. config. ConfigurationException:
replication_factor é uma opção para o SimpleStrategy, não.
Cadeia de caracteres dc = entry. getKey ();
- continuar; // TODO remove isso para 1.0.
ConfigurationException (& quot; replication_factor é uma opção para.
SimpleStrategy, não NetworkTopologyStrategy & quot;);
Réplicas inteiras = Integer. valueOf (entry. getValue ());
AVISO: Não foi possível conectar-se ao JMX em 127.0.0.3:7199, informações.
Estratégia de replicação: org. apache. cassandra. locatorworkTopologyStrategy.
Escrita Durável: verdade.
Aguardando o acordo de esquema.
. esquemas concordam em todo o cluster.
Estratégia de replicação: org. apache. cassandra. locatorworkTopologyStrategy.
Escrita Durável: verdade.
Pesquisar discussões.
4 respostas mais antigas aninhadas.
Porque RESOLVIDO é o primeiro que vi.)
anexou um patch para corrigir o problema.
Causado por: org. apache. cassandra. config. ConfigurationException:
replication_factor é uma opção para o SimpleStrategy, não.
Cadeia de caracteres dc = entry. getKey ();
- continuar; // TODO remove isso para 1.0.
ConfigurationException (& quot; replication_factor é uma opção para.
SimpleStrategy, não NetworkTopologyStrategy & quot;);
Réplicas inteiras = Integer. valueOf (entry. getValue ());
AVISO: Não foi possível conectar-se ao JMX em 127.0.0.3:7199, informações.
Estratégia de replicação: org. apache. cassandra. locatorworkTopologyStrategy.
Escrita Durável: verdade.
Aguardando o acordo de esquema.
. esquemas concordam em todo o cluster.
Estratégia de replicação: org. apache. cassandra. locatorworkTopologyStrategy.
Escrita Durável: verdade.
Presidente do projeto, Apache Cassandra.
co-fundador da DataStax, a fonte para suporte profissional a Cassandra.
foi resolvido para mim depois de uma hora de investigação. ;-)
Porque RESOLVIDO é o primeiro que vi.)
anexou um patch para corrigir o problema.
Causado por: org. apache. cassandra. config. ConfigurationException:
replication_factor é uma opção para o SimpleStrategy, não.
Cadeia de caracteres dc = entry. getKey ();
- continuar; // TODO remove isso para 1.0.
ConfigurationException (& quot; replication_factor é uma opção para.
SimpleStrategy, não NetworkTopologyStrategy & quot;);
Réplicas inteiras = Integer. valueOf (entry. getValue ());
AVISO: Não foi possível conectar-se ao JMX em 127.0.0.3:7199, informações.
Estratégia de replicação: org. apache. cassandra. locatorworkTopologyStrategy.
Escrita Durável: verdade.
Aguardando o acordo de esquema.
. esquemas concordam em todo o cluster.
Estratégia de replicação: org. apache. cassandra. locatorworkTopologyStrategy.
Escrita Durável: verdade.
Presidente do projeto, Apache Cassandra.
co-fundador da DataStax, a fonte para suporte profissional a Cassandra.
Você pode por favor explicar como você fez o upgrade? algo como passo a passo.
para ouvir como as outras pessoas estão fazendo isso.
meu notebook. Então seria bom ouvir sobre configurações reais. Aqui está o meu.
distribuição de cassandra. Eu então crio um repositório local do GIT e adiciono o.
& # 39; conf & # 39; diretório para que eu possa rastrear quaisquer alterações de configuração em um nó.
Em seguida, configurações de configuração específicas de nós relevantes são definidas. O.
& # 39; commitlog & # 39 ;, & # 39; dados & # 39; e & # 39; saved_caches & # 39; são criados por cassandra e.
deve ser configurado em & # 39; cassandra. yaml & # 39; para cada nó.
Faça um diff dos novos arquivos conf da nova versão para obter isso.
novos parâmetros, etc. Eu uso emacs ediff-mode.
Remova o antigo & quot; apache-cassandra & quot; symlink e aponte para o novo cassandra dist.
De maneira rotativa, pare um nó e, em seguida, reinicie-o. Enquanto o.
symlink é alterado, ele será então inicializado com o dist de cassandra atualizado.
(lembre-se de copiar o & amp; da bin / dir, caso contrário você ainda será.
no diretório antigo).
Se algo quebrar. apenas recriar o link simbólico antigo e reinicie.
o nó (desde que a cassandra não tenha executado nenhum não para trás.
alterações compatíveis com os arquivos db, devem ser observadas no README)
(puppetlabs /) para facilitar a configuração em muitos nós. Mas lá.
Há muitas maneiras de fazer isso, por exemplo, pssh.
Você pode por favor explicar como você fez o upgrade? algo como passo a passo.
Causado por: org. apache. cassandra. config. ConfigurationException:
replication_factor é uma opção para o SimpleStrategy, não.

Linguagem de consulta do Cassandra (CQL) v3.3.1.
Sintaxe CQL.
Este documento descreve a versão 3 do CAND (Cassandra Query Language) 3. O CQL v3 não é compatível com versões anteriores do CQL v2 e difere de várias maneiras. Observe que este documento descreve a última versão dos idiomas. No entanto, a seção changes fornece o diff entre as diferentes versões do CQL v3.
O CQL v3 oferece um modelo muito próximo ao SQL no sentido de que os dados são colocados em tabelas contendo linhas de colunas. Por esse motivo, quando usados ​​neste documento, esses termos (tabelas, linhas e colunas) têm a mesma definição que no SQL. Mas, por favor, note que, como tal, eles não se referem ao conceito de linhas e colunas encontradas na implementação interna do Cassandra e no thrift e na API CQL v2.
Convenções
Para auxiliar na especificação da sintaxe da CQL, usaremos as seguintes convenções neste documento:
As regras de idioma serão dadas em uma notação semelhante à BNF:
Os símbolos não terminais terão & lt; colchetes angulares>. Como notações de atalho adicionais para a BNF, usaremos os símbolos da expressão regular tradicional (?, + E *) para indicar que um determinado símbolo é opcional e / ou pode ser repetido. Também permitiremos que parênteses agrupem símbolos e a notação [& lt; characters>] para representar qualquer um dos & lt; characters>. A gramática é fornecida para fins de documentação e deixa alguns detalhes menores. Por exemplo, a última definição de coluna em uma instrução CREATE TABLE é opcional, mas suportada se estiver presente, mesmo que a gramática fornecida neste documento sugira que não é suportada. O código de amostra será fornecido em um bloco de código:
Referências a palavras-chave ou partes do código CQL no texto em execução serão mostradas em uma fonte de largura fixa.
Identificadores e palavras-chave.
A linguagem CQL usa identificadores (ou nomes) para identificar tabelas, colunas e outros objetos. Um identificador é um token que corresponde à expressão regular [a-zA-Z] [a-zA-Z0-9_] *.
Vários desses identificadores, como SELECT ou WITH, são palavras-chave. Eles têm um significado fixo para o idioma e a maioria é reservada. A lista dessas palavras-chave pode ser encontrada no Apêndice A.
Identificadores e palavras-chave (sem aspas) são insensíveis a maiúsculas e minúsculas. Assim, SELECT é o mesmo que select ou sElEcT, e myId é o mesmo que myid ou MYID, por exemplo. Uma convenção frequentemente usada (em particular pelas amostras desta documentação) é usar maiúsculas para palavras-chave e minúsculas para outros identificadores.
Há um segundo tipo de identificadores chamados de identificadores entre aspas definidos pelo fechamento de uma sequência arbitrária de caracteres entre aspas duplas ("). Os identificadores entre aspas nunca são palavras-chave. Assim," selecionar "não é uma palavra-chave reservada e pode ser usada para se referir a uma coluna. , enquanto select cria um erro de análise. Além disso, ao contrário de identificadores não citados e palavras-chave, os identificadores citados diferenciam maiúsculas de minúsculas ("Meu ID citado" é diferente de "meu ID citado"). Um identificador entre aspas minúsculo que corresponde a [a-zA - Z] [a-zA-Z0-9_] * é equivalente ao identificador não indicado obtido removendo-se as aspas duplas (assim, "myid" é equivalente a myid e a myId, mas diferente de "myId"). Dentro de um identificador entre aspas , o caractere de aspas duplas pode ser repetido para escapar, então "foo" "bar" é um identificador válido.
Aviso: os identificadores entre aspas permitem declarar colunas com nomes arbitrários, e esses podem conflitar com nomes específicos usados ​​pelo servidor. Por exemplo, ao usar a atualização condicional, o servidor responderá com um conjunto de resultados contendo um resultado especial chamado "[aplicado]". Se você declarou uma coluna com esse nome, isso poderia confundir algumas ferramentas e deve ser evitado. Em geral, os identificadores não citados devem ser preferidos, mas se você usar identificadores entre aspas, é altamente recomendável evitar qualquer nome entre colchetes (como "[aplicado]") e qualquer nome que se pareça com uma chamada de função (como "f (x)". ) ").
O CQL define os seguintes tipos de constantes: strings, inteiros, floats, booleans, uuids e blobs:
Uma constante de seqüência de caracteres é uma seqüência arbitrária de caracteres caracteres entre aspas simples ('). Pode-se incluir uma aspa simples em uma string repetindo-a, por exemplo 'Está chovendo hoje' . Aqueles não devem ser confundidos com identificadores citados que usam aspas duplas. Uma constante inteira é definida por '-'? [0-9] +. Uma constante de flutuação é definida por '-'? [0-9] + ('.' [0-9] *)? ([EE] [+ -]? [0-9 +])? . Além disso, NaN e Infinity também são constantes de float. Uma constante booleana é verdadeira ou falsa até insensibilidade a maiúsculas e minúsculas (ou seja, True é uma constante booleana válida). Uma constante UUID é definida por hex - hex - hex - hex - hex em que hex é um caractere hexadecimal, por ex. [0-9a-fA-F] e é o número de tais caracteres. Uma constante de blob é um número hexadecimal definido por 0 [xX] (hex) + onde hex é um caractere hexadecimal, p. [0-9a-fA-f].
Para saber como essas constantes são digitadas, consulte a seção de tipos de dados.
Um comentário no CQL é uma linha iniciada por traços duplos (-) ou por uma barra dupla (//).
Os comentários de várias linhas também são suportados por meio do gabinete em / * e * / (mas o aninhamento não é suportado).
Afirmações.
CQL consiste em instruções. Como no SQL, essas instruções podem ser divididas em 3 categorias:
Instruções de definição de dados, que permitem definir e alterar a maneira como os dados são armazenados. Instruções de manipulação de dados, que permitem alterar consultas de dados, para procurar dados.
Todas as instruções terminam com um ponto-e-vírgula (;), mas esse ponto-e-vírgula pode ser omitido ao lidar com uma única instrução. As instruções suportadas são descritas nas seções a seguir. Ao descrever a gramática das declarações, reutilizaremos os símbolos não-terminais definidos abaixo:
Por favor, note que nem todas as produções possíveis da gramática acima serão válidas na prática. Mais notavelmente, & lt; variable> e aninhados & lt; collection-literal> não são permitidos no & lt; collection-literal>.
Uma & lt; variável> pode ser anônima (um ponto de interrogação (?)) Ou nomeada (um identificador precedido por:). Ambos declaram uma variável de ligação para instruções preparadas. A única diferença entre uma variável anymous e uma variável nomeada é que será mais fácil referir uma variável com nome (como exatamente depende do driver cliente usado).
A produção de & lt; properties> é usada pela instrução que cria e altera espaços de chaves e tabelas. Cada & lt; property> é simples, caso em que apenas tem um valor ou um mapa, caso em que o valor é uma subopção de agrupamento de mapas. O seguinte se referirá a um ou outro como o tipo (simples ou mapa) da propriedade.
Um & lt; tablename> será usado para identificar uma tabela. Este é um identificador que representa o nome da tabela que pode ser precedido por um nome de espaço de chaves. O nome do espaço de chaves, se fornecido, permite identificar uma tabela em outro espaço de chaves que não a atualmente ativa (o espaço de chaves ativo atualmente é definido através da instrução USE).
Para a função suportada, veja a seção sobre funções.
Seqüências de caracteres podem ser incluídas entre aspas simples ou caracteres de dois dólares. A segunda sintaxe foi introduzida para permitir cadeias de caracteres que contenham aspas simples. Candidatos típicos para essas cadeias de caracteres são fragmentos de código-fonte para funções definidas pelo usuário.
Declaração preparada.
CQL suporta instruções preparadas. A instrução preparada é uma otimização que permite analisar uma consulta apenas uma vez, mas executá-la várias vezes com diferentes valores concretos.
Em uma declaração, cada vez que um valor de coluna é esperado (na manipulação de dados e nas instruções de consulta), uma variável & lt; variável> (veja acima) pode ser usada em seu lugar. Uma declaração com variáveis ​​de ligação deve então ser preparada. Uma vez preparado, pode ser executado fornecendo valores concretos para as variáveis ​​de ligação. O procedimento exato para preparar uma instrução e executar uma instrução preparada depende do driver CQL usado e está além do escopo deste documento.
Além de fornecer valores de coluna, os marcadores de ligação podem ser usados ​​para fornecer valores para cláusulas LIMIT, TIMESTAMP e TTL. Se forem usados ​​marcadores de ligação anônimos, os nomes dos parâmetros de consulta serão [limit], [timestamp] e [ttl], respectivamente.
Definição de dados.
CRIE O KEYSPACE.
A instrução CREATE KEYSPACE cria um novo espaço de chaves de nível superior. Um espaço de chaves é um espaço de nomes que define uma estratégia de replicação e algumas opções para um conjunto de tabelas. Os nomes de espaços de chaves válidos são identificadores compostos exclusivamente de caracteres alfanuméricos e cujo comprimento é menor ou igual a 32. Observe que, como identificadores, os nomes de espaços de teclas não diferenciam maiúsculas de minúsculas: use um identificador entre aspas para nomes de espaços de teclas com distinção entre maiúsculas e minúsculas.
As & lt; properties> suportadas por CREATE KEYSPACE são: