Hola amigos, durante los próximos meses haremos una serie de blogs que seguirán el desarrollo del SDK .NET 2.0 de Couchbase. En este post repasaré la arquitectura de alto nivel, algunas motivaciones y características que deberías esperar, y cuáles son los objetivos generales del SDK .NET con respecto a los otros clientes de Couchbase: Node, PHP, Java, y C. Discutir los objetivos del SDK .NET dentro del ámbito de toda la suite de clientes Couchbase es un paso importante en la unificación de las API's, para que los desarrolladores tengan una experiencia de programación consistente sin importar el SDK que elijan.
Historia y motivación
En primer lugar, vamos a hablar de cuál es nuestra motivación para reescribir el SDK .NET de Couchbase. Tenga en cuenta que en su mayor parte, se trata de una reescritura completa desde cero ... casi todos los componentes están siendo rediseñados y desarrollados para satisfacer mejor las necesidades de nuestros clientes y la comunidad de usuarios en general. A estas alturas, la mayoría de nosotros ya hemos sido advertidos de que el El peor error estratégico que puede cometer una empresa de software es reescribir desde cero un código funcional que funcione., pero aquí en Couchbase creemos que es la mejor decisión dada la historia y el estado del SDK .NET 1.X y la dirección que queremos seguir con el cliente.
Conviene hacer un poco de historia. El cliente actual está basado en el cliente .NET original de Memcached: Enyim.Caching. Fue escrita hace varios años y originalmente soportaba el protocolo Memcached Text y eventualmente también el Memcached Binary Protocol. En sí misma, fue diseñada para ser una API independiente, no un framework para crear otras APIs. Dicho esto, el actual cliente .NET Couchbase se construyó sobre una bifurcación del código fuente de Enyim.Caching; lo bifurcamos porque el autor original, aunque era un gran colaborador, ya no tenía el tiempo necesario para mantener el proyecto en marcha. El cliente Couchbase añadió soporte de vistas y otras características específicas de Couchbase Server además de las cosas K/V ya soportadas por Enyim.Caching.
Dado que el cliente se basó originalmente en un protocolo basado en K/V, la adaptación de algunas de las características de Couchbase ha hecho que la API sea un poco espinosa. Además, a medida que se han ido añadiendo capas, la complejidad también ha aumentado, lo que ha dificultado cada vez más el soporte y mantenimiento del cliente. Además, dado que el cliente se basa realmente en .NET 3.5 (aunque construimos para 4.0, 3.5 es la LCD), no estábamos progresando con el estado actual de las características de .NET, como las nuevas y potentes bibliotecas y características asíncronas basadas en tareas (async/await) y las mejoras en las API de red. Mantener la compatibilidad con versiones anteriores y hacer progresar el cliente es, por tanto, imposible; tenemos que tomar una dirección completamente nueva.
Objetivos y características
Las metas/objetivos del SDK .NET 2.0 de Couchbase son bastante simples:
- Unificación y coherencia de la interfaz de programación en todas las plataformas del SDK de Couchbase (Java, .NET, PHP, Node, C, etc.)
- Un diseño flexible y basado en pruebas: su núcleo es la extensibilidad
- Altamente configurable, pero fácil de poner en marcha con la configuración predeterminada.
- E/S asíncrona: un modelo no bloqueante para la programación en red
- Una interfaz de programación sencilla y fácil de usar
- Uso minimalista de conexiones cliente/servidor
- Documentación mejorada
Algunas características probables son:
- Compatibilidad con la publicación de configuración de portadores de clústeres (CCCP) - una nueva forma de actualizar la configuración de los clientes basada en el estado actual de los clusters a través de un mecanismo pull.
- Patrón asíncrono basado en tareas (TAP) apoyo a las operaciones K/V y View
- Primera clase N1QL N1QL es el nuevo lenguaje de consulta SQL de Couchbase.
- A LINQ implementación del proveedor sobre la API básica
- Puntos de integración con otras tecnologías .NET como ASP.NET y Frameworks para desarrollar rápidamente aplicaciones basadas en datos.
Arquitectura de alto nivel
Durante los últimos dos años, el equipo de SDK de Couchbase ha desarrollado varios clientes de Couchbase Server en diferentes plataformas y frameworks: .NET, Java, Node.js, etc. Como cada uno de estos clientes se han desarrollado y evolucionado con los cambios en el servidor, han surgido varios patrones para el desarrollo de un cliente consciente de clúster, o más específicamente en el caso de Couchbase, un cliente "inteligente". Con el objetivo de "unificar la interfaz de programación", implementamos estos patrones dentro de cada cliente. Discutiremos esos patrones en detalle en posts posteriores.
Componentes de cliente Couchbase
Estos componentes forman un cliente Couchbase:
- IO - Gestión de recursos y acceso general a la programación de red
- Configuración - Configuración del cliente y del servidor
- Operaciones - Operaciones de clave/valor y vista en documentos JSON: Get, Set, etc.
- Mapa del clúster: gestiona los nodos activos y dónde se almacenan las claves en el clúster.
- Registro e instrumentación: registro general, seguimiento y supervisión de la actividad de los clientes.
Siguiente
Bueno, eso es todo por ahora. A continuación repasaremos el diseño y desarrollo de una parte del componente Configuración: Configuración del Servidor. La Configuración del Servidor maneja el estado del cliente que es paralelo al estado del cluster. Un cambio en el cluster generalmente, significa un cambio en el estado del cliente también, lo que trae consigo varias complejidades y problemas que deben ser abordados para mantener las cosas estables.
Todo esto suena increíble. Ahora la gran pregunta, ¿cuándo tienen previsto lanzarlo?
Próximamente publicaremos las fechas de las versiones preliminares para desarrolladores, las versiones beta y, por último, la versión GA. Permanezca atento.
Hola Jeff - estamos iniciando una nueva y emocionante construcción de productos utilizando 1.3. Supongo que habrá un montón de cambios que vienen con 2.0 por lo que nos aconseja mantener nuestro enfoque simple hasta que los detalles 2.0 salen a ahorrar una tonelada de recableado? Es una pregunta muy subjetiva, lo sé. Gracias.
Hola Jake -
Habrá cambios significativos en la forma de crear el cliente, en la forma de interactuar con un cubo a través de un cliente y en los propios elementos de configuración. Además, aunque se soportarán las mismas operaciones de K/V y vista, la interfaz será bastante diferente a la actual de .NET.
Tal vez quieras considerar tu propia envoltura para el cliente, de modo que puedas depender de esa interfaz en lugar de la CB, facilitando así la actualización en el futuro. Sí, mantener las cosas simples también ayudará en la futura actualización.
En breve publicaré otro post en el que daré una visión general de cómo serán las interfaces de cliente, lo que debería ayudar a algunos.
-Jeff
Gracias Jeff
Hola Jeff, Estamos desarrollando una aplicación en la que debo estar absolutamente seguro de que los datos persisten cuando la interfaz del cliente no devuelve errores. De la documentación actual me entero de que cuando el cliente no devuelve errores esto sólo significa que los datos han llegado a la memoria y están en cola para su persistencia en disco y serán transferidos por el proceso de gestión de colas a uno o más servidores de réplica. Si en ese momento el servidor que está gestionando la petición del cliente falla o simplemente se bloquea, los datos pueden perderse. Esto es realmente un obstáculo para nuestra aplicación y tendemos a utilizar un sqldbs ordinario en su lugar para estar protegidos por el sistema de transacciones. La interfaz 2.0 abordará este problema y sólo devolverá el estado ok cuando los datos se entreguen en un servidor Y los datos estén en memoria (como réplica) en al menos otro servidor. De este modo se garantiza que los datos se guardarán y serán visibles después de que el proceso de conmutación por error se haya ocupado del servidor que ha fallado. La aplicación tolera no ser capaz de leer todos los datos almacenados, siempre y cuando la conmutación por error no es manejado por el clúster, por lo que la falta de disponibilidad temporal de los datos almacenados (por un par de minutos) no es show-stopper.
Nos gustan las otras características flexibles de couchbase pero esta es una situación de no-go si esto no se soluciona.
Saludos, Martien
Martien -
Tenemos un mecanismo llamado "Observe" para manejar las restricciones de durabilidad como lo que usted está pidiendo. Puede obtener más información aquí: http://www.couchbase.com/wiki/…
Ya me contarás qué tal.
Gracias,
Jeff
Hola Jeff,
Pasé por alto completamente esa característica, eso es lo que estaba buscando. ¡Así que ahora puedo continuar con la evaluación! Muchas gracias y felices Pascuas.
Martien
Hola Jeff,
De hecho, hay funciones de observación, pero por desgracia las funciones de observación no son compatibles con .ExecuteCas que necesito para asegurar que reemplazar los datos correctamente y de manera coherente. ¿Alguna idea?
Saludos, Martien