Com a proximidade do lançamento estável do Couchbase 5.0, é uma boa ideia revisitar alguns dos aprimoramentos, tanto em termos de desempenho quanto de recursos, que estão chegando com a tecnologia N1QL.
Então, quais foram alguns dos aprimoramentos feitos na questão do desempenho?
Aprimoramentos de desempenho do N1QL
Vejamos a projeção do índice, por exemplo. Ao criar um índice, você pode criar um com qualquer número de propriedades. Por exemplo, considere o seguinte índice:
1 |
CREATE INDEX idx ON default(type, firstname, lastname); |
A instrução acima criará um índice de cobertura no padrão
Balde para o tipo
, primeiro nome
e sobrenome
propriedades de um determinado documento.
Agora, digamos que criamos a seguinte consulta N1QL para recuperar alguns documentos com o parâmetro idx
que havíamos criado:
1 2 3 |
SELECT firstname DO padrão WHERE type = 'person' |
A consulta acima usaria o idx
e retornar apenas o índice primeiro nome
para cada documento correspondente. O conceito de consulta dessa forma não é novo, no entanto, o que acontece nos bastidores mudou. Você notará que, embora nosso índice tenha muitas chaves, estamos interessados apenas em um subconjunto ou, neste caso, em duas chaves.
Então, o que está acontecendo e por que isso é importante?
Nas versões anteriores do Couchbase, todas as chaves do índice eram levadas em consideração, independentemente de apenas um subconjunto ser usado. Como resultado, eram necessários mais rede, CPU e memória para acomodar o que estava acontecendo. Agora, esse não é o caso.
Então, como você sabe que a projeção de índice está acontecendo?
Faça um EXPLICAR
na consulta que você está executando:
1 2 3 |
EXPLAIN SELECT firstname DO padrão WHERE type = 'person' |
Nos resultados, você deverá ver algo relacionado a index_projection
que se parece com o seguinte:
1 2 3 4 5 6 7 8 |
... "index_projection": { "entry_keys": [ 0, 1 ] }, ... |
O chaves_de_entrada
será alterada com base em sua consulta. Por exemplo, e se adicionarmos um ONDE
condição assim?
1 2 3 |
SELECT firstname DO padrão WHERE type = 'person' AND lastname = 'Nic' |
No cenário acima, obteríamos um EXPLICAR
resultado que se parece com o seguinte:
1 2 3 4 5 6 7 8 9 |
... "index_projection": { "entry_keys": [ 0, 1, 2 ] }, ... |
Agora, a consulta acima não foi uma projeção de índice porque usamos todas as chaves em nosso índice de cobertura.
A criação de índices adequados em conjunto com a projeção de índices pode realmente ajudar no desempenho geral e no dimensionamento do cluster do Couchbase Server.
A projeção do índice não foi o único aprimoramento de desempenho feito na compilação de março de 2017, certo? É isso mesmo, há mais!
Vamos pegar o COUNT(DISTINCT)
por exemplo. Agora vamos usar essa operação na consulta a seguir:
1 2 |
EXPLAIN SELECT COUNT(DISTINCT type) DO padrão; |
Nos resultados, você notará que ele está usando IndexCountDistinctScan2
e o que ele está fazendo é armazenar todos os tipo
no índice e processando os valores distintos. Embora isso aconteça no indexador no Couchbase 5.0, anteriormente acontecia no serviço N1QL em edições anteriores. Ao transferir essa operação para o indexador, podemos obter ganhos significativos de desempenho.
Da mesma forma, pegue o DESLOCAMENTO
, LIMITE
e ORDER BY
operadores que podem ser usados em consultas N1QL. Veja a consulta a seguir, por exemplo:
1 2 3 4 5 6 |
EXPLAIN SELECT firstname DO padrão WHERE type = 'person' ORDER BY firstname LIMITE 1 OFFSET 1; |
Você notará que o LIMITE
, ORDER BY
e DESLOCAMENTO
aparecerão no indexador. Antes da versão 5.0, o LIMITE
apareceu no indexador, mas agora os outros também aparecem. Essa é uma grande vitória, pois nas versões anteriores do Couchbase, se você compensasse os resultados, o N1QL obteria um número X de resultados e descartaria tudo antes da compensação.
Isso nos leva ao tópico do N1QL e aos aprimoramentos dos recursos de indexação.
Indexação de matriz simplificada
Com o Couchbase Server 4.5, veio a indexação de matriz. Veja o seguinte documento de amostra, por exemplo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "type": "pessoa", "firstname": "Nic", "Lastname": "Raboy", "social-media": [ { "type": "twitter", "url": "https://www.twitter.com/nraboy" }, { "tipo": "website", "url": "https://www.thepolyglotdeveloper.com" } ] } |
Nova sintaxe de índice de matriz
Antes do Couchbase 5.0, para indexar os elementos da matriz encontrados em mídia social
você tinha que escrever um índice parecido com o seguinte:
1 2 3 |
CREATE INDEX ism ON `default` ( DISTINCT ARRAY media FOR media IN `social-media` END ) WHERE type = 'person'; |
No exemplo acima, o PARA
era necessário para a indexação do array. No Couchbase Server 5.0, há uma sintaxe muito mais simplificada. O mesmo índice pode ser criado da seguinte forma:
1 2 3 |
CREATE INDEX ism ON `default` ( DISTINCT `social-media` ) WHERE type = "person"; |
Para garantir que seu índice funcione, você pode executar a seguinte consulta N1QL:
1 2 3 |
EXPLAIN SELECT * DO padrão WHERE type = 'person' AND ANY media IN `social-media` SATISFIES media.type = 'website' END; |
Ao examinar os resultados da EXPLICAR
você verá que ele está usando o ismo
que foi criado anteriormente.
O fato de a sintaxe simplificada existir não significa que você não possa usar a sintaxe anterior na indexação de matriz. O exemplo a seguir seria um exemplo perfeito de por que a sintaxe anterior ainda seria válida:
1 2 3 |
CREATE INDEX ism_website ON `default` ( DISTINCT ARRAY media FOR media IN `social-media` WHEN media.type = 'website' END ) WHERE type = 'person'; |
Observe que a QUANDO
foi usado ao criar o operador ism_website
índice acima.
Mais informações sobre indexação de matriz podem ser encontradas aquijuntamente com outra documentação útil sobre a criação de índices no Couchbase.
Requisito de correspondência de variável relaxada para índices de matriz
Nas versões 4.x, a indexação de matriz exigia o uso de nomes de variáveis exatamente iguais no SELECIONAR
que foram usadas na consulta CRIAR ÍNDICE
declaração. Veja mais detalhes aqui.
Por exemplo, referindo-se às consultas anteriores vistas acima, observe que a variável mídia
que é usado para iterar pela matriz mídia social
é muito importante. A indexação de matrizes na versão 4.x exige o nome exato da variável mídia
a ser usado no SELECIONAR
consulta.
A versão 5.0 do Couchbase relaxa esse requisito, e a consulta a seguir funcionaria perfeitamente bem:
1 2 3 4 |
EXPLAIN SELECT * DO padrão USE INDEX (ism) WHERE type = 'person' AND ANY m IN `social-media` SATISFIES m.type = 'website' END; |
Observe que o índice ismo
usa o nome da variável mídia
mas a consulta acima usa m
. Ainda assim, a consulta acima pode usar o índice ismo
com sucesso.
Um requisito de chave de índice de matriz inteira descontraído para índices de matriz
Lembre-se também de que, nas versões 4.x, a indexação de matriz coberta exige todo o atributo da matriz como uma chave de índice obrigatória na definição do índice da matriz. Por exemplo, veja novamente a consulta a seguir:
1 2 3 |
EXPLAIN SELECT * DO padrão WHERE type = 'person' AND ANY media IN `social-media` SATISFIES media.type = 'website' END; |
O índice da matriz coberta correspondente à consulta acima seria:
1 2 3 |
CREATE INDEX ism_covered ON `default` ( DISTINCT ARRAY media FOR media IN `social-media` END, `social-media`) WHERE type = 'person'; |
Observe que a segunda chave de índice mídia social
é obrigatório, por exemplo, para cobrir a consulta a seguir:
1 2 3 |
EXPLAIN SELECT mídia DO padrão WHERE type = 'person' AND ANY media IN `social-media` SATISFIES media IS NOT NULL END; |
No Couchbase 5.0, essa mesma consulta será coberta pelo índice ismo
no início deste artigo.
É importante observar que esse recurso traz muito poder aos índices de matriz. Porque, agora, cada entrada no índice de matriz consome menos espaço de armazenamento e memória. Ele permite os seguintes benefícios:
- Uso de índices de matriz cobertos para matrizes maiores
- Proporciona mais eficiência e desempenho às consultas que usam índices de matriz cobertos
Indexação de meta-informações de documentos
Vamos dar uma guinada e discutir as novas metainformações que podem ser indexadas. Anteriormente, os índices podiam ser criados na variável meta().id
mas agora tanto a propriedade meta().cas
e meta().expiração
são compatíveis.
Então, como criamos um índice que usa as metapropriedades como chaves? Não é muito diferente do que você já sabe. Veja os seguintes índices de cobertura, por exemplo:
1 2 3 4 5 |
CREATE INDEX idx_cas ON `default` ( META().cas, META().expiration ) CREATE INDEX idx_exp ON `default` ( META().expiration ) |
Agora, se eu quisesse usar o idx_cas
e idx_exp
em uma consulta N1QL, eu poderia fazer algo como o seguinte:
1 2 3 4 5 6 7 |
SELECT META().id, META().cas DO padrão WHERE META().cas > 1489531586248179712; SELECT META().id, META().expiration DO padrão WHERE META().expiration > NOW_MILLIS(); |
Então, por que seria possível indexar essas propriedades? Bem, e se você quisesse fazer uma consulta de todos os documentos que expiraram hoje ou de todos os documentos que foram modificados hoje?
Para obter mais informações sobre o CAS e as propriedades de expiração, acesse aqui. Para obter mais informações sobre a indexação ou o uso do N1QL com o Couchbase, consulte a seção Portal do desenvolvedor do Couchbase.