Migração de SQL para NoSQL Databases

Etapas para migrar dados de um banco de dados relacional para NoSQL

O uso de um banco de dados relacional em seus aplicativos .NET não está isento de algumas limitações, como a incapacidade de lidar com mais carga sem substituir o hardware existente (aumento de escala) e a incapacidade de atualizar seu modelo de dados rígido, ou seja, linhas e colunas. Se você está enfrentando esses desafios, talvez já tenha decidido mudar seu banco de dados para NoSQL. Se você ainda não está convencido, então você pode querer ler Sua marca NoSQL?

Considerando o caso em que você está sem opções para dimensionar sua camada de banco de dados e optou por mover seus dados para NoSQL, a difícil tarefa da migração pode estar impedindo você de dar esse salto.

Embora a migração seja uma grande tarefa, se dividida em etapas, ela pode ser abordada de maneira muito organizada, facilitando sua vida. Este whitepaper está aqui para ajudá-lo a organizar seu processo de migração em 6 etapas lógicas.

ASP.NET Core Gargalos de desempenho — Processo de migração em 6 etapas lógicas

Se você seguir estas etapas simples, elas certamente o ajudarão em seu processo de migração. Este trabalho considera que você já conhece o básico sobre as funcionalidades do NosDB, uma rede NoSQL Banco de dados de documentos. Se não, por favor, dirija-se ao site do Network Development Group. Abaixo apresento os detalhes do processo acima mencionado.

Etapa 1: identificar o escopo

A primeira e mais importante etapa é entender seu modelo de negócios e o esquema do banco de dados. Você também precisará entender completamente como seu aplicativo acessa esses dados e o fluxo de dados de e para seu banco de dados. Isso ajuda a identificar duas informações principais:

A parte do seu esquema de banco de dados que é mais acessada (leituras, gravações ou ambos)
Dados que são agrupados, ou seja, sempre acessados juntos para leituras e gravações.

Ter essas informações ajuda a identificar as principais decisões nas etapas restantes. Portanto, este também é o passo mais crucial.

Etapa 2: Identificar NoSQL Requisitos de configuração

Depois de entender seu modelo de negócios e o fluxo de dados, você estará em boa forma para tomar algumas decisões aproximadas sobre como implantar seu NoSQL cluster, com base em seus requisitos de negócios. Por exemplo, anotar o número atual de aplicativos em execução, número de usuários e taxa de acesso são algumas métricas importantes. Observar qual parte de seus dados é altamente sensível, ou seja, você precisa ter um backup a todo custo, também ajuda a decidir a estratégia de implantação dos nós de réplica.

Desde uma NoSQL database é um banco de dados distribuído, você pode aproveitar a natureza distribuída a seu favor e implantá-lo de acordo com seus requisitos de negócios. A maior vantagem que você obtém, além da escalabilidade, é distribuir/implantar seu NosDB fragmentos de cluster em diferentes locais GEO. Isso permite que você implante shards perto da localização geográfica do seu aplicativo e evite dispendiosas viagens de rede. E aumenta o desempenho do aplicativo.

Apenas lembre-se de que tudo o que estamos fazendo aqui é esboçar os requisitos. Definitivamente, revisitaremos essas configurações depois de identificarmos, criarmos e otimizarmos nossas coleções.

Etapa 3: converter e otimizar coleções JSON

Agora que você tem os requisitos básicos de seu cluster de implantação, seu 'esboço' ditará suas estratégias de otimização.

Converter tabelas em coleções

Primeiro, basta converter as tabelas do banco de dados relacional em coleções e converter suas colunas em atributos. Isto é o normalizado dados provenientes de um banco de dados relacional.

Desnormalize dados incorporando documentos

Em seguida, você precisa desnormalizar tabelas isoladas, ou seja, tabelas que não significam nada a não ser correlacionadas com outra tabela. Em termos relacionais, tabelas isoladas são tabelas de junção. Por exemplo, a Detalhes do pedido em um banco de dados Northwind fazem mais sentido quando mencionados com referência a um Pedido. Portanto, a escolha certa seria incorporar o OrderDetails dentro do Encomenda documentos.

Converter relações

Agora, o que resta são essas coleções contendo documentos que têm seus respectivos tabelas de junção embutidos dentro deles. Mas e as relações muitos-para-muitos, um-para-muitos e outras? É aqui que seu conhecimento sobre dados agrupados naturalmente e dados acessados juntos é útil.

No Exemplo de migração do banco de dados NorthWind, Experiência e dinâmica de loja e Encomenda as tabelas estão relacionadas, mas nem sempre são acessadas juntas. Então, não faz sentido incorporar o Objeto Cliente no interior da Documento do pedido. Além disso, incorporar o Documento do cliente irá duplicar dados desnecessariamente, o que queremos evitar tanto quanto possível. Caso contrário, uma única alteração no perfil do Cliente exigirá que o aplicativo faça a alteração em todos os Pedido.Cliente documentos. Um custo de computação desnecessário.

Por outro lado, as Categorias são sempre exigidas pelo aplicativo sempre que o Produto é buscado; portanto, este é um bom candidato para incorporação. E não esqueça que a beleza dos documentos JSON é que eles também podem suportar arrays e arrays de documentos JSON, para enriquecer seus objetos.

Modelo Híbrido - Melhor da Normalização e Desnormalização

Desde uma NoSQL esquema é baseado no fluxo de dados do aplicativo, se uma coleção tem vantagens de mantê-la incorporada e não incorporada, então adote o modelo híbrido.

No banco de dados de exemplo Northwind, referenciado na página anterior, esse fenômeno pode ser visto na Categoria e Produto mesas. O cenário é que sempre que um Produto é acessado, o aplicativo precisa conhecer sua Categoria. Mas o aplicativo também precisa descobrir Produtos by Categoria.

Se o Categoria foi mantido em uma tabela separada, uma única busca de produto significaria duas chamadas de banco de dados, uma para buscar o Produto e o outro para buscar o respectivo Categoria, portanto, o custo extra da rede. Se apenas o Categoria foi incorporado, então para descobrir todas as categorias você teria que executar a seguinte instrução SQL:

SELECT DISTINCT product.Category.CategoryName FROM Products;

Uma consulta SQL simples, mas não muito eficiente, não é? Então a resposta é manter o Categoria documento em uma coleção separada, mas incorporar apenas a parte que é necessariamente exigida pelo Produto. Isso é chamado de Modelo híbrido.

Por exemplo, em nosso cenário, quando o aplicativo busca o documento do produto, é necessário apenas conhecer o Categoria Nome e Categoria Descrição. Portanto, é completamente desnecessário incorporar o Categoria Imagem em todos os documentos do Produto. Na verdade, se duplicado, será necessário muito armazenamento desnecessário e aumentará o tamanho do documento, impondo uma viagem de rede cara.

Este é um caso de uso perfeito de um Modelo Híbrido, portanto, as coleções teriam o seguinte formato:

"Product" {
   "name": "string",
   "category": {
      "name": "string",
      "description": "string",
   }
}

e armazenando Categoria separadamente também:

"Category" {
   "name": "string",
   "description": "string",
   "picture": byte[]
   }
}

Decida sua estratégia de distribuição

A próxima coisa a decidir é a estratégia de distribuição provável de suas coleções. O esboço inicial de seus requisitos de configuração afeta diretamente isso.

Você tem três opções para sua estratégia de distribuição:

Distribuição baseada em intervalo: Essa estratégia permite definir como os dados são distribuídos entre os nós de acordo com os intervalos especificados para cada estilhaço. Por exemplo, se o seu NosDB cluster é GEO distribuído com um shard em Nova York e outro em Londres, então os dados gerados e exigidos pelas aplicações existentes em Nova York devem estar no mesmo local GEO, otimizando assim os custos da rede. Essa estratégia é usada principalmente em clusters distribuídos GEO, mas também tem outros casos de uso.
Distribuição baseada em hash: O hash permite distribuir dados entre os estilhaços de maneira uniforme, distribuindo assim também a carga de maneira uniforme. Essa estratégia não é a melhor escolha para um cluster distribuído GEO, mas é ótima para NosDB clusters em um único data center.
Coleção Fragmentada Única (Desativar Distribuição): Isso desativa completamente a distribuição em uma coleção. Use essa opção se seu conjunto de dados for pequeno ou se você desejar especificamente que ele esteja em uma única máquina.

Depois de decidir sua estratégia de distribuição, convém revisar a otimização de sua coleção e sua estratégia de implantação para ver se elas podem ser otimizadas ainda mais. Algumas iterações geralmente são suficientes para chegar a uma decisão.

Etapa 4: migrar dados

Finalmente, depois de um brainstorming pesado, aqui vem a parte relativamente fácil, ou seja, migrar dados do banco de dados relacional para o banco de dados relacional. NoSQL database.

Primeiro crie seus objetos .NET representando suas coleções e documentos JSON. Sim! nenhum ORM é necessário para inserir dados, pois a API .NET converte automaticamente seus objetos .NET em documentos JSON. (Apenas uma observação, no entanto, você também pode optar por usar a integração ADO.NET fornecida junto com NosDB).

Em seguida, acesse seu banco de dados relacional e preencha esses objetos .NET e insira-os no NoSQL database. Você também pode usar gatilhos CLR e UDFs CLR fornecidos por NosDB para ajudar na sua migração.

Depois de ter seus dados migrados, agora é a hora de migrar seu aplicativo para adotar os dados em termos de coleções e documentos. Sem NosDB você não tem a opção de usar ADO.NET ou CLR Triggers & UDFs, mas ainda pode usar a API.

Etapa 5: migrar o aplicativo

Existem várias maneiras de migrar seu aplicativo .NET de trabalho para NosDB. NosDB suporta operações SQL como SELECT, INSERT, UPDATE e DELETE. O uso de operações SQL reduz muito a curva de aprendizado para migrar seu aplicativo, ou seja, você pode usar a sintaxe com a qual está acostumado. Você pode até mesmo gerenciar o cluster de banco de dados em NosDB usando SQL.

NosDB suporta SQL com todas as múltiplas maneiras que o banco de dados pode ser acessado, a saber:

API .NET
- ADO.NET
- LINQ
API Java
API REST

Você também pode usar a API do lado do servidor para melhorar o desempenho do seu aplicativo, aproveitando o poder da distribuição usando estruturas como MapReduce. Se você não estiver usando NosDB você só tem a opção de chamar a API diretamente. SQL e ADO.NET são fornecidos apenas por NosDB.

Etapa 6: validar a migração

Após a migração, a validação é a última etapa de todo o processo: verifique todos os seus testes, valide os dados migrados e sua aplicação. Esta etapa depende totalmente de você e de seus processos de negócios. Banco o recém-incorporado NoSQL database. Verifique os limites da configuração atual do cluster (embora você possa expandir sempre que quiser) e equipe-se com as ferramentas certas, como NosDB Management Studio para gerenciar e monitorar todo o cluster a partir de um único local.

É isso! Se você seguir estas etapas, poderá organizar sua migração de um banco de dados relacional para um NoSQL database em um processo lógico de 6 etapas.