Nesta série de postagens do blog, apresentarei as considerações sobre a mudança para um banco de dados de documentos quando você tem um histórico relacional. Especificamente, o Microsoft SQL Server em comparação com o Servidor Couchbase.
Em três partes, abordarei o assunto:
- Modelagem de dados
- Os dados em si (esta postagem do blog)
- Aplicativos que usam os dados
O objetivo é estabelecer algumas diretrizes gerais que podem ser aplicadas ao planejamento e ao design do seu aplicativo.
Se você quiser acompanhar, criei um aplicativo que demonstra o Couchbase e o SQL Server lado a lado. Obtenha o código-fonte no GitHube certifique-se de Faça o download de uma prévia para desenvolvedores do Couchbase Server.
Tipos de dados em JSON vs. SQL
O Couchbase (e muitos outros bancos de dados de documentos) usa objetos JSON para os dados. O JSON é um formato poderoso e legível por humanos para armazenar dados. Ao comparar com os tipos de dados em tabelas relacionais, há algumas semelhanças e algumas diferenças importantes.
Todos os dados JSON são compostos de 6 tipos: string, número, booleano, matriz, objeto e nulo. Há muitos tipos de tipos de dados disponíveis no SQL Server. Vamos começar com uma tabela que é um tipo de tradução "literal" e trabalhar a partir daí.
| SQL Server | JSON |
|---|---|
|
nvarchar, varchar, text |
string |
|
int, float, decimal, double |
número |
|
bit |
booleano |
|
nulo |
nulo |
|
Campos XML/hierarchyid |
matriz / objeto |
É importante entender como o JSON funciona. Listei algumas diferenças de alto nível entre os tipos de dados JSON e os tipos de dados do SQL Server. Supondo que você já entenda os tipos de dados SQL, talvez queira passar algum tempo aprendendo mais sobre JSON e tipos de dados JSON.
A string no SQL Server é geralmente definido por um comprimento. nvarchar(50) ou nvarchar(MAX) por exemplo. No JSON, você não precisa definir um comprimento. Basta usar uma string.
A número no SQL Server varia muito de acordo com a finalidade para a qual você o está usando. Os número em JSON é flexível, pois pode armazenar números inteiros, decimais ou ponto flutuante. Em circunstâncias específicas, como quando você precisa de uma precisão específica ou precisa armazenar números muito grandes, talvez seja melhor armazenar um número como uma cadeia de caracteres.
A booleano em JSON é verdadeiro/falso. No SQL Server, é mais ou menos equivalente: um bit que representa verdadeiro/falso.
No JSON, qualquer valor pode ser nulo. No SQL Server, você define isso em uma base de campo por campo. Se um campo no SQL Server não estiver definido como "nullable", ele será aplicado. Em um documento JSON, não há essa aplicação.
O JSON não tem data tipo de dados. Geralmente, as datas são armazenadas como carimbos de data/hora do UNIX, mas você também pode usar representações de cadeia de caracteres ou outros formatos para datas. A linguagem de consulta N1QL tem uma variedade de funções de data disponíveisPortanto, se você quiser usar o N1QL em datas, poderá usar essas funções para planejar o armazenamento de datas adequadamente.
No SQL Server, há um geografia tipo de dados. No Couchbase, o formato GeoJSON é compatível.
Existem alguns outros tipos de dados especializados no SQL Server, incluindo hierarchyid e xml. Normalmente, eles seriam desenrolados em objetos JSON e/ou referenciados por chave (conforme explorado em Parte 1 desta série do blog sobre modelagem de dados). Você ainda pode armazenar XML/JSON em uma string, se quiser, mas, se fizer isso, não poderá usar todo o poder do N1QL nesses campos.
Migração e tradução de dados
Dependendo da sua organização e da sua equipe, talvez seja necessário trazer pessoas de várias funções para garantir uma migração bem-sucedida. Se você tiver um DBA, ele terá de saber como executar e gerenciar o Couchbase tão bem quanto o SQL Server. Se você for DevOps ou tiver uma equipe de DevOps, é importante envolvê-la desde o início, para que ela saiba o que você está fazendo e possa ajudá-lo a coordenar seus esforços. Mudança para um banco de dados de documentos não significa que você não precisa mais do envolvimento de DBAs, Ops ou DevOps. Essas funções também devem ser envolvidas ao fazer a modelagem de dados, se possível, para que possam fornecer informações e entender o que está acontecendo.
Depois de projetar seu modelo com o Parte 1 sobre modelagem de dadosVocê pode começar a mover os dados para o Couchbase.
Para uma migração ingênua (1 linha para 1 documento), você pode escrever um programa muito simples para percorrer as tabelas, colunas e valores de um banco de dados relacional e gerar os documentos correspondentes. Uma ferramenta como Bonitão trataria todas as traduções de tipos de dados no C# e as alimentaria no SDK do Couchbase .NET.
No entanto, dados totalmente planos são relativamente incomuns, portanto, para modelos mais complexos, você provavelmente precisará escrever código para migrar do modelo relacional antigo para o novo modelo de documento.
Aqui estão algumas coisas que você deve ter em mente ao escrever código de migração (de qualquer tipo, mas especialmente de relacional para não relacional):
- Dê a si mesmo bastante tempo para planejar. Durante a migração, você pode descobrir que precisa repensar seu modelo. Você precisará testar e fazer ajustes, e é melhor ter mais tempo do que cometer erros na pressa. A migração de dados é um ciclo iterativo: migrar uma tabela, ver se funciona, ajustar e continuar iterando. Talvez você tenha que passar por esse ciclo várias vezes.
- Teste sua migração usando dados reais. Os dados podem ser cheios de surpresas. Você pode pensar que o campo NVARCHAR só contém representações de string de números, mas talvez haja algumas linhas anormais que contenham palavras. Use uma cópia dos dados reais para testar e verificar sua migração.
- Esteja preparado para executar a migração várias vezes. Tenha um plano para limpar uma migração com falha e começar de novo. Isso pode ser um simples
DELETE FROM bucketno N1QL, ou pode ser uma série de limpezas mais planejadas e direcionadas. Se você planejar desde o início, isso será mais fácil. Automatize sua migração para que isso seja menos doloroso. - ETL ou ELT? Extract-Transform-Load ou Extract-Load-Transform. Quando você vai fazer uma transformação? Ao colocar dados no Couchbase, a flexibilidade do JSON permite que você transfira no local após carregando se você quiser.
Um exemplo de migração ETL
Escrevi um aplicativo de console de migração muito simples usando C#, Entity Framework e o Couchbase .NET SDK. Ele migra o carrinho de compras e os exemplos de mídia social da postagem anterior do blog. O aplicativo completo O código-fonte está disponível no GitHub.
Este aplicativo fará a transformação, portanto, trata-se de uma abordagem ETL. Essa abordagem usa o Entity Framework para mapear tabelas relacionais para classes C#, que são então inseridas em documentos. O modelo de dados do Couchbase pode ser melhor representado por classes C# do que por tabelas relacionais (conforme demonstrado na postagem anterior do blog), portanto, essa abordagem tem menos atrito.
Vou usar o C# para escrever um programa de migração, mas o que importa é a automação, não a ferramenta específica. Esse será um código essencialmente "descartável" após a conclusão da migração. Minha abordagem C# não faz nenhum tipo de lote e provavelmente não é adequada para quantidades extremamente grandes de dados, portanto, pode ser uma boa ideia usar uma ferramenta como Talend e/ou uma abordagem ELT para dados de grande escala/empresariais.
Eu criei um ShoppingCartMigrator e uma classe SocialMediaMigrator aula. Neste post, abordarei apenas o carrinho de compras. Passo a ele um arquivo Couchbase balde e o Entity Framework contexto que usei na última postagem do blog. (Em vez disso, você poderia passar um arquivo NHibernate sessão ou um simples DbConnection aqui, dependendo de sua preferência).
|
1 2 3 4 5 6 7 8 9 10 11 |
público classe ShoppingCartMigrator { somente leitura IBucket _bucket; somente leitura SqlToCbContext _contexto; público ShoppingCartMigrator(IBucket balde, SqlToCbContext contexto) { _bucket = balde; _contexto = contexto; } } |
Com esses objetos no lugar, criei um Ir método para realizar a migração, e um Limpeza para excluir quaisquer documentos criados na migração, caso eu decida fazê-lo.
Para o Ir deixo que o Entity Framework faça o trabalho pesado das junções e faça um loop em cada carrinho de compras.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
público bool Ir() { var carrinhos = _contexto.Carrinhos de compras .Incluir(x => x.Itens) .ToList(); antes de (var carrinho em carrinhos) { var cartDocument = novo Documento<dinâmico> { Id = carrinho.Id.ToString(), Conteúdo = MapCart(carrinho) }; var resultado = _bucket.Inserir(cartDocument); se (!resultado.Sucesso) { Console.WriteLine($"Ocorreu um erro ao migrar o carrinho de compras {cart.Id}"); retorno falso; } Console.WriteLine($"Carrinho de compras migrado com sucesso {cart.Id}"); } retorno verdadeiro; } |
Optei por abortar a migração se houver um erro sequer. Talvez você não queira fazer isso. Em vez disso, talvez queira fazer o log em um arquivo e abordar todos os registros que causam erros de uma só vez.
Para a limpeza, optei por excluir todos os documentos que têm um tipo de "ShoppingCart".
|
1 2 3 4 5 6 7 8 9 10 |
público vazio Limpeza() { Console.WriteLine("Excluir todos os carrinhos de compras..."); var resultado = _bucket.Consulta<dinâmico>("DELETE FROM `sqltocb` WHERE type='ShoppingCart';"); se (!resultado.Sucesso) { Console.WriteLine($"{result.Exception?.Message}"); Console.WriteLine($"{result.Message}"); } } |
Essa é a abordagem mais simples. Uma abordagem mais complexa poderia envolver a colocação de um campo de marcação de "impressão digital" temporário em determinados documentos e, em seguida, a exclusão de documentos com uma determinada impressão digital na limpeza. (Por exemplo. DELETE FROM sqltocb WHERE fingerprint = '999cfbc3-186e-4219-ab5d-18ad130a9dc6'). Ou vice-versa: faça a impressão digital dos dados problemáticos para análise posterior e exclua o restante. Apenas certifique-se de limpar esses campos temporários quando a migração for concluída com êxito.
Ao tentar fazer isso, talvez queira executar o aplicativo de console duas vezes, apenas para ver a limpeza em ação. A segunda tentativa resultará em erros, pois ele estará tentando criar documentos com chaves duplicadas.
E quanto aos outros recursos do SQL Server?
Nem tudo no SQL Server tem uma contrapartida direta no Couchbase. Em alguns casos, nunca haverá uma contrapartida. Em alguns casos, haverá um equivalente aproximado. Alguns recursos chegarão no futuro, pois o Couchbase está em desenvolvimento acelerado, ativo e de código aberto, e novos recursos estão sendo adicionados quando apropriado.
Além disso, lembre-se de que os bancos de dados de documentos e os bancos de dados NoSQL geralmente forçam a lógica comercial para fora do banco de dados em uma extensão maior do que os bancos de dados relacionais. Por melhor que fosse se o Couchbase Server tivesse todos os recursos disponíveis, sempre há compensações. Algumas são de natureza técnica, outras são decisões de design do produto. É possível fazer concessões para adicionar recursos de estilo relacional, mas, em algum momento dessa jornada, o Couchbase deixa de ser um banco de dados rápido e escalável e começa a ser "apenas mais um" banco de dados relacional. Certamente há muita convergência nos bancos de dados relacionais e não relacionais, e muitas mudanças acontecem todos os anos.
Com isso em mente, fique atento à última postagem do blog desta série. Ela abordará as alterações na codificação de aplicativos que vêm com o uso do Couchbase, incluindo:
- SQL/N1QL
- Procedimentos armazenados
- Níveis de serviço
- Gatilhos
- Visualizações
- Serialização
- Segurança
- Concorrência
- Número automático
- OR/Ms e ODMs
- Transações
Resumo
Esta postagem do blog comparou e contrastou os recursos de dados disponíveis no Couchbase Server com o SQL Server. Se você estiver usando o SQL Server e estiver pensando em adicionar um banco de dados de documentos ao seu projeto ou iniciar um novo projeto, estou aqui para ajudar.
Confira o Portal do desenvolvedor do Couchbase para obter mais detalhes.
Entre em contato comigo em matthew.groves@couchbase.com, faça uma pergunta em os fóruns do Couchbaseou entre em contato comigo pelo Twitter @mgroves.
[...] Os dados em si [...]
[...] em 14 de fevereiro de 2017 enviado por /u/mgroves [link] [comentários] Deixe um [...]
[...] Migração de dados [...]
Sugiro que você dê uma olhada neste útil conector para sincronização em tempo real do SQL Server (e também do Oracle Database) com o Couchbase e vice-versa -> https://molo17.com/gluesync-connector-couchbase/