Como migrar do MySQL para o Couchbase Server 2.0: Parte 1

Se você tiver um banco de dados criado com MySQL, talvez esteja se perguntando se, e principalmente como, esse banco de dados (e seu aplicativo) pode ser transferido para o Couchbase. O maior obstáculo não são os aspectos técnicos da criação do Couchbase ou do armazenamento das informações (embora eles sejam importantes); em vez disso, trata-se de analisar os dados de uma maneira diferente e saber como isso altera o funcionamento do aplicativo.

Vamos começar analisando como você pode transformar a estrutura do seu banco de dados MySQL no Couchbase Server e como a consulta ao seu banco de dados no Couchbase Server difere dos métodos usados no MySQL.

Pense primeiro na estrutura de dados

O MySQL (e outros bancos de dados baseados em tabelas e SQL) força você a pensar sobre seus dados em termos de tabelas. Todos os seus dados são uma tabela e, ao armazenar estruturas complexas, uma parte individual dos dados pode ser dividida em uma ou mais tabelas. Para alguns aplicativos e tipos de dados, essa é uma maneira perfeitamente lógica e razoável de abordar e armazenar seus dados. Mas, para alguns aplicativos, a estrutura da tabela não se adapta muito bem aos dados que você deseja armazenar.

Vejamos um exemplo típico, um banco de dados de receitas. Isso é algo que conheço bem, pois Cheffy.com foi desenvolvido com base no MySQL. A estrutura básica da tabela é uma tabela principal, chamada receita, que contém o nome da receita, o subtítulo, a descrição e as porções. Outras informações relevantes sobre a receita, como a lista de ingredientes, as etapas do método, os metadados e as palavras-chave, são armazenadas em outras tabelas, vinculadas à receita original por um ID de receita exclusivo. Você pode ver isso, basicamente, na figura abaixo.

???

Há alguns benefícios potenciais nessa estrutura - certas operações, por exemplo, podem ser muito simples e fáceis. Por exemplo, deseja encontrar todas as receitas que tenham o ingrediente "cenoura"? Você pode realizar uma consulta na tabela de ingredientes procurando por "cenoura" e, a partir disso, obter uma lista de receitas correspondentes. Com o uso de uniões, você pode obter uma lista de receitas, seu título e outras informações da tabela de receitas, pesquisando na tabela de ingredientes, usando a união para conectar o ID da receita na tabela de ingredientes ao ID da receita no título da receita.

???

Embora esse tipo de pesquisa seja fácil, coletar todas as informações sobre uma receita, por exemplo, quando se deseja exibir a receita para o usuário, pode ser muito complicado. Você poderia fazer isso com uma única consulta, mas às vezes pode ser mais fácil fazer isso com várias consultas, uma para obter os dados da receita, outra para os ingredientes, outra para os metadados e assim por diante. Na camada de aplicativos, isso é feito automaticamente para criar um objeto, que é usado como base para exibir a receita ao usuário de forma formatada.

Para muitos usuários e aplicativos, uma camada especial é criada para fazer isso ou um dos muitos sistemas de mapeamento objeto-relacional é usado para mapear os dados da estrutura tabular subjacente para o objeto de nível superior com o qual o aplicativo (e o usuário) está familiarizado. As receitas aqui são um exemplo, mas se estendem a uma ampla variedade de outros aplicativos, incluindo faturamento (fatura, fornecedor, destino, linhas de fatura) e postagens de blog (conteúdo da postagem, palavras-chave, criador, comentários).

Essas soluções baseadas em tabelas não são inerentemente ruins, mas para esse tipo de situação, as principais informações estão sendo armazenadas em várias tabelas, e isso significa manter as várias tabelas sincronizadas entre si. Por exemplo, o que acontece quando um registro é excluído? É preciso excluir todos os outros registros que possam ter sido vinculados ao original, seja manualmente ou usando exclusões em cascata.) Da mesma forma, quando se trata de carregar as informações sobre uma receita, você acaba executando de 5 a 10 consultas das informações juntas.

O Couchbase adota uma abordagem diferente. Em vez de várias tabelas nas quais você pode armazenar diferentes partes de informações, no Couchbase você armazena uma única estrutura (no formato JavaScript Object Notation JSON). O formato JSON permite uma estrutura complexa de campos, matrizes, objetos e tipos escalares, que podem ser combinados em um registro inteiro. Isso significa que agora você pode representar sua entidade antiga, com várias tabelas (receita, post de blog), como um único "documento".

Agora, tudo relacionado à sua receita está em um único lugar e podemos carregar a receita em uma única operação a partir do banco de dados do Couchbase.

Não há estrutura ou definição para o conteúdo; qualquer documento em um banco de dados do Couchbase pode conter qualquer coisa e qualquer estrutura. No entanto, você pode aplicar uma rotina de validação que verifique a estrutura do documento fornecido ao banco de dados. A validação pode abranger tanto os campos quanto seu conteúdo.

Além disso, lembre-se de que, como não há uma estrutura rígida, há mais flexibilidade no que e como você armazena as informações. Adicionar uma nova seção ao seu documento de receita que contenha dados sobre quem forneceu a receita ao seu banco de dados é um caso de extensão da estrutura do documento.

Também não há noção de várias tabelas. Há apenas o banco de dados e os documentos contidos nesse banco de dados. Se você quiser oferecer suporte a diferentes tipos de informações no mesmo banco de dados, poderá adicionar um campo ao documento. Por exemplo, para identificar uma receita, você pode fazer isso:

A identificação do tipo de registro pode ser usada em outras áreas do sistema de banco de dados para ajudá-lo a reconhecer (e selecionar) os dados que estão sendo carregados.

Se tudo é um documento, como posso obter uma lista de registros?

Na primeira seção, falei sobre como, com o MySQL, você poderia construir uma instrução SQL simples para obter uma lista de receitas que incluam cenouras. No MySQL, isso funciona pesquisando valores na tabela de ingredientes para encontrar IDs de receitas e, em seguida, usar uma união para obter os títulos das receitas na tabela de receitas. Para aumentar a velocidade, você normalmente usaria um índice para melhorar o tempo de resposta da consulta, economizando a análise individual de cada registro.

No Couchbase, tudo é um documento, e não há nenhum método interno para pesquisar o campo de uma tabela, já que não há campos nem tabelas. Como não existe uma estrutura rígida (e não há como o mecanismo de banco de dados identificar os campos em um documento de forma livre), como fazemos qualquer operação que normalmente opera em uma lista (ou tabela)? Tudo, desde uma simples "listar todas as receitas" até "encontrar todas as receitas com um ingrediente de cenoura", depende do uso de uma lista em algum lugar.

O Couchbase suporta uma construção chamada de visualização. Em princípio, as visualizações são semelhantes às visualizações do MySQL, exceto pelo fato de que, no Couchbase, as visualizações são a única maneira de obter listas de documentos do banco de dados, e não um método de obter uma alternativa .

Na verdade, uma visualização define três coisas:

• A estrutura das informações incluídas na visualização. Você pode pensar nisso como a definição da estrutura da tabela, da mesma forma que definiria uma tabela no MySQL.
• Os campos ou informações que podem ser pesquisados. Uma visualização gera dois elementos, uma chave e um valor. As chaves formam o método pelo qual você pode pesquisar ou, mais especificamente, selecionar o conteúdo do banco de dados que deseja.
• Um índice sobre a estrutura e as chaves. O índice é usado para melhorar a pesquisa dos dados informados na exibição.

As visualizações são definidas em um documento de design, em JavaScript, usando uma função que aceita um documento. Quando a visualização é construída, todos os documentos do banco de dados são fornecidos à visualização, e a visualização emite as informações que você deseja que apareçam na saída. Não se preocupe com o JavaScript, pois ele é executado no servidor, não no cliente.

Então, voltando ao MySQL por um momento, uma consulta (sem uma cláusula WHERE) seleciona os campos a serem retornados na saída da consulta e constrói uma lista de linhas correspondentes na saída. Então, olhando para uma instrução SQL:

Ao executar uma consulta no MySQL, o servidor MySQL obtém as informações na tabela ou tabelas e, em seguida, constrói a lista de registros (e campos correspondentes) a serem retornados, da seguinte forma:

No Couchbase, as visualizações constroem uma lista de registros a partir das informações individuais do documento, criando um índice como efeito colateral desse processo. O resultado é uma lista de todos os documentos gerados pela visualização.

???

No MySQL, quando você executa uma consulta com uma cláusula WHERE, o índice (espero) é usado para ajudar a selecionar os registros que você deseja escolher:

???

No Couchbase, a visualização gerada é a sua tabela e, quando você consulta a visualização, o Couchbase usa os valores-chave (e o índice associado que foi gerado), com os valores de consulta que você especifica filtrando as informações retornadas para gerar a lista final de registros correspondentes.

Esse método de especificar as tabelas que você deseja consultar permite simplificar e otimizar a maneira como você extrai informações do banco de dados. Mas isso também significa que você precisa pensar um pouco mais sobre como deseja consultar as informações.

Próxima vez

Agora você sabe como o MySQL armazena e consulta informações e como esse conhecimento pode ser traduzido quando você migra informações para o Couchbase Server 2.0. Na próxima vez, começaremos a criar algumas consultas com base no que aprendemos e a examinar consultas mais avançadas e o processo de migração.