Moving from SQL Server to Couchbase Part 3: App Migration

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
Migração de dados
Aplicativos que usam os dados (esta postagem do blog)

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.

Migrar vs. Reescrever

Se você estiver criando um novo aplicativo da Web, o Couchbase Server é uma boa opção para usar como seu sistema de registro. A modelagem de dados flexível, o acesso rápido aos dados e a facilidade de dimensionamento fazem dele uma boa opção.

O Couchbase Server pode complementar o SQL Server em seu aplicativo da Web existente. Ele pode ser um armazenamento de sessão ou um armazenamento de cache. Você não precisa substituir seu RDMBS para se beneficiar do Couchbase Server. Você pode usá-lo como seu sistema de engajamento.

No entanto, se você estiver pensando em fazer de um banco de dados de documentos o seu "sistema de registro" para um aplicativo existente, precisará planejar o que fazer com esse aplicativo (supondo que você já tenha elaborado um plano de modelagem e migração de dados, conforme abordado nas partes anteriores desta série do blog). Na verdade, há duas opções:

Substitua sua camada de dados/serviço. Se você criou seu aplicativo de forma a desacoplá-lo da persistência subjacente, isso o beneficiará enormemente ao mudar do SQL Server para o Couchbase. Se você estiver usando um SOA, por exemplo, talvez não precise fazer muitas alterações no aplicativo Web.
Reconstrua seu aplicativo. Se você não tiver uma arquitetura desacoplada, provavelmente terá que se preocupar e reescrever/refatorar grandes partes do seu aplicativo. Esse pode ser um custo significativo que você terá de levar em conta ao decidir se deve ou não mudar para um banco de dados de documentos. Eu gostaria de poder dizer que seria mais fácil, que haveria uma poção mágica que você poderia usar. Mas lembre-se, mesmo que o custo de uma reconstrução seja muito alto, você ainda pode usar o Couchbase Server em
em conjunto com o SQL Server.

As peças da pilha que podem precisar ser reconstruídas ou substituídas incluem:

ADO.NET - Se estiver usando o ADO.NET simples ou um micro-OR/M como o Dapper, eles podem ser substituídos pelo SDK do Couchbase .NET.
OR/M - Estrutura de entidades, NHibernate, Linq2SQL, etc. Eles podem ser substituídos pelo Linq2Couchbase
Qualquer código que os utilize diretamente - Qualquer código que toque em ADO.NET, OR/Ms ou outro código do SQL Server precisará ser substituído para usar o Couchbase (e/ou reescrito para introduzir outra camada de abstração).

O restante desta postagem do blog será composto de dicas e diretrizes que se aplicam à reescrita, à refatoração ou ao início de um novo projeto.

O que será coberto

Os bancos de dados de documentos 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.

Nesta postagem do blog, abordaremos as alterações na codificação de aplicativos que vêm com o uso do Couchbase. Em um alto nível, veja o que será abordado nesta postagem do blog. À esquerda, um recurso do SQL Server; à direita, o equivalente mais próximo ao usar o Couchbase Server.

SQL Server	Servidor Couchbase
tSQL	N1QL
Procedimentos armazenados	Nível de serviço
Gatilhos	Nível de serviço
Visualizações	Visualizações Map/Reduce
Número automático	Balcão
OR/M (mapeador de objeto/relacional)	ODM (Modelo de dados de objeto)
ÁCIDO	ACID de documento único

SQL Server

Servidor Couchbase

tSQL

N1QL

Procedimentos armazenados

Nível de serviço

Gatilhos

Nível de serviço

Visualizações

Visualizações Map/Reduce

Número automático

Balcão

OR/M (mapeador de objeto/relacional)

ODM (Modelo de dados de objeto)

ÁCIDO

ACID de documento único

Além disso, também abordaremos estes tópicos importantes:

Serialização
Segurança
Concorrência
SSIS, SSRS, SSAS

Usando o N1QL

O N1QL (pronuncia-se "nickel") A linguagem de consulta SQL é um dos meus recursos favoritos do Couchbase Server. Você já está familiarizado com a linguagem de consulta SQL. Com o N1QL, você pode aplicar seus conhecimentos a um banco de dados de documentos.

Aqui estão alguns exemplos para mostrar o semelhanças entre o N1QL e o tSQL:

tSQL N1QL

tSQL	N1QL
DELETE FROM [tabela] WHERE val1 = 'foo'	DELETE FROM `balde` WHERE val1 = 'foo'
SELECT * FROM [tabela]	SELECT * from `balde`
SELECT t1.* , t2.* FROM [table1] t1 JOIN [table2] t2 ON t1.id = t2.id	SELECT b1.* , b2.* FROM `balde` b1 JOIN `balde` b2 ON KEYS b1.mykeys
INSERT INTO [table] (key, col1, col2) VALUES (1, 'val1′,'val2')	INSERT INTO `balde` (KEY, VALUE) VALUES ('1', {"col1″: "val1", "col2″: "val2"})
UPDATE [tabela] SET val1 = 'newvalue' WHERE val1 = 'foo'	ATUALIZAÇÃO `balde` SET val1 ='newvalue' WHERE val1 = 'foo'

DELETE FROM [tabela] WHERE val1 = 'foo'

DELETE FROM balde WHERE val1 = 'foo'

SELECT * FROM [tabela]

SELECT * from balde

SELECT t1.* , t2.* FROM [table1] t1 JOIN [table2] t2 ON t1.id = t2.id

SELECT b1.* , b2.* FROM balde b1 JOIN balde b2 ON KEYS b1.mykeys

INSERT INTO [table] (key, col1, col2) VALUES (1, 'val1′,'val2')

INSERT INTO balde (KEY, VALUE) VALUES ('1', {"col1″: "val1", "col2″: "val2"})

UPDATE [tabela] SET val1 = 'newvalue' WHERE val1 = 'foo'

ATUALIZAÇÃO balde SET val1 ='newvalue' WHERE val1 = 'foo'

Agradecimentos a N1QLSe você não tiver um banco de dados de documentos, migrar suas consultas SQL deve ser menos difícil do que em outros bancos de dados de documentos. Seu modelo de dados será diferente, e nem todas as funções do tSQL estão (ainda) disponíveis no N1QL. Mas, na maior parte do tempo, seu conhecimento atual de escrita em tSQL pode ser aplicado.

Voltando ao carrinho de compras, aqui está um exemplo de uma consulta tSQL simples que obteria informações sobre o carrinho de compras de um determinado usuário:

SELECT c.Id, c.DateCreated, c.[User], i.Price, i.Quantity
FROM ShoppingCart c
INNER JOIN ShoppingCartItems i ON i.ShoppingCartID = c.Id
WHERE c.[User] = 'mschuster'

SELECIONAR c.Id, c.DateCreated, c.[Usuário], i.Preço, i.Quantidade

DE ShoppingCart c

INNER JUNTAR Itens do carrinho de compras i ON i.ID do carrinho de compras = c.Id

ONDE c.[Usuário] = 'mschuster'

No Couchbase, um carrinho de compras poderia ser modelado como um único documento, portanto, uma consulta aproximadamente equivalente seria:

SELECT META(c).id, c.dateCreated, c.items, c.`user`
FROM `sqltocb` c
WHERE c.type = 'ShoppingCart'
AND c.`user` = 'mschuster';

SELECIONAR META(c).id, c.dateCreated, c.itens, c.`usuário`

DE `sqltocb` c

ONDE c.tipo = 'ShoppingCart'

E c.`usuário` = 'mschuster';

Observe que, embora o N1QL tenha JUNTAR funcionalidade, não JUNTAR é necessário nessa consulta de carrinho de compras. Todos os dados do carrinho de compras estão em um único documento, em vez de estarem espalhados em várias tabelas e linhas.

Os resultados não são exatamente o mesmo: a consulta N1QL retorna um resultado mais hierárquico. Mas a consulta poderia ser modificado com um INÚTIL para achatar os resultados, se necessário. INÚTIL é um união intra-documentoque é um recurso necessário ao escrever SQL para JSON.

Em muitos bancos de dados de documentos que não sejam o Couchbase, você provavelmente teria que aprender uma API para criar consultas e não poderia aplicar sua experiência com o tSQL para ajudar a aumentar a produtividade. Não estou dizendo que a tradução será sempre um passeio no parque, mas será relativamente fácil em comparação com as alternativas. Se você estiver iniciando um novo então você ficará feliz em saber que suas habilidades de escrita em SQL continuarão a ser bem utilizadas!

Ao escrever o C# para interagir com o N1QL, é importante conhecer alguns conceitos-chave.

Consistência de varredura. Ao executar uma consulta N1QL, há várias opções de consistência de varredura. A consistência da varredura define como a consulta N1QL deve se comportar em relação à indexação. O comportamento padrão é "Not Bounded", que oferece o melhor desempenho. No outro extremo do espectro está "RequestPlus", que oferece a melhor consistência. Há também o "AtPlus", que é um bom meio-termo, mas exige um pouco mais de trabalho. I escreveu no blog sobre consistência de varredura em junho, e vale a pena revisá-lo antes de começar a escrever N1QL em .NET.

Parametrização. Se você estiver criando consultas N1QL, é importante usar parametrização para evitar injeção de SQL. Há duas opções no N1QL: parâmetros posicionais (numerados) e parâmetros nomeados.

Aqui está um exemplo de consistência de varredura e parametrização usadas no C#:

var query = QueryRequest.Create(n1ql);
query.ScanConsistency(ScanConsistency.RequestPlus);
query.AddNamedParameter("userId", id);
var result = _bucket.Query<Update>(query);

var consulta = Solicitação de consulta.Criar(n1ql);

consulta.Consistência de varredura(Consistência de varredura.RequestPlus);

consulta.AddNamedParameter("userId", id);

var resultado = _bucket.Consulta<Atualização>(consulta);

Não vou me aprofundar no Linguagem de consulta N1QL mais do que isso, porque esse é um tópico muito profundo. Mas você pode confira os conceitos básicos do N1QL e Comece a usar o tutorial interativo do N1QL.

Procedimentos armazenados em SQL

Não há equivalente aos procedimentos armazenados (sprocs) no Couchbase. Se você ainda não tiver uma camada de serviço e estiver usando sprocs para compartilhar alguma lógica entre domínios, recomendo que crie uma camada de serviço e mova a lógica para lá.

Na verdade, eu não tinha certeza se os sprocs pertenciam à parte 2 ou à parte 3 desta série do blog. Camadas típicas em um aplicativo corporativo:

Camada da Web (UI - Angular/React/Tradicional ASP.NET MVC)
Camada de serviço (ASP.NET WebApi)
Banco de dados

Os sprocs vivem no banco de dados, mas contêm lógica. A camada de serviço também contém lógica comercial. Então, eles contam como dados ou funcionalidade?

Fiz uma pesquisa de opinião no Twitter para decidir.

Twitter straw poll on Stored Procedures

Mas minha recomendação é que, se você já tiver uma camada de serviço, mova a lógica do sproc para ela. Se você não tiver uma camada de serviço, crie uma. Isso ficará entre o banco de dados e a interface do usuário.

No código-fonte desta série, criei um único procedimento armazenado.

CREATE PROCEDURE SP_SEARCH_SHOPPING_CART_BY_NAME
	@searchString NVARCHAR(50)
AS
BEGIN
	SELECT c.Id, c.[User], c.DateCreated
	FROM ShoppingCart c
	WHERE c.[User] LIKE '%' + @searchString + '%'
END
GO

CRIAR PROCEDIMENTO SP_SEARCH_SHOPPING_CART_BY_NOME

@searchString NVARCHAR(50)

INICIAR

SELECIONAR c.Id, c.[Usuário], c.DateCreated

DE ShoppingCart c

ONDE c.[Usuário] GOSTO '%' + @searchString + '%'

FIM

Esse sproc pode ser executado a partir do Entity Framework da seguinte forma:

public List<ShoppingCart> SearchForCartsByUserName(string searchString)
{
    var cmd = _context.Database.Connection.CreateCommand();
    cmd.CommandText = "SP_SEARCH_SHOPPING_CART_BY_NAME @searchString";
    cmd.Parameters.Add(new SqlParameter("@searchString", searchString));
    _context.Database.Connection.Open();
    var reader = cmd.ExecuteReader();

    var carts = ((IObjectContextAdapter) _context)
        .ObjectContext
        .Translate<ShoppingCart>(reader, "ShoppingCarts", MergeOption.AppendOnly);

    var result = carts.ToList();
    _context.Database.Connection.Close();
    return result;
}

público Lista<ShoppingCart> SearchForCartsByUserName(string searchString)

{

var cmd = _contexto.Banco de dados.Conexão.CreateCommand();

cmd.CommandText = "SP_SEARCH_SHOPPING_CART_BY_NAME @searchString";

cmd.Parâmetros.Adicionar(novo SqlParameter("@searchString", searchString));

_contexto.Banco de dados.Conexão.Aberto();

var leitor = cmd.ExecuteReader();

var carrinhos = ((IObjectContextAdapter) _contexto)

.Contexto de objeto

.Traduzir<ShoppingCart>(leitor, "ShoppingCarts", MergeOption.AppendOnly);

var resultado = carrinhos.ToList();

_contexto.Banco de dados.Conexão.Fechar();

retorno resultado;

}

A propósito, esse código sproc do Entity Framework é feio. Talvez eu tenha feito isso errado? Não estou tentando difamar o EF, mas, em geral, não usei muito OR/Ms e sprocs juntos em minha carreira. Certamente, um trecho de código ADO.NET ou Dapper seria mais curto e mais limpo.

Esse é um sproc muito simples, mas introduz uma funcionalidade básica de pesquisa. Os benefícios desse sproc:

Reutilização: O mesmo sproc pode ser reutilizado entre diferentes aplicativos
Abstração: A implementação do sproc pode ser alterada ou aprimorada. Nesse caso, um GOSTO poderia ser trocado por uma pesquisa de texto completo mais robusta.

Qualquer abordagem adotada com a introdução de uma camada de serviço deve proporcionar os mesmos benefícios. Criei um endpoint ASP.NET WebApi para substituir o sproc.

[HttpGet]
[Route("api/searchByName/{searchString}")]
public IHttpActionResult SearchByName(string searchString)
{
    var n1ql = @"SELECT META(c).id, c.`user`
        FROM `sqltocb` c
        WHERE c.type = 'ShoppingCart'
        AND c.`user` LIKE $searchString";
    var query = QueryRequest.Create(n1ql);
    query.AddNamedParameter("searchString", "%" + searchString + "%");
    query.ScanConsistency(ScanConsistency.RequestPlus);
    var results = _bucket.Query<ShoppingCart>(query).Rows;

    return Json(results);
}

[HttpGet]

[Rota("api/searchByName/{searchString}")]

público IHttpActionResult SearchByName(string searchString)

{

var n1ql = @"SELECT META(c).id, c.`user`

FROM `sqltocb` c

WHERE c.type = 'ShoppingCart'

E c.`user` LIKE $searchString";

var consulta = Solicitação de consulta.Criar(n1ql);

consulta.AddNamedParameter("searchString", "%" + searchString + "%");

consulta.Consistência de varredura(Consistência de varredura.RequestPlus);

var resultados = _bucket.Consulta<ShoppingCart>(consulta).Fileiras;

retorno Json(resultados);

}

Observação: por uma questão de simplicidade no código de exemplo, esse endpoint realmente reside no mesmo projeto da Web, mas, na produção, ele deve ser movido para seu próprio projeto e implantado separadamente.

Esse endpoint contém uma consulta N1QL de natureza semelhante ao sproc acima. Vamos ver se ela tem os mesmos benefícios:

Reutilizar? Sim. Esse endpoint pode ser implementado em seu próprio servidor e ser reutilizado de outros aplicativos.
Abstração? Mais uma vez, sim. A implementação usa o ingênuo GOSTO que poderíamos melhorar mudando-a para usar Recursos de pesquisa de texto completo do Couchbase sem alterar a API.

Em vez de chamar um sproc por meio do Entity Framework, esse ponto de extremidade seria chamado via HTTP. Aqui está um exemplo que usa a biblioteca RestSharp:

public List<ShoppingCart> SearchForCartsByUserName(string searchString)
{
    // typically there would be authentication/authorization with a REST call like this
    var client = new RestClient(_baseUrl);
    var request = new RestRequest("/api/searchByName/" + searchString);
    request.AddHeader("Accept", "application/json");
    var response = client.Execute<List<ShoppingCart>>(request);
    return response.Data;
}

público Lista<ShoppingCart> SearchForCartsByUserName(string searchString)

{

// normalmente, haveria autenticação/autorização com uma chamada REST como esta

var cliente = novo Cliente Rest(_baseUrl);

var solicitação = novo RestRequest("/api/searchByName/" + searchString);

solicitação.AddHeader("Aceitar", "application/json");

var resposta = cliente.Executar<Lista<ShoppingCart>>(solicitação);

retorno resposta.Dados;

}

Se estiver criando um novo projeto, recomendo que crie uma camada de serviço com a expectativa de que ela seja usada em toda a empresa. Isso permite que você tenha o mesmo "código compartilhado" que os sprocs normalmente forneceriam sem colocar esse código no banco de dados.

Isso também se aplica ao SQL Server funções, tipos definidos pelo usuário, regras, objetos CLR definidos pelo usuário.

Observação: o exemplo de sproc acima é um SELECIONAR apenas para manter o exemplo simples. Nesse caso, você poderia criar uma visualização do MapReduce (que será discutida abaixo). No entanto, uma visualização do MapReduce não pode alterar documentos, portanto, uma abordagem de camada de serviço é uma solução geral melhor para substituir os sprocs.

Acionadores SQL

Se os sprocs ainda não foram controversos o suficiente, basta mencionar os acionadores em uma conversa. Assim como acontece com os procedimentos armazenados, geralmente recomendo que você mova a lógica do acionador para a camada de serviço, longe do banco de dados. Se o seu projeto de software depende de muitos acionadores, ou de acionadores complexos, ou de muitos acionadores complexos, talvez seja melhor esperar por outro projeto para tentar usar o Couchbase Server.

Dito isso, há algumas coisas de ponta que estão sendo trabalhadas e que podem ser mais ou menos equivalentes aos acionadores. Se estiver interessado nisso, entre em contato comigo e também fique atento a Blog do Couchbase para obter as informações mais recentes.

Visualizações

No SQL Server, as visualizações são uma forma de armazenar consultas complexas no servidor, além de proporcionar alguns benefícios de desempenho. No Couchbase, as visualizações de mapa/reprodução têm fornecido funcionalidade semelhante há algum tempo. Na maioria das vezes, a funcionalidade fornecida pelas visualizações pode ser fornecida de forma mais expressiva com o N1QL. No entanto, as visualizações não estão desaparecendo e, às vezes, há benefícios em usá-las.

As exibições de mapa/redução podem ser definidas e armazenadas no cluster do Couchbase. Para criá-las, você define uma função "map" (com JavaScript) e, opcionalmente, uma função "reduce" (também em JavaScript).

Na interface do usuário do Console do Couchbase, vá para Índices → Visualizações → Criar visualização. Crie um documento de design e crie uma visualização dentro desse documento de design.

Figura 1. Captura de tela do editor de visualização Map/Reduce no Console do Couchbase mais recente

No centro está o código Map/Reduce no qual você está trabalhando. Um documento de amostra e seus metadados também são mostrados para ajudá-lo visualmente e, na parte inferior, você tem algumas opções para executar sua visualização.

Para obter detalhes completos sobre como as visualizações funcionam, consulte o Documentação das visualizações do MapReduce.

Como um exemplo rápido, quero criar uma exibição que liste apenas as pessoas com idade superior a 21 anos.

function (doc, meta) {
  if(doc.age > 21) {
  	emit(meta.id, doc.name);
  }
}

função (doc, meta) {

se(doc.idade > 21) {

emitir(meta.id, doc.nome);

}

Essa exibição emitiria a chave do documento e o valor do campo "name". Se meu compartimento contivesse os seguintes documentos:

foo1	{"age":17,"name":"Carmella Albert"}
foo2	{"age":25,"name":"Lara Salinas"}
foo3	{"age":35,"name":"Teresa Johns"}

foo1 {"idade":17,"name" (nome):"Carmella Albert"}

foo2 {"idade":25,"name" (nome):"Lara Salinas"}

foo3 {"idade":35,"name" (nome):"Teresa Johns"}

Em seguida, os resultados da exibição seriam semelhantes:

Chave	Valor
"foo2"	"Lara Salinas"
"foo3"	"Teresa Johns"

Chave

Valor

"foo2"

"Lara Salinas"

"foo3"

"Teresa Johns"

Os resultados dessas exibições são atualizados automaticamente em um intervalo e também são atualizados de forma incremental à medida que os documentos sofrem mutação. Isso significa que, por padrão, os resultados das exibições são eventualmente consistente com os documentos reais. Como desenvolvedor, você pode especificar o nível de consistência (ou estanqueidade) que você deseja. Isso terá um impacto no desempenho.

As visualizações de mapa/reprodução podem ser muito úteis quando você tem uma lógica muito complexa que é mais fácil de escrever em JavaScript do que em N1QL. Também pode haver benefícios de desempenho quando se está trabalhando com um sistema que exige muita gravação.

As visualizações podem ser acessadas a partir do .NET usando Consulta.

var query = new ViewQuery().From("viewdesigndocument", "viewname").Limit(10);
var people = bucket.Query<dynamic>(query);
foreach (var person in people.Rows)
    Console.WriteLine(landmark.Key);

var consulta = novo Consulta().De("viewdesigndocument", "viewwname").Limite(10);

var pessoas = balde.Consulta<dinâmico>(consulta);

antes de (var pessoa em pessoas.Fileiras)

Console.WriteLine(marco histórico.Chave);

Como alternativa, você pode criar consultas N1QL em vez de usar visualizações. Em muitos casos, o N1QL será mais fácil de escrever, e a diferença de desempenho será insignificante. Ao contrário das visualizações, as consultas N1QL residiriam na camada de serviço. Atualmente, não há como armazenar uma "visualização N1QL" no cluster do Couchbase Server.

Serialização/desserialização

Se você estiver usando N1QL, visualizações ou operações de chave/valor, é importante considerar como o JSON é serializado e desserializado.

O SDK do .NET usa Newtonson JSON.NET. Se você estiver familiarizado com essa ferramenta (e quem entre os desenvolvedores de .NET não está), lembre-se de que você pode usar os mesmos atributos (como JsonProperty, JsonConverteretc.). Em alguns casos extremos, pode ser útil criar seu próprio serializador personalizado, o que é possível com o Couchbase .NET SDK. Dê uma olhada no documentação sobre serialização e documentos não JSON para obter mais informações.

Segurança

O Couchbase tem controle de acesso baseado em função (RBAC) para administradores.

O Couchbase pode se integrar ao LDAP para gerenciar os administradores do Couchbase e atribuir funções aos usuários. O Couchbase também pode criar internamente usuários somente leitura.

Há algumas mudanças e melhorias mais robustas chegando ao sistema RBAC do Couchbase, portanto, fique atento. Na verdade, eu recomendaria que você começasse a verificando as compilações mensais para desenvolvedoresEspero ver alguns aprimoramentos e recursos interessantes nessa área em breve!

Concorrência

A simultaneidade é algo com que você precisa lidar com frequência, especialmente em um aplicativo da Web. Vários usuários podem estar realizando ações que resultam na alteração do mesmo documento ao mesmo tempo.

O SQL Server usa bloqueio pessimista por padrão. Isso significa que o SQL Server espera que as linhas estejam em contenção e, portanto, age de forma defensiva. Esse é um padrão sensato para bancos de dados relacionais porque os dados desnormalizados estão espalhados por várias tabelas e várias linhas. O SQL Server tem a capacidade de usar bloqueio otimista também, por meio de uma variedade de níveis de transação.

O Couchbase também oferece duas opções para lidar com a concorrência: otimista e pessimista.

Otimista. Isso é chamado de "otimista" porque funciona melhor quando é improvável que um documento esteja em contenção com muita frequência. Você está fazendo uma suposição otimista. No Couchbase, isso é feito com CAS (Compare and Swap). Quando você recupera um documento, ele vem com metadados, incluindo um valor CAS (que é apenas um número). Quando você for atualizar esse documento, poderá fornecer o valor CAS. Se os valores corresponderem, então seu otimismo valeu a pena e as alterações serão salvas. Se não corresponderem, a operação falhará e você terá de lidar com isso (uma mesclagem, uma mensagem de erro etc.). Se você não fornecer um valor CAS, as alterações serão salvas de qualquer maneira.

Pessimista. Isso é chamado de "pessimista" porque funciona melhor quando você sabe que um documento sofrerá muitas mutações. Você está fazendo uma suposição pessimista e está bloqueando o documento à força. Se você usar GetAndLock no .NET SDK, o documento será bloqueado, o que significa que não poderá ser modificado. Os documentos são bloqueados por um período máximo de 15 segundos. Você pode definir um valor menor. Também é possível desbloquear explicitamente um documento, mas é preciso controlar o valor CAS para fazer isso.

Para obter mais detalhes, consulte a documentação sobre Mutações simultâneas de documentos.

Número automático

Atualmente, o Couchbase Server não oferece nenhum tipo de geração automática de chaves ou numeração sequencial de chaves.

No entanto, você pode usar o Balcão recurso para fazer algo semelhante. A ideia é que um documento seja reservado como um documento contador especial. Esse documento pode ser incrementado como uma operação atômica, e o número pode ser usado como uma chave parcial ou total do novo documento que está sendo criado.

Ratnopam Chakrabarti, um desenvolvedor da Ericsson, escreveu recentemente um postagem de blog de convidado sobre como criar chaves numeradas sequencialmente com o Couchbase Server. Seu exemplo está em Java, mas é fácil de seguir, portanto, não repetirei seu exemplo aqui.

OR/Ms e ODMs

Se estiver usando o SQL Server, talvez esteja familiarizado com os mapeadores objeto-relacionais (OR/Ms). Entity Framework, NHibernate, Linq2SQL e muitos outros são OR/Ms. Os OR/Ms tentam preencher a lacuna entre os dados estruturados em C# e os dados normalizados em bancos de dados relacionais. Normalmente, eles também oferecem outros recursos, como provedores Linq, unidade de trabalho etc. Acredito que os OR/Ms seguem a regra 80/20. Eles podem ser muito úteis 80% do tempo, e uma dor de cabeça nos outros 20%.

Para bancos de dados de documentos, há uma incompatibilidade de impedância muito menor, pois os objetos C# podem ser serializados/desserializados para JSON e não precisam ser divididos em um conjunto normalizado de tabelas.

No entanto, as outras funcionalidades que os OR/Ms oferecem ainda podem ser úteis em bancos de dados de documentos. A ferramenta equivalente é chamada de ODM (Object Document Model). Essas ferramentas ajudam você a definir um conjunto de classes para mapear para documentos. Ottoman e Linq2Couchbase são ODMs populares para o Couchbase, para Node e .NET, respectivamente.

Linq2Couchbase tem um provedor Linq. Não é um projeto oficialmente suportado (ainda), mas é um dos provedores Linq mais completos que já usei e é usado em produção pelos clientes do Couchbase.

Abaixo está um exemplo da documentação do Linq2Couchbase que deve parecer familiar para os usuários do Entity Framework e do NHibernate.Linq:

var context = new BucketContext(ClusterHelper.GetBucket("travel-sample"));
var query = (from a in context.Query<AirLine>()
             where a.Country == "United Kingdom"
             select a).
             Take(10);

var contexto = novo BucketContext(Ajudante de cluster.GetBucket("amostra de viagem"));

var consulta = (de a em contexto.Consulta<AirLine>()

onde a.País == "Reino Unido"

selecionar a).

Pegue(10);

Também usei o Linq2Couchbase no código de amostra para esta série do blog. Aqui está um exemplo para carrinhos de compras:

var query = from c in _context.Query<ShoppingCart>()
    where c.Type == "ShoppingCart"  // could use DocumentFilter attribute instead of this Where
    orderby c.DateCreated descending
    select new {Cart = c, Id = N1QlFunctions.Meta(c).Id};
var results = query.ScanConsistency(ScanConsistency.RequestPlus)
    .Take(10)
    .ToList();

var consulta = de c em _contexto.Consulta<ShoppingCart>()

onde c.Tipo == "ShoppingCart" // poderia usar o atributo DocumentFilter em vez desse Where

por ordem c.DateCreated descendente

selecionar novo {Carrinho = c, Id = N1QlFunções.Meta(c).Id};

var resultados = consulta.Consistência de varredura(Consistência de varredura.RequestPlus)

.Pegue(10)

.ToList();

Além de ser um excelente provedor de Linq, o Linq2Couchbase também tem um recurso experimental de controle de alterações. Vale a pena dar uma olhada. Brant Burnett é um dos principais colaboradores do projeto e também é um Especialista em Couchbase. Ele apresentou uma sessão no Couchbase Connect 2016 chamada LINQing para dados: Facilitando a transição do SQL.

[youtube https://www.youtube.com/watch?v=X__mC2FArp4&w=560&h=315]

Transações

Já abordei o bloqueio pessimista e otimista para transações em um único documento. Por causa disso, podemos dizer que o Couchbase suporta transações ACID em um nível por documento. No momento, o Couchbase não oferece suporte a transações ACID entre vários documentos.

Pensando no Primeira postagem no blog sobre modelagem de dadosEm comparação com um modelo relacional, a necessidade de transações com vários documentos é geralmente reduzida ou eliminada. Um conceito (como carrinho de compras) pode exigir linhas em várias tabelas em um modelo relacional, mas um único modelo de documento no Couchbase.

Se você estiver seguindo um modelo referencial, como no exemplo de mídia social do primeira postagem no blogSe você não tiver um modelo de dados de dados, poderá se preocupar com a falta de transações. Isso destaca a importância de pensar em seus casos de uso ao criar o modelo de dados. Se as transações forem vitais para o seu caso de uso, o modelo de dados poderá ser estruturado para acomodá-las. Teremos prazer em ajudá-lo com isso, basta perguntar!

O suporte a transações de vários documentos poderá ser oferecido no futuro se um número suficiente de desenvolvedores e clientes do Couchbase solicitar ou precisar dele. Portanto, se você fizer o exercício de projetar um modelo de dados de banco de dados de documentos e as transações forem ainda uma parte vital do seu projeto, então o Couchbase pode não ser o melhor "sistema de registro" para pelo menos parte do seu projeto. O Couchbase ainda pode ser o melhor "sistema de engajamento", capaz de ajudar com dimensionamento, armazenamento em cache, desempenho e flexibilidade quando necessário.

Como observação adicional, talvez valha a pena dar uma olhada no NDescreva o projetopois inclui um SDK que funciona sobre o SDK do Couchbase e fornece um sistema de transações. (Observe que essa não é uma ferramenta com suporte oficial).

SSIS, SSAS, SSRS

Nem todo mundo usa o SQL Server Integration Services (SSIS), o SQL Server Analysis Services (SSAS) e o SQL Server Reporting Services (SSRS), mas esses são recursos poderosos que o SQL Server tem para integração, geração de relatórios e análise.

Não posso lhe dar uma resposta genérica "use X em vez de Y" para esses casos, pois isso depende muito do seu caso de uso. Posso indicar algumas das ferramentas disponíveis para o Couchbase que giram em torno de processamento de dados, transformação de dados, geração de relatórios e análise.

Kafka é uma ferramenta de streaming de dados de código aberto. Algumas das Casos de uso populares para o Kafka incluem mensagens, rastreamento de atividades do site, métricas e muito mais.
Faísca é um mecanismo de processamento de dados, destinado ao processamento de dados em grande escala e ETL.
Hadoop é uma estrutura de big data para armazenamento e processamento distribuídos.

O Couchbase tem conectores que suportam cada uma dessas três ferramentas populares.

Finalmente, Análise do Couchbase está atualmente em visualização para desenvolvedores. Ele foi concebido como um mecanismo de gerenciamento de dados que é executado paralelamente ao Couchbase Server. É uma prévia para desenvolvedores e ainda não é recomendado para uso em produção, mas você pode Faça o download do Couchbase Analytics e das extensões do Kafka, Spark e Hadoop (clique na guia Extensões) e experimente-os.

Resumo

Abordamos a modelagem de dados, a migração de dados e a migração de aplicativos pelas lentes do SQL Server. Esse é um bom ponto de partida para seu próximo projeto e lhe dará algo em que pensar se estiver pensando em migrar.

O Portal do desenvolvedor do Couchbase contém mais detalhes e informações sobre todos os aspectos do Couchbase Server.

Gostaria de saber o que o Couchbase pode fazer para facilitar a sua transição, quer você esteja migrando ou começando do zero. Perdi alguma coisa? Você tem alguma ferramenta ou sistema que recomenda? Tem alguma dúvida? Dê uma olhada na seção Fóruns do CouchbaseEnvie-me um e-mail para matthew.groves@couchbase.com ou me encontre em Twitter @mgroves.

Matthew Groves

Compartilhe este artigo

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Mudança do SQL Server para o Couchbase Parte 3: Migração de aplicativos

Mudança do SQL Server para o Couchbase Parte 3: Migração de aplicativos

Migrar vs. Reescrever

O que será coberto

Usando o N1QL

Procedimentos armazenados em SQL

Acionadores SQL

Visualizações

Serialização/desserialização

Segurança

Concorrência

Número automático

OR/Ms e ODMs

Transações

SSIS, SSAS, SSRS

Resumo

Receba atualizações do blog do Couchbase em sua caixa de entrada

Autor

Postado por Matthew Groves

2 Comentários

Deixe um comentário Cancelar resposta

Pronto para começar a usar o Couchbase Capella?

Iniciar a construção

Use o Capella gratuitamente

Entre em contato