Práticas recomendadas e tutoriais

Introdução ao Couchbase para desenvolvedores de MongoDB e especialistas em NoSQL

Há seis mil anos, os sumérios inventaram a escrita para o processamento de transações. Gray e Reuter

De qualquer forma, o MongoDB é um banco de dados JSON popular orientado a documentos. Nos últimos doze anos, ele cresceu de seu início humilde de um único bloqueio por banco de dados para uma transação moderna de vários documentos com isolamento de instantâneos. A MongoDB University treinou um grande número de desenvolvedores para desenvolver no banco de dados MongoDB.

Atualmente, existem muitos bancos de dados JSON. Embora seja fácil começar com o MongoDB para aprender a usar o NoSQL e o esquema JSON flexível, muitos clientes escolhem o Couchbase por causa do desempenho, da escala e do SQL. À medida que avança na avaliação e evolução do banco de dados, você deve aprender sobre outros bancos de dados JSON. Estamos trabalhando em um curso de treinamento on-line para que os especialistas em MongoDB aprendam facilmente o Couchbase. Até publicarmos esse curso, você terá que ler este artigo :-) 

Se você conhece RDBMS como Microsoft SQL Server e Oracle, temos cursos fáceis de seguir para aprender a mapear seu conhecimento de banco de dados para o Couchbase com esses dois cursos:

  1. CB116m - Introdução ao Couchbase para especialistas em MSSQL
  2. CB116o - Introdução ao Couchbase para especialistas em Oracle

RESUMO

O MongoDB e o Couchbase têm muitas coisas em comum. Ambos são NoSQL bancos de dados distribuídosAmbos usam o modelo JSON; ambos têm linguagens de consulta de alto nível com suporte para operações select-join-project; ambos têm índices secundários; ambos têm um otimizador que escolhe o plano de consulta automaticamente. Ambos suportam replicação intra e intercluster.

Como era de se esperar, há diferenças. Algumas são mais significativas do que outras. O Couchbase foi projetado para ser distribuído desde o início. Por exemplo, o contêiner de dados Bucket é sempre distribuído - sem nada para fragmentar. Basta adicionar novos nós e o sistema distribuirá automaticamente. A replicação intracluster não requer novos servidores - basta definir o número de réplicas e está tudo pronto. Do ponto de vista da interação com o desenvolvedor, a grande diferença é a própria linguagem de consulta - o MongoDB tem uma linguagem linguagem de consulta proprietária e o Couchbase tem N1QL - SQL para JSON. O MongoDB também usa seu índice baseado em B-Tree para pesquisa e lançou recentemente o $searchbeta para o serviço Atlas usando o Apache Lucene; o Couchbase tem um Pesquisa de texto completo.

Esperamos que as diferenças no Couchbase sejam aquelas que facilitam sua vida. Vamos nos aprofundar.

TÓPICOS DE ALTO NÍVEL

  1. Recursos
  2. Arquitetura
  3. Objetos de banco de dados
  4. Tipos de dados
  5. Modelo de dados
  6. SDK
  7. Linguagem de consulta
  8. Índices
  9. Otimizador
  10. Transações
  11. Análises

RECURSOS

ARQUITETURA

Versão para laptop: 

MongoDB:  Basta instalar e usar o Mongodb em seu laptop com os parâmetros corretos e pronto. Um único processo para lidar com todo o banco de dados. Isso mudou um pouco na versão 4.2, em que você precisaria do mongos para executar suas transações. Todos os recursos do MongoDB (dados, indexação, consulta) estão disponíveis aqui, exceto a pesquisa de texto completo, disponível apenas no serviço Atlas.

 

 

 

 

Couchbase: O Couchbase é diferente. Ele abstraiu cada um dos serviços (dados, índice, consulta, pesquisa, análise, eventos) e você tem a opção de escolher quais dos recursos deseja executar em sua instância para otimizar os recursos. Uma instalação típica tem dados, índice e consulta. A pesquisa, os eventos e a análise serão executados em seu laptop - instale e use-os de acordo com seu caso de uso.

 

 

 

Implantação de cluster: Como acontece com a maioria dos bancos de dados NoSQL, tanto o MongoDB quanto o Couchbase podem ser escalonados. No MongoDB, você pode escalonar por fragmentação a coleção em vários nós. Você pode fragmentar por hash ou intervalo. Sem um shard explícito, cada coleção permanece em um único shard. Os servidores de configuração armazenam os metadados e a configuração do cluster. O MongoDB é distribuído de maneira uniforme e o Couchbase é distribuído de maneira multidimensional. O processo (serviço) do Mongodb gerencia os dados, o índice e a consulta em cada fragmento (nó), enquanto o Mongos faz o processamento da consulta distribuída e a fusão dos resultados intermediários e não gerencia nenhum dado ou índice. O Mongos atua como coordenador e o mongodb é a abelha operária. 

O Couchbase pode ser implantado em uma distribuição uniforme com cada nó gerenciando os dados e todos os serviços - dados, índice, consulta, análise e eventos. Cada serviço é uma camada do banco de dados tradicional. Esses serviços são fracamente acoplados - eles são executados em diferentes espaços de processo e se comunicam por meio de uma rede. Portanto, eles podem ser implantados uniformemente em um único nó ou distribuídos multidimensionalmente em um cluster. A escolha depende de sua carga de trabalho e dos SLAs. Os dados em si são armazenados em buckets. Todos os buckets são particionados por hash entre determinados nós - isso é automático e não requer nenhuma especificação. Quando o aplicativo tem as chaves do documento, ele pode operar diretamente nos dados sem nenhum nó intermediário. Essa é uma das principais diferenças arquitetônicas que contribuem para o alto desempenho e a expansão do Couchbase. Além disso, não há servidores de configuração. Os metadados e seu gerenciamento são incorporados ao banco de dados principal. O serviço de dados gerencia os dados, o cluster e a replicação em um cluster do Couchbase. A replicação entre vários clusters do Couchbase é gerenciada pelo XDCR. Leia este artigo para entender os mecanismos de replicação no MongoDB e no Couchbase:  Replicação em bancos de dados de documentos NoSQL (Mongo DB vs Couchbase)

Dentro da implantação do cluster.

Os componentes e a implantação do cluster do MongoDB são explicados aqui e assumo isso como conhecimento prévio. Evitarei repetir.

A implantação do Couchbase começa com o serviço de dados de valor-chave. Esse é o armazenamento de dados de valor-chave distribuído em hash (consistente). Ele também tem replicação intracluster integrada, eliminando qualquer necessidade de servidores de réplica ou servidores de configuração separados. O serviço de consulta orquestra a execução de N1QL consultas. Usos GSI (Indexação secundária global), FTS (Full-Text Search) conforme necessário. O FTS gerencia o índice de texto completo e pode ser consultado diretamente ou através do N1QL serviço de consultaA função Eventing permite que você acione automaticamente a ação (executando uma função Javascript) na mutação de dados. O Couchbase Mecanismo de análise é um mecanismo de consulta e dados MPP. Faz uma cópia dos dados e os redistribui em seus nós, executa a consulta em paralelo para obter o melhor desempenho possível. Tudo isso pode ser usado sem problemas pelo rico conjunto de APIs disponíveis em nosso SDKs disponível em todos os idiomas populares. 

OBJETOS DE BANCO DE DADOS

O MongoDB tem uma coleção e um banco de dados como objetos lógicos com os quais os usuários precisam trabalhar. Tradicionalmente, o Couchbase tinha apenas o Baldes. O Bucket funcionava tanto para o gerenciamento de recursos (por exemplo, a quantidade de memória usada), quanto para a segurança e o contêiner de dados. Em 6.5, introduzimos a noção de coleta e escopo como uma prévia para desenvolvedores. Essa hierarquia bucket:scope:collection é análoga à database:schema:table do RDBMS. Isso torna o banco de dados mais seguro e um melhor multilocatário. Na versão 6.5, sem a visualização para desenvolvedores, cada compartimento usa um escopo e uma coleção padrão, o que torna a transição perfeita.

RDBMS

MongoDB

Couchbase

Banco de dados

Banco de dados

Balde

Tabela

Coleção

Balde

Futuro: Coleção

Linha

Documento (BSON)

Documento (JSON padrão)

Coluna

Campo/Atributo

Campo/Atributo

Partição (tabela/coleção/bucket)

Não particionado por padrão.

O particionamento de hash e intervalo (sharding) é suportado manualmente.

Partição (hash automático)

Notas para os desenvolvedores

No MongoDB, você começa com sua instância (implantação) e cria bancos de dados, coleções e índices.

No Couchbase, você começa com sua instância e cria seus buckets e índices. Cada bucket pode ter vários tipos de documentos, portanto, cada documento deve ter um campo designado pelo aplicativo para reconhecer seu tipo. {"type": "parts"}. Como cada compartimento pode ter qualquer número de tipos de documentos, você deve evitar criar muitos compartimentos. Isso também significa que, ao criar um índice, você estará interessado em criar um índice para cada tipo: cliente, peças, pedidos etc. Portanto, a criação do índice incluirá uma cláusula WHERE para o tipo de documento.

CREATE INDEX ix_customer_zip ON customer(zip) WHERE type = "customer";

SELECT * FROM customer WHERE zip = 94040 AND type = "customer"

Cada documento do MongoDB contém um campo _id de identificação de documento fornecido explicitamente ou gerado implicitamente.

No Couchbase, os usuários devem gerar e inserir uma chave de documento imutável para cada documento. Ao inserir via N1QL, você pode usar a função UUID() para gerar uma para você. Porém, é uma boa prática ter uma chave de documento estrutura regular para a chave do documento.

TIPOS DE DADOS

O modelo de dados do MongoDB é BSON e o modelo de dados do Couchbase é JSON. O tipo proprietário BSON tem alguns tipos que não existem no JSON. O JSON tem os tipos string, numérico, booleano (verdadeiro/falso), matriz e objeto. O BSON tem string, numérico, booleano, array, objeto, binário, UTC DateTime, timestamp e muitas outras extensões proprietárias personalizadas. No Couchbase, todos os dados relacionados a tempo são armazenados como string no formato ISO 8601. O N1QL do Couchbase tem uma infinidade de funções para extrair, converter e calcular a hora. Os detalhes completos das funções são disponível neste artigo

Tipo de dados

MongoDB

Couchbase

JSON

Números

Número BSON

Número JSON

{ "id": 5, "balance":2942.59 }

Cordas

Cadeia de caracteres BSON

Cadeia de caracteres JSON

{"name": "Joe", "city": "Morrisville" }

booleano

BSON Booleano

JSON Booleano

{"premium": true, "pending": false}

data e hora

Formato de dados personalizados

JSON ISO 8901 String com funções de extração, conversão e aritmética

{ "soldate": “2017-10-12T13:47:41.068-07:00” }

MongoDB:

{ "soldate": ISODate(“2012-12-19T06:01:17.171Z”)}

dados espaciais

GeoJSON

Oferece suporte ao vizinho mais próximo e à distância espacial.

"geometria": {"type": "Point", "coordinates": [-104.99404, 39.75621]}

FALTANDO

Sem suporte

FALTANDO

NULL

JSON Nulo

JSON nulo

{"last_address": null }

Objetos

Objetos JSON flexíveis

Objetos JSON flexíveis

{"address" (endereço): {"street": "1, Main street", "city": Morrisville, "zip": "94824″}}

Matrizes

Matrizes JSON flexíveis

Matrizes JSON flexíveis

{ "hobbies": ["tennis", "skiing", "lego"]}

TUDO SOBRE A FALTA

MISSING é o valor de um campo ausente no documento ou literal JSON.

{"name": "joe"} Tudo, exceto o campo "name", está faltando no documento. Você também pode definir o valor de um campo como MISSING para fazer com que o campo desapareça. Os bancos de dados relacionais tradicionais usam lógica de três valores com true, false e NULL. Com a adição de MISSING, o N1QL usa lógica de 4 valores

Você tem as seguintes expressões com MISSING.  

ESTÁ FALTANDO

Retorna true se o documento não tiver um campo de status

FROM CUSTOMER WHERE status is MISSING;

NÃO ESTÁ FALTANDO

Retorna true se o documento tiver um campo de status

FROM CUSTOMER WHERE status is NOT MISSING;

AUSENTE E NULO

MISSING é uma quantidade ausente conhecida

null é um UNKNOWN conhecido. Você pode verificar se há um valor nulo semelhante a MISSING com a expressão IS NULL ou IS NOT NULL.

JSON válido: {"status": null}

Valor ausente

Basta fazer com que o campo de qualquer tipo desapareça, definindo-o como MISSING

UPDATE CUSTOMER SET status = MISSING WHERE cxid = "xyz232"

MODELAGEM DE DADOS

Relacionamento MongoDB Couchbase 
1:1
  • Objeto incorporado (implícito)
  • Referência da chave do documento
  • Objeto incorporado (implícito)
  • Referência da chave do documento
1:N
  • Matriz de objetos incorporada
  • Chave do documento Referência
  • Consulta com o operador $lookup
  • Matriz de objetos incorporada
  • Chave do documento Referência
  • Consulta com uniões INNER, LEFT OUTER, RIGHT OUTER, NEST, UNNEST
N:M
  • Matriz de objetos incorporada
  • Matrizes de objetos com referências
  • Difícil de consultar com o operador $lookup
  • Matriz de objetos incorporada
  • Matrizes de objetos com referências
  • Consulta com uniões INNER, LEFT OUTER, RIGHT OUTER, NEST, UNNEST

GERENCIAMENTO DE ESPAÇO FÍSICO

Tipo de índice MongoDB Couchbase 
Armazenamento de mesa Diretório do sistema de arquivos Diretório do sistema de arquivos
Armazenamento de índices Diretório do sistema de arquivos Diretório do sistema de arquivos
Particionamento - Dados Há suporte para fragmentação por intervalo e hash. Particionamento de hash

Armazenado em 1024 vbuckets

Particionamento - Índice Vinculado à estratégia de fragmentação da coleção, pois todos os (sub)índices são locais para cada nó mongod. Sempre separado do Bucket

Índice global (pode usar uma estratégia diferente da do bloco/coleção)

Oferece suporte ao particionamento de hash dos índices.

Particionamento de intervalo, a indexação parcial é manual por meio de índices parciais.

SDKs

Meu conhecimento pessoal dos dois SDKs é limitado. Deve haver APIs, drivers e conectores equivalentes nos dois produtos. Caso contrário, informe-nos.

SDK MongoDB Couchbase 
Java Driver java do MongoDB SDK Java do Couchbase, 

Simba e CDATA JDBC

C Driver C do MongoDB

Driver ODBC

Couchbase C SDK,

Simba e CDATA ODBC

.NET, LINQ Provedor Mongodb .NET. Provedor do Couchbase .NET

Provedor LINQ

PHP, Python, Perl, Node.js SDK do MongoDB em todos esses idiomas SDK do Couchbase em todos esses idiomas
golang Mongodb go sdk SDK do Couchbase Go

LINGUAGEM DE CONSULTA

SELECIONAR:   O Mongo tem várias APIs para selecionar os documentos. find() e aggregate() podem fazer o trabalho de instruções SELECT simples. Veremos o aggregate() mais adiante nesta seção.

INSERIR

No MongoDB, fornecer _id é opcional. Se você não fornecer seu valor, o Mongo gerará o valor do campo e o salvará. O fornecimento de document KEY é obrigatório no Couchbase.

ATUALIZAÇÃO

DELETE

MERGEA operação MERGE em um conjunto de documentos JSON é frequentemente necessária como parte de seu processo de ETL ou de atualizações diárias. A instrução MERGE pode envolver fontes de dados complexas com predicados complexos baseados em regras de negócios. O Couchbase fornece a operação MERGE padrão com a mesma semântica. No MongoDB, era necessário escrever um longo programa para fazer isso, mas algumas das regras de operação definidas (por exemplo, cada documento deve ser atualizado APENAS uma vez) são difíceis de aplicar em um aplicativo. No Couchbase, você pode simplesmente usar a função Declaração MERGEcomo o RDBMS.

DESCREVER:

Os dados JSON são autodescritivos e flexíveis. O auxiliar de esquema do MongoDB está disponível via Visualização da bússola somente na Enterprise Edition.

O Couchbase tem o INFER para analisar e entender o esquema. Tanto o serviço de consulta quanto o serviço analítico podem inferir o esquema.

    1. Serviço de consulta Comando INFER
    2. O Analytics Service tem array_infer_schema() função.

Aqui está o exemplo de saída do INFER.

EXPLICAR

O Explain informa o plano de consulta para cada consulta - os índices escolhidos, os predicados e outros pushdowns, os tipos de junção, a ordem de junção etc. Tanto o MongoDB quanto o Couchbase produzem o explain em formato JSON - algo natural para bancos de dados JSON.

No Couchbase, basta prefixar a declaração com EXPLAIN. Você pode explicar qualquer declaração no N1QL.

O workbench de consulta também tem uma explicação visual, juntamente com a criação de perfis. (para uma consulta)

GRUPO POR

A cláusula "GROUP BY" do MongoDB faz parte da API aggregate(). Aqui está a comparação.

Diferentemente do SQL e do N1QL, a API de consulta do MongoDB tem muitos significados implícitos sem definições formais. Com N1QL, você está ciente dos agrupamentos (b e c) e agregações (SUM(a)) explicitamente.

ORDER BY

OFFSET e LIMIT

Eles são comumente usados para o método de paginação de deslocamento, suportado pelo Mongo e pelo Couchbase. No entanto, paginação do conjunto de teclas é uma abordagem superior que utiliza menos recursos e tem melhor desempenho. O Mongo usa as cláusulas $skip e $limit e o N1QL usa OFFSET e LIMIT. Não tenho certeza sobre as otimizações de paginação feitas no MongoDB.

JOINs

As junções são geralmente desencorajadas em bancos de dados NoSQL e no MongoDB em particular. Mas o mundo real é complexo e não pode ser desnormalizado em uma única coleção. O MongoDB tem o operador $lookup para a união e faz um loop aninhado entre uma coleção (potencialmente fragmentada) e outra coleção (não pode ser fragmentada). No Couchbase, todos os buckets são particionados (sharded). Operações JOINs (INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, junções com subconsultas, NEST e UNNEST) Temos um artigo detalhado que mostra as operações equivalentes entre o MongoDB e o JSON. Recomendo que você leia o artigo Juntando JSON: comparando Couchbase e MongoDB.

Tipo de JOIN MongoDB Couchbase 
INNER JOIN  Não. O $lookup é uma união externa esquerda limitada somente em coleções sem fragmentos. Os aplicativos precisam fazer isso e, em seguida, remover os documentos sem os documentos correspondentes.   A cláusula ON requer referência à chave do documento. Somente Equi-join
UNIÃO EXTERNA ESQUERDA $lookup limitado.  

Não é possível unir matrizes. É necessário achatar as matrizes manualmente antes da união.

União externa esquerda completa, incluindo predicados de matriz na cláusula ON.
UNIÃO EXTERNA DIREITA Sem suporte. Deve ser tratado no aplicativo Suporte limitado a RIGHT OUTER JOIN; foi possível contornar o problema com o uso de outros JOINs.
JUNÇÃO EXTERNA COMPLETA Sem suporte. Deve ser tratado no aplicativo Trabalhou com o uso de outros JOINs.

CONCESSÃO e REVOGAÇÃO

ÍNDICES

Abaixo está uma visão geral dos recursos de índice do MongoDB e do Couchbase. Ambos têm uma variedade de índices. Os tipos e o uso do índice do Couchbase estão bem documentados no artigo: Crie o índice certo e obtenha o desempenho certo. Além disso, o Couchbase tem um consultor de índice integrado para a declaração individual bem como o carga de trabalho e, além disso, tem o Serviço de consultoria de índices que é atualizado mensalmente.

Tipo de índice MongoDB Couchbase 
Índice primário Varreduras de tabela, índice primário Índice primário
Índice secundário Índice secundário Índice secundário
Índice composto Índice composto Índice composto
Índice funcional 

(Índice de Expressão)

Não disponível Índice Funcional, Índice de Expressão
Índice parcial Não disponível Índice parcial
Índice particionado de intervalo Índice particionado por intervalo, Intervalo, Lista, Ref, Hash, Índice particionado híbrido Intervalo manual particionado usando o Índice parcial
Índice ARRAY 1. Índice baseado em B-Tree com uma chave de matriz por índice.

2. A chave de uma matriz pode ser simples ou composta (várias chaves).

1. Índice baseado em árvore B com uma chave de matriz por índice.

2. A chave da matriz pode ser composta

3. Usando SEARCH(): Índice baseado em árvore invertida com um número ilimitado de chaves de matriz por índice.

Índice de matriz em expressões Não disponível Sim
Objetos Sim Sim

PESQUISA DE TEXTO COMPLETO

O produto MongoDB tem pesquisa de texto e agora está experimentando a integração do Lucene em seu serviço Atlas por meio do $searchbeta recurso. O Couchbase tem um recurso indexação de pesquisa de texto completo que pode ser executado em seu laptop e no cluster. Novamente, temos um artigo detalhado comparando o pesquisa de texto, recurso por recursocom exemplos. O Couchbase 6.5 integra o FTS com N1QLtornando a consulta ainda mais complexa.

OTIMIZADOR

Um otimizador de consultas tenta reescrever a consulta para melhor otimização, escolher o índice mais adequado, decidir o pushdown do índice, a ordem de junção, o tipo de junção e criar um plano que o mecanismo possa executar. Cada banco de dados tem um otimizador especializado que entende os recursos e as peculiaridades do mecanismo.

Recurso MongoDB Couchbase 
Tipo de otimizador Consulta baseada em forma Baseado em regras

Baseado em custos (visualização em 6.5)

Seleção de índice Consulta baseada em forma Baseado em regras

Baseado em custos (visualização em 6.5)

Reescrita de consulta Não Sim, limitado.
JOIN Order Como está escrito, procedimento que usa a estrutura de agregação Especificado pelo usuário (da esquerda para a direita)
Tipo de associação Loop aninhado Loop aninhado

Junção de Hash

DICAS Sim. $hint Sim.

USAR ÍNDICE, USAR HASH

EXPLICAR 1TP4Explicar EXPLICAR
Explicação visual Sim Sim.
Criação de perfil de consulta Sim sim

TRANSAÇÕES

Os bancos de dados NoSQL foram inventados para evitar SQL e transações. Com o tempo, cada banco de dados está adicionando um ou outro, ou ambos! O MongoDB adicionou o transações com vários documentos com isolamento de snapshot. O Couchbase adicionou o transações com vários documentos com isolamento de confirmação de leitura. As transações de vários documentos ainda não são compatíveis com o N1QL.

Recurso MongoDB Couchbase 
Atualizações do índice Os índices são mantidos de forma síncrona Os índices são mantidos de forma assíncrona
Atomicidade Documento único

Multi-documento (em 4.2)

Documento único

Multi-documento (na versão 6.5)

Consistência Os dados e os índices são atualizados de forma síncrona. Por padrão, leitura suja nos dados e índices.  O acesso aos dados é sempre consistente

Os índices têm vários níveis de consistência (UNBOUNDED, AT_PLUS, REQUEST_PLUS)

Isolamento Padrão: Leitura suja

Transação: Isolamento de instantâneos

Bloqueio otimista com verificação de CAS

Transações: Isolamento atômico monotônico

Durabilidade Durável com opção de maioria de gravação. Durável com confirmação após a replicação

ANALÍTICA

Análise do Couchbase foi projetado para fornecer insights sobre seus dados JSON sem ETL - NoETL para NoSQL. Os dados JSON no armazenamento de dados de valor-chave são copiados para o serviço de análise que distribui os dados em seu armazenamento. O serviço de consulta e o serviço de dados do Couchbase foram projetados para lidar com um grande número de operações ou consultas simultâneas para executar os aplicativos. O serviço de análise foi projetado para analisar um grande número de documentos para fornecer insights sobre os negócios. Em termos tradicionais, o serviço de análise é projetado para OLAP, e os demais são projetados para OLTP. O MongoDB não tem um serviço de análise equivalente. Você teria que sobrecarregar seu cluster existente com cargas de trabalho OLTP e OLAP. Como você aprenderá, não existe almoço grátis. As grandes varreduras necessárias para a carga de trabalho de análise afetarão as latências de suas consultas OLTP. Em seguida, você começa a alocar novos nós para suas cópias secundárias e terciárias dos dados nos quais você pode fazer a carga de trabalho de leitura. O que acontecerá ou deverá acontecer em um failover? O secundário assume o controle, mas novamente afeta sua carga de trabalho OLTP.

Há um segundo motivo para um serviço distinto: o processamento de consultas para análise requer uma abordagem diferente das consultas OLTP. Há um grande conjunto de recursos para você aprender sobre esse serviço, incluindo o livro de Don Chamberlin, co-inventor do SQL.

  1. SQL++ para usuários de SQL: UM TUTORIAL:  https://resources.couchbase.com/analytics/sql-book
  2. Couchbase Analytics: Sob o capô - Connect Silicon Valley 2018: https://www.youtube.com/watch?v=1dN11TUj58c
  3. De SQL para NoSQL
  4. NoETL para NoSQL - Análise em tempo real com o Couchbase: https://www.youtube.com/watch?v=MIno71jTOUI
  5. N1QL: Consultar ou analisar?
  6. Parte 2: N1QL: Consultar ou analisar?

Resumo: Parte dois

Os bancos de dados são extraordinariamente úteis. Eles têm nuances e também são pegajosos. Eles são essenciais para a civilização. Os sumérios inventaram a escrita para o processamento de transações: criar um banco de dados a partir de tábuas de argila para manter o controle de impostos, terras, ouro e descobrir informações. Haverá bancos de dados para sempre. Cada banco de dados é diferente - sejam eles bancos de dados SQL ou bancos de dados NoSQL. Nem todos os bancos de dados SQL são iguais. Nem todos os bancos de dados NoSQL são iguais. A compreensão dos diferentes bancos de dados aumenta a flexibilidade e a eficácia de sua organização.

RECURSOS: Parte Dois

  1. SQL++ para usuários de SQL: UM TUTORIAL:  https://resources.couchbase.com/analytics/sql-book
  2. N1QL Guias práticos
  3. Blogs do Couchbase 6.5: https://www.couchbase.com/blog/tag/6.5/

 

 

 

Compartilhe este artigo
Receba atualizações do blog do Couchbase em sua caixa de entrada
Esse campo é obrigatório.

Autor

Postado por Keshav Murthy

Keshav Murthy é vice-presidente de P&D da Couchbase. Anteriormente, ele trabalhou na MapR, IBM, Informix e Sybase, com mais de 20 anos de experiência em design e desenvolvimento de bancos de dados. Ele liderou a equipe de P&D de SQL e NoSQL na IBM Informix. Recebeu dois prêmios President's Club na Couchbase e dois Outstanding Technical Achievement Awards na IBM. Keshav é bacharel em Ciência da Computação e Engenharia pela Universidade de Mysore, Índia, detém dez patentes nos EUA e tem três patentes pendentes nos EUA.

Deixe um comentário

Pronto para começar a usar o Couchbase Capella?

Iniciar a construção

Confira nosso portal do desenvolvedor para explorar o NoSQL, procurar recursos e começar a usar os tutoriais.

Use o Capella gratuitamente

Comece a trabalhar com o Couchbase em apenas alguns cliques. O Capella DBaaS é a maneira mais fácil e rápida de começar.

Entre em contato

Deseja saber mais sobre as ofertas do Couchbase? Deixe-nos ajudar.