¿Qué contiene un SDK?
Couchbase Server ofrece múltiples servicios para almacenar, recuperar, consultar y analizar tus datos. Cada servicio expone una API pública, ya sea como API REST o a través de un protocolo binario Memcached extendido de nivel inferior. Con la autenticación adecuada y los puertos abiertos, cualquier aplicación puede utilizar estas API, pero tienen un coste, la complejidad y la falta de seguridad de tipos en su mayor parte. Seamos realistas, la mayoría de los desarrolladores de aplicaciones no están preocupados por analizar una respuesta REST o desempaquetar paquetes Memcached; quieren construir rápida y eficientemente sus soluciones para resolver sus necesidades de negocio únicas. Quieren una librería que se encargue de la gestión de recursos, sharding, gestión de cambios en la topología del cluster, etc. que es el papel que desempeña el SDK de Couchbase.
¿Por qué cambiamos?
SDK 1.0 se alineaba con Couchbase Server 1.x y soportaba principalmente la lectura/escritura de pares Clave/Valor en formato binario y JSON usando el protocolo Memcached y Views. Los SDK se desarrollaron de forma independiente y carecían de una interfaz API coherente. En algunos casos, las diferencias de empaquetado de Memcached hacían que los datos no se pudieran compartir entre los SDK.
SDK 2.0 soporta nuevas características de Couchbase Server a medida que evoluciona: N1QL, el lenguaje tipo SQL para consultar documentos JSON almacenados en Couchbase Server, autenticación mejorada usando Role Based Access Control (RBAC), soporte JSON mejorado, Analytics, Full Text Search (FTS) y otras herramientas para interactuar con tus datos. En 2.X hemos alineado las interfaces y las hemos hecho consistentes, en su mayor parte, en todos los SDKs utilizando un RFC para asegurar la adherencia a las interfaces definidas y hemos incluido un componente Common Flags para asegurar que los datos se pueden escribir y leer desde cualquier SDK. En el lado negativo, la interfaz de IBucket se hinchó y se hizo difícil de usar al incluir múltiples API.
SDK 3.0 se alinea con las nuevas características de Couchbase Server que se extienden desde la interfaz tradicional Bucket: soporte para Scopes y Collection que estará disponible como un Vista previa para desarrolladores en Couchbase Server 6.5 y como GA en Couchbase Server 7.0. Además, consolida y refina las interfaces formalmente hinchadas y basadas en sobrecargas en una interfaz más pequeña y concisa, al tiempo que conserva y mejora la conformidad entre SDK.
¿Cómo lo hacemos?
Todos los SDK se suscriben al Versionado semántico 2.0.0 Especificación (SemVer) donde para cualquier número de versión dado MAYOR.MENOR.PARCHE se incrementa cuando:
- MAYOR cuando realice cambios incompatibles en la API,
- MENOR versión cuando se añaden funciones de forma compatible con versiones anteriores, y
- PATCH versión cuando realice correcciones de errores compatibles con versiones anteriores.
Además, para las versiones preliminares y los metadatos de compilación añadimos extensiones a la especificación SemVer según lo permita. Por ejemplo, nuestras primeras versiones del SDK 3.0 utilizan la designación "alfa" más un incremento para la versión alfa. Por ejemplo, nuestras primeras versiones preliminares de SDK 3.0 utilizaban la siguiente versión compatible con SemVer: "3.0.0-alpha1". La siguiente versión preliminar, después de las versiones alfa, será "3.0.0-beta1" y, por último, una versión GA totalmente compatible será "3.0.0". En general, se esperan cambios de última hora entre las versiones "alfa", que no deberían producirse (pero en algunos casos pueden ser necesarios) una vez que se publique la "beta".
Tenga en cuenta que se trata de una ligera discrepancia entre la versión del servidor en que Couchbase Server ofrecerá pre-lanzamientos como "developer previews" o "dp" y luego "beta" y finalmente GA.
Ámbitos y colecciones en Couchbase Server 6.5+
En las versiones de Couchbase Servers anteriores a la 6.5, los Buckets se utilizaban como una entidad lógica, con nombre de usuario, que agrupa elementos; permitiendo su acceso, indexación, replicación y control de acceso.
Esta era realmente la única forma de conseguir multi-tenancy usando Couchbase Server y venía con algunas limitaciones: Los buckets en sí son bastante intensivos en recursos y un cluster sólo puede gestionar eficientemente un número finito de buckets. Para arquitecturas modernas de microservicios o cualquier arquitectura donde se necesite multi-tenancy, esto suponía algunos retos a la hora de servir a una gran cantidad de inquilinos. Esto se resuelve en Couchbase Server 6.5+ con Scopes y Collections.
Un Scope en Couchbase 6.5+ representa una unidad de multi tenencia y permite que los nombres de las Colecciones sean reutilizados; cualquier Scope dado puede contener exactamente un único nombre de Colección. Un Scope es simplemente un grupo de colecciones. Cada Bucket contiene un Scope por defecto con el nombre "_por defecto" y un identificador de ámbito 0 (cero) que contiene una colección por defecto denominada "_por defecto"y el identificador 0 (cero) que lo acompaña. Por supuesto, para cada Ámbito determinado pueden crearse múltiples Colecciones.
De este modo, las operaciones clave/valor que se realizaban en el contexto de bucket en SDK1.0 y SDK2.0 pasan al contexto de colección en SDK3.0. Por su parte, las operaciones entre cubos, como FTS, Analytics y N1QL, se realizan ahora a nivel de clúster.
.NET SDK 3.0 Serie Alfa
El primer volcado de paquetes del SDK .NET 3.0 de Couchbase fue Couchbase Alfa 2 (La alfa 1 contenía un error que hizo necesario liberar y aumentar la versión). Alfa 3 fue lanzada el 26 de abril - ¡tenemos planeado lanzar varias más! El objetivo de este pre-release es proporcionar los bits para programar operaciones Key/Value y consultas N1QL contra Couchbase Server. Contiene las conocidas estructuras lógicas Cluster y Bucket, así como las nuevas estructuras Scope y Collections. Ten en cuenta que mientras que Scopes y Collections son parte de Couchbase 6.5 que no saldrá hasta finales de este año o el año que viene, SDK 3.0 también soporta Couchbase 5.0 y superiores usando el Scope y Collection por defecto explicados anteriormente.
Cluster y Buckets en SDK 3.0
Al igual que en SDK 2.0, los objetos Cluster y Bucket están de vuelta en SDK 3.0, cada uno representando sus equivalencias de servidor. La conexión a un Cluster y la apertura de un Bucket se realizan de forma similar a SDK2.0:
|
1 2 3 4 5 6 7 8 |
//Configurar y abrir un objeto clúster var grupo = nuevo Grupo(nuevo Configuración(). ConServidores("couchbase://localhost"). ConCubo("por defecto"). ConCredenciales("Administrador", "contraseña")); //abrir un cubo llamado "default" var cubo = await Grupo.Cubo("por defecto"); |
Al igual que en SDK2.0, los objetos Cluster y Bucket son objetos de larga duración cuya vida se extiende generalmente desde el inicio de la aplicación hasta su cierre.
Uso del ámbito y las colecciones por defecto en Couchbase Server 6.0
Todas las operaciones clave/valor existen ahora en el nivel de las colecciones, que siempre serán miembros de exactamente un ámbito. He aquí un par de ejemplos de acceso a una colección y, a continuación, de lectura y escritura de datos en la colección.
|
1 2 3 4 5 6 7 8 9 10 11 |
//abrir la colección/ámbito por defecto var colección = await cubo.GetDefaultCollection(); //añadir un nuevo documento await colección.Inserte(clave, nuevo {nombre = "mike"}); //recuperar el documento utilizando (var resultado = await colección.Visite(clave)) { var contenido = resultado.ContenidoComo<dinámico>(); Consola.WriteLine(contenido.nombre); } |
Nótese que estamos usando Couchbase Server 6.0 y por lo tanto no tenemos soporte para Scope o Collection (no estarán disponibles hasta Server 6.5), sin embargo, podemos usar el Scope y Collection "por defecto" como si tuviéramos soporte para Scope y Collections. Tenga en cuenta que esto se añadió como una característica de actualización para migrar hacia la versión más reciente del servidor. El ámbito y la colección "por defecto" siempre estarán disponibles; es similar a cómo funciona un cubo en los SDK anteriores a la versión 3.0.
Tenga en cuenta que después de obtener un documento, el GetResult debe ser eliminado para liberar recursos, de lo contrario los búferes internos se "filtrarán"; este es un cambio del SDK 1.0 y 2.0.
Uso del ámbito y las colecciones con nombre en Couchbase Server 6.5+
Este es el futuro de Couchbase; la capacidad de dividir un Bucket en múltiples Scopes lógicos (Multi-tenancy) y Colecciones de documentos distintos. Esto reemplaza el requisito en las primeras versiones del servidor Couchbase de añadir un campo especial "tipo" que designaba una especie de agrupación de documentos por nombre que luego podrían ser consultados de forma independiente dentro de un Bucket. Creo que encontrarás que es un modelo de programación mucho más intuitivo y permitirá futuros avances de las características del servidor en el futuro.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
//Abrir un Ámbito y luego una Colección var alcance = await cubo.Alcance("ACME"); var colección = await alcance.Colección("herramientas"); //añadir un nuevo documentawait colección.Inserte(clave, nuevo Herramienta(Nombre = "Martillo", Tipo="Bola peen"}); //recuperar el documento utilizando (var resultado = await colección.Visite(clave)) { var contenido = resultado.ContenidoComo<Herramienta>(); Consola.WriteLine(contenido.Nombre); } |
Uso del clúster para consultas N1QL
N1QL, al igual que Analytics y FTS, se consideran de ámbito "global" en el sentido de que una consulta puede hacer referencia a varios Buckets. Inicialmente, en SDK 2.0, las consultas N1QL tenían como ámbito el Bucket y más tarde se añadieron al Cluster, en SDK 3.0 actualmente sólo se puede consultar desde el objeto Cluster.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
//ejecutar una consulta contra el cluster var declaración = "SELECT * FROM `default` WHERE type=$name;"; var resultado = await grupo.Consulta<dinámico>(declaración, parámetros =>{parámetros.Añadir("nombre", "persona");}); //enumerar las filas devueltas foreach(var fila en resultado){ Consola.WriteLine(fila.nombre); } //liberar los búferes internos resultado.Deseche(); |
En general, todos los servicios (Query, FTS y Analytics) tienen una API pública muy similar a la del SDK 2.0. Sin embargo, por coherencia, el campo obligatorio (la sentencia SQL para N1QL) se ha añadido como parámetro en el lado izquierdo y los parámetros opcionales se han consolidado en un bloque o estructura de "opciones" en el lado derecho. Observará que esto se mantiene en todo el SDK y mejora enormemente la coherencia de la API.
Obtención de las versiones alfa del SDK de Couchbase .NET 3.0
Al igual que con todas las versiones del SDK .NET de Couchbase, ofrecemos descargas del paquete NuGet y también se publicará en NuGet.
Por último, un agradecimiento especial a Brant Burnett, de Centeredge Software, por su enorme contribución a esta versión.
¿3.0 significa que puede introducir cambios de última hora?
¿Por qué no seguir la convención de sufijar los métodos con Async cuando son Async?
Hola Thomas -
Sí, hay un montón de cambios de última hora - la API pública está completamente reescrita desde SDK 2.X.
La razón para no utilizar el sufijo "Async" es que no hay métodos de sincronización, por lo que no hay razón para diferenciar entre llamadas síncronas y asíncronas. Tenga en cuenta que esto puede cambiar en futuras versiones a medida que recibamos más comentarios como el suyo.
Gracias por sus comentarios.
-Jeff