A migração de SQL para NoSQL parece uma contradição, mas graças aos avanços e inovações no banco de dados NoSQL do Couchbase Server, ela está se tornando mais fácil.
Nesta postagem, apresentarei a você uma ferramenta chamada SqlServerToCouchbaseuma tentativa de código aberto de uma ferramenta automatizada para ajudá-lo a "converter" um banco de dados do Microsoft SQL Server em um banco de dados do Couchbase Server. Ao longo do caminho, examinaremos as estratégias de migração de dados, as comparações entre os termos SQL e NoSQL e as compensações entre os dois tipos de bancos de dados. Mesmo que você não esteja usando o SQL Server ou o Couchbase ServerEste artigo pode ajudá-lo em seus esforços de conversão.
Antes de começar, lembre-se de que a mudança entre dois bancos de dados (SQL para NoSQL ou SQL para SQL) é muito parecido com a tradução entre dois idiomas. Existem automações como Babelfish, Google Translate e assim por diante. Essas ferramentas são muito úteis para começar, mas não substituem (eventualmente) a imersão no idioma.
#googletranslatefails #oversættelsesfejl pic.twitter.com/SNNoGHBD1Q
- EgoLibris (@egolibris) 17 de maio de 2017
Além da tradução da sintaxe, há também as expressões idiomáticas e a cultura que envolve qualquer tecnologia. Nenhuma ferramenta de automação pode capturar todas as nuances, mas vamos tentar para ver até onde podemos chegar.
Converter SQL em NoSQL: Estratégias de migração de dados
Se estiver pensando em migrar dados do SQL Server para o Couchbase (ou de qualquer banco de dados relacional para o Couchbase), a primeira etapa é chegar a um acordo sobre seus objetivos e planos de alto nível. Há vários caminhos a serem seguidos, e cada um deles oferece riscos, esforços e benefícios. Aqui estão alguns exemplos de como converter SQL em NoSQL:
Nível | Descrição | Risco | Esforço | Benefícios |
---|---|---|---|---|
1 |
Reescrita: Sem migração, escreva tudo de novo |
5/5 |
5/5 |
⭐⭐⭐⭐⭐ |
2 |
Redesenho do esquema: Mantenha sua lógica de negócios, reescreva sua camada de dados e esquema, redesenhe totalmente seu esquema com um modelo otimizado para NoSQL |
4/5 |
4/5 |
⭐⭐⭐⭐ |
3 |
Refatorar primeiro: Mantenha tudo, mas refatore sua lógica de dados e o esquema RDBMS em um modelo otimizado para NoSQL |
4/5 |
3/5 |
⭐⭐⭐ |
4 |
Otimizar depois: Hospedar seu esquema com o mínimo de alterações possível, fazer com que o aplicativo seja executado na nova tecnologia, refatorar/otimizar o esquema conforme necessário para o desempenho |
3/5 |
4/5 |
⭐⭐⭐ |
5 |
Apenas hospede-o: Hospede seu esquema com o mínimo de alterações possível. |
2/5 |
2/5 |
⭐⭐ |
Historicamente, os bancos de dados NoSQL têm se concentrado na reconstrução de "Nível 1" ou em projetos greenfield. Embora essa abordagem obtenha o máximo de benefícios do NoSQL desde o início, as reconstruções são sempre caras e arriscadas.
No entanto, o Couchbase Server, juntamente com os novos recursos que virão no Couchbase Server 7 (você pode baixar o Couchbase 7 beta neste momento), permite uma abordagem de nível 5 (seguida de nível 4) que reduz o risco e o custo de experimentar o NoSQL. Você não necessariamente colherá todos os benefícios do NoSQL imediatamente, mas começar a usá-lo está mais fácil do que nunca.
Converter consulta SQL em NoSQL
A maioria dos desenvolvedores e usuários de bancos de dados está familiarizada com os bancos de dados relacionais. Esquemas, tabelas, linhas e colunas, consultas SQL, transações ACID. A linguagem de consulta do Couchbase (N1QL) reconhece há muito tempo que o SQL é o língua franca de bancos de dados. Atualmente, o N1QL oferece recursos completos de SQL, incluindo JOINs, indexação robusta, agregação, CTEs e muito mais. Isso faz com que seja relativamente simples para os desenvolvedores de SQL serem produtivos, mesmo como novatos na oferta de NoSQL do Couchbase.
Dica: Fazer check-out Por que os desenvolvedores valorizam o Couchbase e outras pesquisas independentes da TechValidate.
E se a maioria dos outros conceitos relacionais pudesse ser traduzida e convertida com a mesma facilidade? Vamos ver como os conceitos do SQL Server podem ser mapeados para os conceitos do Couchbase Server.
SQL Server | Servidor Couchbase | Notas |
---|---|---|
Servidor |
Aglomerado |
Um dos principais benefícios do NoSQL é a escalabilidade e a alta disponibilidade que o clustering proporciona. |
Catálogo/Banco de dados |
Balde |
Os buckets do Couchbase também oferecem um cache integrado para melhorar o desempenho |
Esquema |
Escopo |
O esquema geralmente é apenas "dbo" no SQL Server, mas nem sempre. |
Tabela |
Coleção |
As coleções são mais flexíveis: não há colunas ou restrições predefinidas |
Linha |
Documento |
JSON em vez de dados simples |
tSQL |
N1QL |
O N1QL não é "semelhante ao SQL", é uma implementação completa do SQL com extensões JSON, às vezes chamada de SQL++ |
Chave primária |
Chave do documento |
As chaves primárias devem ser exclusivas por tabela, as chaves de documento devem ser exclusivas por coleção |
Índice |
Índice |
SQL: Índices em coluna(s), Couchbase: Índices em campo(s) JSON |
Com esse mapeamento como linha de base, podemos escrever um programa para converter automaticamente o conteúdo de um banco de dados do SQL Server em um banco de dados do Couchbase Server?
Acredito que podemos chegar à maior parte do caminho, e criei um projeto de código aberto chamado SqlServerToCouchbase para fazer exatamente isso.
Converter banco de dados SQL em NoSQL/Catálogo em Bucket
Vou usar o AdventureWorks fornecidos pela Microsoft no SQL Server. Estarei migrando para um banco de dados Couchbase 7 (atualmente em versão betamas provavelmente será RTM este ano).
Observação: Estou usando o AdventureWorks2016 porque é a versão do SQL Server que tenho disponível. A maioria das versões mais antigas e mais recentes deve funcionar bem, mas se você tiver algum problema, crie um problema no GitHub!
Você pode criar um bucket manualmente no Couchbase Server ou pode fazer com que o utilitário crie o bucket automaticamente para você.
Esquema para escopo
No SQL Server, um esquema é como um "namespace" que permite agrupar objetos (como tabelas) para fins de organização/segurança. Por exemplo, o AdventureWorks contém esquemas como HumanResources, Person, Production etc.
Muitos projetos não usam realmente o esquema além do esquema padrão "dbo". No entanto, um esquema pode ser usado para agrupar dados de um microsserviço específico ou de um locatário específico em um aplicativo multilocatário.
No Couchbase 7, há um conceito muito semelhante chamado "escopo". Ele oferece os mesmos benefícios de organização e segurança para microsserviços ou multitenancy.
Com base em suas preferências, o utilitário SqlServerToCouchbase pode criar escopos com base nos esquemas do SQL Server ou pode ignorá-los e colocar tudo em um esquema chamado "_default" (que é aproximadamente equivalente a "dbo"). No exemplo acima, optei por criar escopos para cada esquema do AdventureWorks.
Da mesa à coleção
No SQL Server, uma tabela é uma relação estritamente imposta (portanto, "relacional") que organiza os dados em conjunto.
No Couchbase, não há nenhuma relação estritamente imposta, mas no Couchbase 7, há um conceito de "coleção". Embora isso não possa impor nenhuma restrição aos dados (a não ser uma chave de documento exclusiva, análoga a uma chave primária), ele ainda pode fornecer o mesmo nível de organização de dados.
O utilitário SqlServerToCouchbase criará uma coleção para cada tabela que encontrar. Se você optar por criar escopos na etapa anterior, essas coleções serão colocadas dentro do escopo apropriado.
Dica: Os nomes de tabela no SQL Server podem ser muito mais longos do que os nomes de coleção no Couchbase Server. Portanto, se estiver migrando um banco de dados com nomes de tabela longos, será necessário fornecer explicitamente um nome de coleção novo e mais curto.
E quanto à conversão da consulta SQL?
O utilitário SqlServerToCouchbase (ainda) não converterá suas consultas do SQL Server para você, mas aqui está uma comparação entre uma consulta do SQL Server do AdventureWorks e a consulta equivalente do banco de dados AdventureWorks convertido no Couchbase.
A consulta tSQL abaixo (extraída de Documentação da Microsoft) foi projetado para "retornar o nome e o sobrenome de todos os funcionários e as cidades em que eles moram".
1 2 3 4 5 6 7 8 9 10 |
SELECIONAR RTRIM(p.FirstName) + ' ' + LTRIM(p.Sobrenome) AS Nome, d.Cidade DE AdventureWorks2016.Pessoa.Pessoa AS p INNER JUNTAR AdventureWorks2016.Recursos Humanos.Funcionário e ON p.BusinessEntityID = e.BusinessEntityID INNER JUNTAR (SELECIONAR bea.BusinessEntityID, a.Cidade DE AdventureWorks2016.Pessoa.Endereço AS a INNER JUNTAR AdventureWorks2016.Pessoa.BusinessEntityAddress AS bea ON a.EndereçoID = bea.EndereçoID) AS d ON p.BusinessEntityID = d.BusinessEntityID ORDEM BY p.Sobrenome, p.FirstName; |
Os resultados dessa consulta:
Com quase nenhuma alteração, uma consulta muito semelhante pode ser executada como uma consulta N1QL no Couchbase:
1 2 3 4 5 6 7 8 9 10 |
SELECIONAR RTRIM(p.FirstName) || ' ' || LTRIM(p.Sobrenome) AS Nome, d.Cidade DE AdventureWorks2016.Pessoa.Pessoa AS p INNER JUNTAR AdventureWorks2016.Recursos Humanos.Funcionário e ON p.BusinessEntityID = e.BusinessEntityID INNER JUNTAR (SELECIONAR bea.BusinessEntityID, a.Cidade DE AdventureWorks2016.Pessoa.Endereço AS a INNER JUNTAR AdventureWorks2016.Pessoa.BusinessEntityAddress AS bea ON a.EndereçoID = bea.EndereçoID) AS d ON p.BusinessEntityID = d.BusinessEntityID ORDEM BY p.Sobrenome, p.FirstName; |
A única diferença na versão N1QL é o uso de ||
em vez de +
para concatenação de strings, e os resultados sendo JSON em vez de um Result Set:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[ { "Cidade": "Bothell", "Nome": "Syed Abbas" }, { "Cidade": "Cravo", "Nome": "Kim Abercrombie" }, { "Cidade": "Kenmore", "Nome": "Hazem Abolrous" }, { "Cidade": "Seattle", "Nome": "Pilar Ackerman" }, { "Cidade": "Monroe", "Nome": "Jay Adams" }, { "Cidade": "Issaquah", "Nome": "François Ajenstat" }, { "Cidade": "Renton", "Nome": "Amy Alberts" }, { "Cidade": "Bellevue", "Nome": "Greg Alderson" }, { "Cidade": "Renton", "Nome": "Sean Alexander" }, { "Cidade": "Renton", "Nome": "Gary Altman" }, /// ... etc ... ] |
Isso acontece não significa que a consulta N1QL está tão otimizada quanto possível. Por exemplo, a consulta N1QL acima não usa chaves de documento e talvez possa se beneficiar de mais índices ou de índices diferentes. (Como ela só precisa de FirstName, LastName e City, cobrir índice(s) pode ser apropriado aqui, por exemplo). Mas como essa é uma conversão de "nível 5", deve ser suficiente para começar.
Conversão de índice para índice
O SQL Server permite que você crie índices em tabelas para uma ou mais colunas.
O Couchbase Server também permite que você criar índices em coleções para um ou mais campos JSON.
O utilitário SqlServerToCouchbase fará uma conversão direta dos índices do SQL Server.
Por exemplo, um índice no SQL Server:
1 |
CRIAR ÍNDICE SalesTaxRate_StateProvinceID_TaxType ON AdventureWorks2016.Vendas.Taxa de imposto sobre vendas (ID da província, TaxType) |
se tornará um índice no Couchbase Server:
1 |
CRIAR ÍNDICE sql_SalesTaxRate_StateProvinceID_TaxType ON AdventureWorks2016.Vendas.Taxa de imposto sobre vendas (ID da província, TaxType) |
O Couchbase converterá todos os índices, mas o nível de indexação do SQL Server pode ser muito alto ou muito baixo, dependendo das consultas que você planeja executar. Felizmente, o Couchbase Server 6.6 e versões mais recentes têm um recurso interno de Consultor de índices (um sistema autônomo A versão baseada na web também está disponível), que recomendará índices para qualquer consulta N1QL que você desejar.
Observação: O Couchbase Server NÃO permite o equivalente a varreduras de tabela completas (ou seja, índices primários) por padrão. O utilitário SqlServerToCouchbase não cria índices primários para cada coleção. Se você tentar executar uma consulta e receber uma mensagem de erro como "No index available on keypace" (Nenhum índice disponível no espaço de chave), essa é a sua dica para tentar usar o Index Advisor.
Você também pode usar o Monitor de índice do Couchbase para verificar a Taxa de solicitação de índice (entre outras características do índice). Isso pode ajudá-lo a identificar os índices de que você não precisa mais.
Linha para o documento
Depois que os escopos e as coleções apropriados estiverem instalados, o utilitário SqlServerToCouchbase poderá ser usado para obter todas as linhas de dados de cada tabela e gravá-las em documentos JSON em cada coleção.
Na maioria das vezes, os tipos de dados compatíveis com o SQL Server mapear bem para JSON tipos de dados. Alguns exemplos:
Tipo de dados do SQL Server | Tipo de dados JSON |
---|---|
char, varchar, nvarchar, etc |
string |
inteiro, decimal, float, real, etc. |
número |
bit |
booleano |
data, datetime, hora, etc. |
string |
Além disso, há alguns tipos de dados especializados do SQL Server que o utilitário SqlServerToCouchbase também é capaz de manipular.
Por exemplo, a função geografia
torna-se um objeto JSON aninhado com propriedades como "Lat" e "Long" e "Z". Aqui está o documento convertido para a linha de dados na captura de tela acima.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "AddressID": 1, "AddressLine1": "1970 Napa Ct.", "AddressLine2": nulo, "Cidade": "Bothell", "StateProvinceID": 79, "PostalCode" (Código Postal): "98011", "SpatialLocation" (Localização espacial): { "IsNull": falso, "STSrid": 4326, "Lat": 47.7869921906598, "Longo": -122.164644615406, "Z": nulo, "M": nulo, "HasZ": falso, "HasM": falso }, "rowguid": "9aadcb0d-36cf-483f-84d8-585c2d4ec6e9", "ModifiedDate" (Data de modificação): "2007-12-04T00:00:00" } |
Se houver um tipo de dados específico sobre o qual você esteja curioso, experimente o utilitário SqlServerToCouchbase e veja o que acontece. Se ele não estiver convertendo os dados como você espera, crie um problema no GitHub.
De usuário para usuário
O SQL Server suporta uma variedade de tipos de usuários, funções de segurança e permissões nos níveis de banco de dados, esquema e tabela.
O Couchbase Server tem autenticação baseada em função (RBAC) que também permite que várias permissões sejam definidas nos níveis de bucket, escopo e coleção.
O utilitário SqlServerToCouchbase criará usuários correspondentes e fará o possível para converter as permissões o máximo possível.
O AdventureWorks não contém nenhum exemplo de usuários com permissões refinadas. Criei meu próprio exemplo para representar um subconjunto de permissões para algumas tabelas no esquema Person.
O usuário correspondente no Couchbase terá permissões semelhantes:
Enquanto o SQL Server tem apenas uma API para trabalhar com dados (tSQL), o Couchbase tem várias: N1QL, chave/valor, pesquisa de texto completo, análise e muito mais. Portanto, o número de permissões convertidas para o usuário no Couchbase é maior. À medida que você avança para o "nível 4", essas permissões podem ser ajustadas conforme necessário.
Advertência: Usuários, autenticação, autorização e segurança é uma área em que se deve ter cuidado e fazer uma revisão manual. Não deixe que essa etapa seja totalmente automatizada até que você tenha certeza de que o resultado é o desejado.
Próximas etapas
O utilitário de "conversão" criará uma conversão do Couchbase Server de seu banco de dados do SQL Server. No entanto, atualmente ele não consegue converter nenhum código de cliente. Esse é um problema difícil para qualquer migração de banco de dados, não apenas do SQL Server para o NoSQL. No entanto, fique de olho neste blog para artigos futuros sobre a migração de consultas SQL e código de cliente!
Enquanto isso, algumas das etapas que você precisará examinar:
- Você precisará alterar o acesso aos dados em seu cliente para usar um SDK do Couchbase. Por exemplo, se estiver usando ADO.NET, Dapper, PetaPoco, etc., você poderá usar o SDK do Couchbase .NET.
- Usando o Entity Framework? Dê uma olhada na seção Projeto Linq2Couchbase. (Se estiver usando Java, consulte Dados do Spring Couchbase.)
- O Couchbase é compatível com transações ACID! Para .NET, Couchbase.Transações estão atualmente na versão beta. No Couchbase 7, o N1QL também oferece suporte a
INICIAR/COMPROMETER/RETROCEDER TRANSAÇÃO
- O N1QL do Couchbase é uma implementação completa de SQL. Entretanto, como todos os dialetos SQL, há diferenças entre o N1QL e o tSQL. Algumas consultas podem funcionar como estão, mas, na maioria dos casos, é provável que haja diferenças de sintaxe. Dê uma olhada no navegador Tutorial interativo de N1QL.
- Procurando uma abordagem semelhante com o MySQL? Dê uma olhada em Migração prática de relacional para coleções para uma abordagem semelhante que usa Python / CLI.
- Está procurando uma abordagem semelhante com o PostgreSQL? Dê uma olhada em Couchgresum projeto de código aberto com suporte da comunidade que usa uma abordagem semelhante com Golang / CLI.
Resumo
O Couchbase Server 7 está definido para ser a maior e mais importante versão do Couchbase Server. Fique de olho no blog do Couchbase para mais artigos como este, criados para ajudá-lo em sua jornada de conversão de SQL para NoSQL.
O Couchbase Server 7 beta está disponível agora mesmo para você Faça o download e experimente. Como se trata de uma versão beta, qualquer feedback ou pergunta que você tiver será muito bem-vindo: confira o Seção de suporte beta nos fóruns do Couchbase para o Couchbase Server 7 e outras versões beta/preview.