Acho que é seguro assumir que todo desenvolvedor ou administrador de sistemas já tocou no MySQL em algum momento. Geralmente era o
rito de passagem para qualquer novo desenvolvedor há alguns anos, quando linguagens como PHP estavam florescendo. Agora você pode estar em uma situação em que
as coisas mudaram e agora seu banco de dados pode precisar de uma mudança. Mais especificamente, uma mudança para um banco de dados NoSQL sem esquema.
À primeira vista, se você estiver examinando as diferenças, isso pode parecer uma tarefa assustadora. O que devo fazer com todas as minhas tabelas e
restrições? Como posso consultar meus dados? Quais linguagens de desenvolvimento posso usar?
Vamos desacelerar e analisar um cenário em que você está usando um RDBMS MySQL e gostaria de fazer a transição para o Couchbase.
Principais diferenças entre o MySQL e o Couchbase
Falando de MySQL, presumo que você já saiba que ele é um banco de dados relacional que consiste em tabelas, linhas e colunas.
Bastante padrão quando se trata de qualquer banco de dados relacional. Esse não é o caso de um banco de dados de documentos NoSQL como o Couchbase.
Em vez disso, você está trabalhando com objetos e matrizes JSON que não têm estrutura e praticamente nenhuma limitação.
Embora a modelagem de dados seja, em minha opinião, a maior diferença, ela não é a única. No entanto, vamos começar por aí.
O modelo de dados do banco de dados relacional
Para simplificar, vamos nos ater a um modelo de dados pequeno. Ele sempre pode ser ajustado para acomodar um cenário mais complexo. Nosso modelo de dados
será o seguinte:
cliente
- id: chave primária numérica
- firstname: varchar
- lastname: varchar
endereço_do_cliente
- id: chave primária numérica
- cidade: varchar
- estado: varchar
- zip: varchar
- customer_id: chave estrangeira numérica
As duas tabelas acima e suas colunas não são as mais complexas, mas ainda assim provam ser relacionais por meio das colunas primária e
relações de chave estrangeira.
Opções para um modelo de dados NoSQL
Os documentos NoSQL são um pouco diferentes porque, nesse caso, eles não têm esquema. Isso significa que há várias opções quando se trata de
se trata de modelar os dados que vimos para o MySQL.
Documentos de referência
A referência a documentos provavelmente lhe parecerá mais familiar em termos de dados relacionais. Em um RDBMS como o MySQL, você está se referindo a
a outras linhas de dados por meio de chaves primárias e estrangeiras. Não existe o conceito de chave primária ou estrangeira no NoSQL, mas isso não significa que o NoSQL seja uma chave primária.
significa que você não pode estabelecer o mesmo tipo de relacionamento.
Por exemplo, veja os seguintes documentos NoSQL:
c::1
|
1 2 3 4 5 6 7 |
{ "tipo": "cliente", "first_name": "Nic", "last_name": "Raboy" } |
ca::1
|
1 2 3 4 5 6 7 8 9 |
{ "tipo": "customer_address" (endereço do cliente), "cidade": "São Francisco", "estado": "CA", "zip": "94101", "customer_id": "c::1" } |
Suponha que os documentos acima sejam modelados de forma semelhante ao seu equivalente em RDBMS. c::1 é apenas um valor de identificação que criei para o
documento do cliente e ca:1 é uma identificação que criei para o endereço_do_cliente documento.
Embora ainda não os consultemos, podemos pensar nesses documentos como sendo o equivalente a uma única linha em um arquivo
banco de dados relacional. Por exemplo, uma linha da tabela cliente A tabela MySQL seria um documento em
Couchbase.
Muito semelhante, correto?
Incorporação de documentos
É aqui que as coisas podem se tornar muito diferentes em relação ao MySQL. Como o JSON é um dado complexo, podemos ter matrizes em nosso
documentos. Então, e se quiséssemos manter todos esses dados juntos?
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "tipo": "cliente", "first_name": "Nic", "last_name": "Raboy", "endereços": [ { "cidade": "São Francisco", "estado": "Califórnia" }, { "cidade": "Vista da montanha", "estado": "Califórnia" } ] } |
No documento acima, estamos armazenando todos os endereços de um determinado cliente em uma matriz dentro do documento. Isso é feito em vez de
criar um novo documento para cada endereço e fazer referência ao documento do cliente.
Você deve estar se perguntando o que acontece se tiver relacionamentos muito complexos nos dados do MySQL que, quando transpostos para
Couchbase, resultaria no fato de os mesmos dados serem incorporados em mais de um documento do Couchbase. Isso poderia acontecer, mas não é
uma coisa ruim. Você não precisa de dados normalizados em um banco de dados NoSQL, como o Couchbase. Entretanto, se você estiver realmente preocupado, por que não
misturar as duas abordagens? Manter dados como, por exemplo histórico do cliente juntos sem relacionamentos e se referem a
outros que podem mudar com mais frequência.
Diferenças de consulta entre o MySQL e o Couchbase
Couchbase N1QL vs MySQL SQL
O MySQL, assim como todas as plataformas de bancos de dados relacionais, usa sua própria variante de SQL. Supondo que estejamos usando o esquema definido anteriormente
para o MySQL, podemos consultar os clientes e seus endereços da seguinte forma:
|
1 2 3 4 5 6 |
SELECIONAR c.primeiro nome, c.sobrenome, ca.cidade, ca.estado DE endereço_do_cliente ca ESQUERDA JUNTAR cliente c ON ca.ID do cliente = c.id |
E se eu lhe dissesse que você pode fazer quase a mesma coisa com os dados NoSQL do Couchbase? Veja a seguinte consulta N1QL do Couchbase:
|
1 2 3 4 5 6 |
SELECIONAR c.primeiro nome, c.sobrenome, ca.cidade, ca.estado DE `balde-nome` ca ESQUERDA JUNTAR `balde-nome` c ON CHAVES ca.cliente_id |
Não é muito diferente, certo? Você pode notar que estamos usando nome do balde duas vezes. Isso ocorre porque não há
no NoSQL e todos os diferentes documentos e tipos de documentos existirão no mesmo bucket. A chave do documento é o
valor ao qual nos unimos.
Agora, digamos que você queira inserir novos dados no MySQL cliente tabela. No MySQL, você pode fazer algo assim:
|
1 2 3 4 |
INSERIR PARA cliente (id, primeiro_nome, sobrenome) VALORES (1, "Arun, Gupta); |
Se você quiser inserir dados no Couchbase, poderá fazer o seguinte:
|
1 2 3 4 |
INSERIR PARA `balde-nome` (CHAVE, VALOR) VALORES (1, {"first_name": "Arun", "last_name": "Gupta"}); |
Mais informações sobre o Couchbase N1QL podem ser encontradas em aqui.
Diferenças de desenvolvimento entre o MySQL e o Couchbase
Em meu artigo anterior sobre Oracle para CouchbaseEm minha palestra, escrevi sobre as diferenças de desenvolvimento na perspectiva do Java. Para
consistência, usarei Java nos exemplos a seguir. O MySQL certamente não está restrito ao Java e o Couchbase também não.
O driver JDBC do MySQL
Em um aplicativo Java, se você quisesse se conectar a um banco de dados MySQL, usaria o driver Java Database Connector (JDBC).
Com o driver incluído em seu projeto, seja por meio de ferramentas como o Maven ou manualmente, você pode carregá-lo e começar a consultar os dados.
Um exemplo disso pode ser o seguinte:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Classe.forName("com.mysql.jdbc.Driver"); Propriedades informações = novo Propriedades(); informações.colocar("usuário", "nraboy"); informações.colocar("senha", "senha"); Conexão conexão = Gerenciador de driver.getConnection("jdbc:mysql://HOST:PORT/DATABASE", informações); Declaração stmt = conexão.getConnection().createStatement(); ResultSet rs = stmt.executeQuery("SELECT * FROM customer"); enquanto(rs.próxima()) { // rs.getString("first_name"); } stmt.próximo(); |
O SDK Java do Couchbase
Para se conectar ao Couchbase por meio de um aplicativo Java, você usaria o Couchbase Java SDK em vez de um driver JDBC, embora
Existe um. O motivo pelo qual usaríamos o SDK é que as coisas se tornam incrivelmente fáceis com ele.
Por exemplo, com o SDK do Couchbase, o mesmo tipo de operação do Oracle pode ser parecido com o seguinte:
|
1 2 3 4 5 6 7 8 |
CouchbaseCluster.criar(HOST).openBucket(BUCKET, SENHA); Cordas consulta = "SELECT * FROM `bucket-name-here`"; N1qlQueryResult resultado da consulta = balde.consulta(consulta); para (N1qlQueryRow fila : resultado da consulta) { // row.value().toMap(); } |
O que foi dito acima pressupõe, é claro, que você baixou o Couchbase Java SDK ou usou o Maven para obtê-lo.
Diferenças de ferramentas
Ao usar o MySQL, você tem muitas ferramentas que podem ser usadas. Por exemplo, se quiser executar consultas no banco de dados, você
poderia usar o CLI do MySQL. Você ainda pode usar ferramentas comparáveis ao fazer a mudança para o Couchbase.
Se estiver procurando uma ferramenta de linha de comando, você pode usar CBQ para consultar seus dados. Se você for um usuário avançado do
MySQL Workbench, não se preocupe, pois o Couchbase tem seu próprio Workbench de consulta como
de Servidor Couchbase 4.5.
Migração de dados
No que diz respeito aos seus dados, você deve estar se perguntando como pode tirar os dados do MySQL e colocá-los no Couchbase o mais rápido possível.
Laurent Doguin escreveu uma excelente ferramenta de migração para Movendo dados do MySQL para o Couchbase.
Basicamente, o que essa ferramenta faz é se conectar ao seu banco de dados MySQL por meio de Java e do driver JDBC. Cada linha de cada tabela será convertida em um documento JSON exclusivo.
Embora não haja restrições de banco de dados nos novos documentos JSON, as chaves ainda existirão e poderão ser consultadas por meio do N1QL.
Conclusão
O MySQL e o Couchbase são duas tecnologias de banco de dados muito diferentes, mas a forma como você as utiliza não precisa ser assim. O modelo de dados relacional
ainda pode ser preservado até certo ponto em um banco de dados de documentos NoSQL. Todos os dados armazenados podem ser consultados no Couchbase da mesma forma que você faria
em um banco de dados MySQL usando consultas SQL. A principal diferença entre os dois é que você não está limitado aos dados que pode armazenar
e como você pode armazená-lo.
Se você for um usuário do banco de dados Oracle, este post semelhante que escrevi sobre a migração do Oracle para o Couchbase.
[...] Mudança do MySQL para o Couchbase [...]
Olá, qual índice deve ser criado para seu exemplo de consulta de união acima?
OK, entendi, o PRIMARY INDEX é necessário nesse caso