Esta versão é a versão GA oficial do suporte do .NET Core para o SDK do Couchbase .NET! O .NET Core é a encarnação mais recente do .NET framework e é descrito como ".NET Core é uma plataforma extremamente rápida, leve e modular para criar aplicativos e serviços da Web que são executados no Windows, Linux e Mac"
Espere um minuto... leia isso novamente: O ".NET Core é uma plataforma extremamente rápida, leve e modular para a criação de aplicativos e serviços da Web que Executar no Windows, Linux e Mac“. Aplicativos Microsoft .NET em execução no OSX e no Linux? Em que tipo de mundo bizarro estamos vivendo? É a "nova" Microsoft, com certeza!
Nesta postagem do blog, abordarei o que há na versão 2.4.0, as alterações no empacotamento (NuGet) e a versão do .NET compatível com o SDK. Também demonstraremos alguns dos novos recursos, como Datastructures.
O que há nesta versão?
O 2.4.0 é um grande lançamento com mais de 30 commits. Se considerarmos que lançamos 3 Developer Previews antes da versão 2.4.0, na verdade há muito, muito mais commits que levaram a essa versão nos últimos 6 meses. Aqui está uma visão geral de alguns dos recursos mais impressionantes - você pode ver todos os commits na seção "Notas da versão" abaixo:
Suporte ao .NET Core
Obviamente, o recurso mais importante do 2.4.0 é o suporte ao .NET Core, o que, de acordo com o parágrafo inicial, significa que agora você pode desenvolver no Mac OS ou no Windows e implantar no Linux (ou vice-versa, mas as ferramentas ainda são um pouco imaturas). Esse é um ótimo material e uma grande mudança para o desenvolvedor tradicional do Windows.
Se você não conhece o .NET Core, pode ler mais sobre ele no site Site do .NET Core. Um aspecto interessante é que ele é de código aberto (Apache 2.0) e o código-fonte está disponível no Github.
O SDK do Couchbase é compatível especificamente com o netstandard1.5 ou superior. Testamos o SDK usando a versão 1.0.0-preview2-1-003177 das ferramentas de linha de comando.
Mudanças na embalagem
Assim como nas três visualizações prévias do desenvolvedor, o pacote NuGet conterá binários para o .NET Full Framework (voltado para o .NET 4.5 ou superior), mas também para o .NET Core (voltado para o .NET Core 1.1). Dependendo do projeto de destino para o qual você está incluindo a dependência, os binários corretos serão usados.
Portanto, se o seu projeto do Visual Studio for um aplicativo .NET Full Framework maior ou igual a 4.5, você obterá os binários para a versão full framework do .NET. Da mesma forma, se seu aplicativo for um aplicativo .NET Core, a versão .NET Core dos binários será usada. Não deve haver nada que você precise fazer para habilitar isso.
A versão mais antiga do .NET 4.5 dos pacotes não será mais lançada; a 2.3.11 é a última versão com suporte da série 2.3.X.
Registro em log do MS para o Core
Para o .NET Core, decidimos mudar o uso do Comum.Registro para o MS Logging, principalmente porque nenhum terceiro (log4net por exemplo) têm suporte estável para o .NET Core no momento.
Além disso, ao mudar de Comum.Registro em log Ao usar o Common.Logging para o MS Logging, removemos mais uma dependência de terceiros, o que é sempre bom. Não que o Common.Logging não fosse suficiente, mas faz mais sentido usar uma dependência da Microsoft.
Aqui está um exemplo de configuração do cliente 2.4.0 voltado para o .NET Core e usando o NLog:
Primeiro, adicione as dependências ao project.json:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
{ "versão": "1.0.0-*", "buildOptions": { "emitEntryPoint": verdadeiro, "copyToOutput": { "include": [ "config.json", "nlog.config" ] } }, "dependencies" (dependências): { "CouchbaseNetClient": "2.4.0-dp6", "NLog.Extensions.Logging": "1.0.0-rtm-beta1", "Microsoft.NETCore.App": { "tipo": "plataforma", "versão": "1.0.1" }, "Microsoft.Extensions.Logging.Debug": "1.1.0", "Microsoft.Extensions.Logging": "1.1.0" }, "estruturas": { "netcoreapp1.0": { "importações": "dnxcore50" } } } |
Em seguida, adicione um arquivo nlog.config ao seu projeto com o seguinte conteúdo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
<?xml versão="1.0" codificação="utf-8" ?> <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" (verdadeiro) internalLogLevel="Depurar" internalLogFile="c:\temp\internal-nlog.txt"> <targets> <alvo xsi:tipo="Arquivo" nome="allfile" nome do arquivo="c:\temp\nlog-all-${shortdate}.log" layout="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}" /> <alvo xsi:tipo="Null" (nulo) nome="buraco negro" /> </targets> <rules> <!--All logs, including from Microsoft--> <logger nome="*" nível mínimo="Traço" writeTo="allfile" /> </rules> </nlog> |
Por fim, adicione o código para configurar o SDK do Couchbase para registro:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
usando Couchbase; usando Couchbase.Registro em log; usando Microsoft.Extensões.Registro em log; usando NLog.Extensões.Registro em log; espaço de nome ConsoleApp2 { público classe Programa { público estático vazio Principal(string[] argumentos) { var fábrica = novo Fábrica de registradores(); fábrica.AddDebug(); fábrica.AddNLog(); fábrica.ConfigurarNLog("nlog.config"); //configurar o registro em log no cliente couchbase var configuração = novo Configuração de cliente { Fábrica de registradores = fábrica }; var agrupamento = novo Aglomerado(configuração); //usar o cliente couchbase } } } |
Observe que o project.json tem um copyToOutput.incluir valor para nlog.configuração . Isso é necessário para que o ferramental copie esse arquivo para o diretório de saída quando construído.
Agora, para os binários do .NET 4.5 Full Framework, a dependência do Comum.Registro em log permanece e qualquer configuração de registro existente deve funcionar como sempre funcionou.
Estruturas de dados
As estruturas de dados são uma nova maneira de trabalhar com documentos do Couchbase como se fossem estruturas de dados comuns da ciência da computação, como listas, filas, dicionários ou conjuntos. Há duas implementações no SDK; uma como uma série de métodos em CouchbaseBucket que fornecem funcionalidade para operações comuns de estrutura de dados e outro como implementações das interfaces dentro de Sistema.Coleções.Genéricos . Aqui está uma descrição de cada classe de estrutura de dados encontrada no SDK:
- CouchbaseDictionary<TKey, Valor da TV> : Representa uma coleção de chaves e valores armazenados em um documento do Couchbase.
- CouchbaseList<T> : Representa uma coleção de objetos, armazenados no servidor Couchbase, que podem ser acessados individualmente por índice.
- CouchbaseQueue<T> : Fornece uma estrutura de dados persistente do Couchbase com comportamento FIFO.
- CouchbaseSet<T> : Fornece um conjunto persistente do Couchbase, que é uma coleção de objetos sem duplicatas.
Todas essas classes são encontradas na classe Couchbase.Coleções namespace. Aqui está um exemplo de uso de um CouchbaseQueue<T> :
|
1 2 3 4 5 6 7 |
var fila = novo CouchbaseQueue<Poco>(_bucket, "somekey"); fila.Enfileirar(novo Poco { Nome = "pcoco1" }); fila.Enfileirar(novo Poco { Nome = "pcoco2" }); fila.Enfileirar(novo Poco { Nome = "pcoco3" }); var item = fila.Fila de espera(); Afirmar.AreEqual("pcoco1", item.Nome); |
Multiplexação de E/S
O SDK do Couchbase usou o pooling de conexões no passado para permitir alta taxa de transferência e escalonamento ao custo de latência e utilização de recursos. No Couchbase 2.2.4 introduzimos um modelo de IO melhor, chamado Multiplexing IO ou MUX-IO, que o cliente pode ser configurado para usar (o padrão era conexões em pool).
Na versão 2.4.0, estamos tornando o MUX-IO o modelo de E/S padrão e tornando o pooling de conexões opcional. O que isso significa para você é que algumas propriedades de pooling de conexão em sua configuração ainda podem ser usadas no SDK. Por exemplo:
- PoolConfiguration.Tamanho máximo ainda é usado, mas deve ter valores relativamente pequenos - por exemplo, 5-10
- PoolConfiguration.Tamanho mínimo deve ser 0 ou 1
Para desativar o MUX-IO, basta definir o parâmetro Configuração de cliente.UseConnectionPoolingpara true (o padrão é false) para usar o pooling de conexões:
|
1 2 3 4 5 6 |
var clientConfig = novo Configuração de cliente{ UseConnectionPooling = falso }; var agrupamento = novo Aglomerado(clientConfig); //abrir buckets e usar o cliente |
Transmissão de N1QL e visualizações
O streaming N1QL e as visualizações são uma otimização de desempenho em determinados casos em que a quantidade de dados recuperados é grande. Para entender o motivo, vamos considerar como funcionam as consultas sem streaming:
- Uma solicitação é enviada ao servidor.
- O servidor faz seu processamento e retorna os resultados como um fluxo após processar toda a resposta.
- O cliente armazena em buffer o fluxo inteiro e, em seguida, desserializa o fluxo em uma coleção do tipo "T", em que T é o POCO para o qual cada resultado é mapeado.
- O servidor retorna a lista para o aplicativo em seu IResultado
O que pode dar errado aqui? Pense em resultados muito grandes e que os recursos de memória são finitos: eventualmente, você sempre encontrará um OutOfMemoryException ! Há também outros efeitos colaterais relacionados à coleta de lixo.
Com clientes de streaming, o processo é o seguinte:
- Uma solicitação é enviada ao servidor
- O servidor faz o processamento e retorna os resultados como um fluxo assim que os cabeçalhos de resposta estiverem disponíveis.
- O cliente lê parcialmente os cabeçalhos e metadados e, em seguida, faz uma pausa até que a iteração ocorra.
- Quando o aplicativo começa a iterar sobre o IResultado Cada item é lido um de cada vez sem ser armazenado em uma coleção subjacente.
A grande vantagem aqui é que o conjunto de trabalho da memória não aumentará à medida que a coleção crescer e for redimensionada internamente pelo .NET. Em vez disso, você tem um tamanho de memória de trabalho fixo e o GC pode ocorrer assim que o objeto lido for descartado.
Para usar o N1QL de streaming e as exibições, tudo o que você faz é chamar o comando UseStreaming() e passar true para o fluxo:
|
1 2 3 4 5 |
var solicitação = novo Solicitação de consulta("SELECT * FROM `travel-sample` LIMIT 100;").UseStreaming(verdadeiro); usando (var resultado = _bucket.Consulta<dinâmico>(solicitação)) { Console.WriteLine(resultado); } |
Passar false significará que toda a resposta será armazenada em buffer e processada antes de retornar.
Cancelamento de consulta N1QL
Esse recurso permite que as consultas N1QL de longa duração sejam canceladas antes de serem concluídas usando tokens de cancelamento de tarefas. Por exemplo:
|
1 2 3 4 |
var cancellationTokenSource = novo CancellationTokenSource(Tempo.FromMilliseconds(5)); var resultado = aguardar _bucket.QueryAsync<dinâmico>(queryRequest, cancellationTokenSource.Token); //fazer algo com o resultado |
Esse commit foi feito por meio de uma contribuição da comunidade de Brant Burnett de CenteredgeSoftware.com!
Observação importante sobre TLS/SSL no Linux
Há um problema no Linux que você pode encontrar se estiver usando SSL: uma PlatformNotSupportedException será lançada se você tiver uma versão da libcurl instalada no servidor < 7.30.0. A solução alternativa é simplesmente atualizar sua instalação da libcurl no Linux para algo igual ou superior à versão 7.30.0. Você pode ler mais sobre isso no ticket do Jira: NCBC-1296.
[...] Leia tudo sobre isso na postagem do blog de Jeff Apresentando o Couchbase .NET 2.4.0 - .NET Core GA. [...]
[...] a recente versão do Couchbase .NET SDK 2.4.0 adicionou muitos recursos novos. No entanto, há um recurso menor que vale a pena mencionar. [...]
[Com o lançamento do Couchbase .NET SDK 2.4.0, o Couchbase agora tem suporte oficial para o .NET Core. Isso abre um vasto mundo novo para o .NET [...]