Olá pessoal, nos próximos meses, faremos uma série de blogs que acompanharão o desenvolvimento do Couchbase .NET 2.0 SDK. Neste post, abordarei a arquitetura de alto nível, algumas motivações e recursos que você deve esperar e quais são os objetivos gerais do .NET SDK em relação aos outros clientes do Couchbase: Node, PHP, Java e C. Discutir os objetivos do SDK do .NET no escopo de todo o conjunto de clientes do Couchbase é uma etapa importante na unificação das APIs, para que os desenvolvedores tenham uma experiência de programação consistente, independentemente do SDK escolhido.
História e motivação
Primeiramente, vamos falar sobre qual é a motivação para reescrever o SDK do Couchbase .NET. Observe que, em sua maior parte, essa é uma reescrita completa do zero... praticamente todos os componentes estão sendo reprojetados e desenvolvidos para atender melhor às necessidades de nossos clientes e da comunidade de usuários em geral. A esta altura, a maioria de nós já foi avisada de que o o pior erro estratégico que uma empresa de software pode cometer é reescrever um código funcional e funcional do zero, mas nós, aqui no Couchbase, achamos que essa é a melhor decisão, considerando o histórico e o estado do SDK .NET 1.X e a direção que queremos seguir com o cliente.
Um pouco de história pode ser útil aqui. O cliente atual é baseado no cliente Memcached .NET original: Enyim.Caching. Ela foi escrita há vários anos e originalmente suportava o protocolo Memcached Text e, eventualmente, também o protocolo Memcached Binary. Por si só, ele foi projetado para ser uma API autônoma, não uma estrutura para a criação de outras APIs. Dito isso, o atual cliente .NET Couchbase foi criado com base em uma bifurcação do código-fonte Enyim.Caching; fizemos a bifurcação porque o autor original, embora fosse um grande apoiador, não tinha mais o tempo necessário para manter o projeto em andamento. O cliente Couchbase adicionou suporte a visualizações e outros recursos específicos do Couchbase Server sobre o material K/V já suportado pelo Enyim.Caching.
Como o cliente foi originalmente baseado em um protocolo baseado em K/V, a adaptação de alguns dos recursos do Couchbase criou uma API um tanto espinhosa. Além disso, à medida que mais camadas foram adicionadas, a complexidade também aumentou, tornando o suporte e a manutenção do cliente cada vez mais difíceis. Além disso, como o cliente é realmente baseado no .NET 3.5 (embora criemos para o 4.0, o 3.5 é o LCD), não estávamos progredindo com os recursos atuais de última geração do .NET, como as novas e poderosas bibliotecas/recursos assíncronos baseados em tarefas (async/await) e melhorias nas APIs de rede. Portanto, manter a compatibilidade com versões anteriores e progredir com o cliente é impossível; precisamos tomar uma direção totalmente nova.
Metas e recursos
As metas/objetivos do SDK do Couchbase .NET 2.0 são bastante simples:
- Unificação e consistência da interface de programação em todas as plataformas do SDK do Couchbase (Java, .NET, PHP, Node, C, etc.)
- Um design flexível e orientado por testes - extensibilidade em seu núcleo
- Altamente configurável, mas fácil de colocar em funcionamento com a configuração padrão
- E/S assíncrona - um modelo sem bloqueio para programação de rede
- Uma interface de programação simples e fácil de usar
- Uso minimalista de conexões cliente/servidor
- Documentação aprimorada
Alguns recursos prováveis incluem:
- Suporte para a publicação de configuração da operadora de cluster (CCCP) - uma nova maneira de atualizar a configuração dos clientes com base no estado atual dos clusters por meio de um mecanismo de extração
- Padrão assíncrono baseado em tarefas (TAP) suporte para operações de K/V e View
- Primeira classe N1QL suporte - N1QL é a nova e incrível linguagem de consulta semelhante ao SQL no Couchbase
- A LINQ implementação do provedor sobre a API principal
- Pontos de integração com outras tecnologias .NET, como ASP.NET e Frameworks, para desenvolver rapidamente aplicativos orientados por dados
Arquitetura de alto nível
Nos últimos dois anos, a equipe do SDK do Couchbase desenvolveu vários clientes do Couchbase Server em diferentes plataformas e estruturas: .NET, Java, Node.js etc. Como cada um desses clientes foi desenvolvido e evoluiu com as alterações no servidor, surgiram vários padrões para o desenvolvimento de um cliente com reconhecimento de cluster ou, mais especificamente no caso do Couchbase, um cliente "inteligente". Com o objetivo de "unificar a interface de programação", implementamos esses padrões em cada cliente. Discutiremos esses padrões em detalhes em postagens posteriores.
Componentes do cliente Couchbase
Esses componentes formam um cliente do Couchbase:
- IO - Gerenciamento de recursos e acesso geral à programação de rede
- Configuração - Configuração do cliente e do servidor
- Operações - operações de chave/valor e visualização em documentos JSON: Get, Set, etc.
- Mapa do cluster - gerencia os nós ativos e onde as chaves são armazenadas no cluster
- Registro e instrumentação - Registro geral, rastreamento e monitoramento da atividade do cliente
Próximo
Bem, por enquanto é isso. A seguir, examinaremos o projeto e o desenvolvimento de uma parte do componente Configuration: Configuração do servidor. A configuração do servidor conduz o estado do cliente, que é paralelo ao estado do cluster. Uma mudança no cluster geralmente significa uma mudança no estado do cliente também, o que traz consigo várias complexidades e problemas que devem ser resolvidos para manter as coisas estáveis.
Tudo isso parece incrível. Agora a grande pergunta: quando você planeja lançá-lo?
Em um futuro próximo, publicaremos datas para visualizações de desenvolvedores, beta\s e, finalmente, a versão GA. Fique ligado!
Olá, Jeff - estamos iniciando a criação de um produto novo e empolgante usando a versão 1.3. Suponho que haverá muitas mudanças com a versão 2.0, portanto, você nos aconselharia a manter nossa abordagem simples até que os detalhes da versão 2.0 sejam divulgados, para evitar uma grande quantidade de reconfigurações? Uma pergunta tão subjetiva... eu sei. thx
Oi Jake -
Haverá mudanças significativas na forma como o cliente é criado, como você interage com um bucket por meio de um cliente e os próprios elementos de configuração. Além disso, embora as mesmas operações de K/V e visualização sejam suportadas, a interface será bem diferente da atual do .NET.
Talvez você queira considerar seu próprio wrapper para o cliente, de modo que possa depender dessa interface em vez do CB, facilitando assim a atualização no futuro. Sim, manter as coisas simples também ajudará na atualização futura.
Em breve, farei outra postagem com uma visão geral de alto nível de como serão as interfaces do cliente, o que deve ajudar algumas pessoas.
-Jeff
Obrigado, Jeff
Olá, Jeff, estamos desenvolvendo um aplicativo em que preciso ter certeza absoluta de que os dados serão mantidos quando a interface do cliente não retornar nenhum erro. Com base na documentação atual, aprendi que, quando o cliente não retorna nenhum erro, isso significa apenas que os dados chegaram à memória e estão na fila para persistência no disco e serão transferidos pelo processo de tratamento da fila para um ou mais servidores de réplica. Quando, nesse momento, o servidor que está lidando com a solicitação do cliente sofre uma falha ou simplesmente trava, os dados estão sujeitos a serem perdidos. Isso é realmente um obstáculo para o nosso aplicativo e, em vez disso, tendemos a usar um sqldbs comum para ficarmos protegidos pelo sistema de transações. A interface 2.0 resolverá esse problema e só retornará com o status ok quando os dados forem entregues em um servidor E os dados estiverem na memória (como uma réplica) em pelo menos um outro servidor. Isso garante que os dados serão salvos e ficarão visíveis depois que o processo de failover tiver lidado com o servidor com falha. O aplicativo tolera a impossibilidade de ler todos os dados armazenados, desde que o failover não seja tratado pelo cluster, de modo que a indisponibilidade temporária dos dados armazenados (por alguns minutos) não é um obstáculo.
Gostamos dos outros recursos flexíveis do couchbase, mas essa é uma situação inviável se isso não for corrigido.
Saudações, Martien
Martien -
Temos um mecanismo chamado \"Observe\" para lidar com restrições de durabilidade como a que você está solicitando. Você pode ler mais sobre ele aqui: http://www.couchbase.com/wiki/…
Me diga como as coisas estão indo!
Obrigado,
Jeff
Olá, Jeff,
Eu ignorei completamente esse recurso, era isso que eu estava procurando. Portanto, agora posso continuar a avaliação!!! Muito obrigado e feliz Páscoa.
Martien
Olá, Jeff,
De fato, existem funções de observação, mas, infelizmente, elas não são compatíveis com o .ExecuteCas, que eu preciso para garantir que substitua os dados de forma correta e consistente. Alguma ideia?
Saudações, Martien