Ahora es más fácil que nunca construir y desplegar microservicios y aplicaciones multi-tenant en Couchbase. La versión 7.0 introduce una nueva función de organización de datos denominada Ámbitos y colecciones.
Los ámbitos y las colecciones permiten el aislamiento lógico de distintos tipos de datos, la gestión independiente del ciclo de vida y el control de la seguridad a varios niveles de granularidad. Los desarrolladores de aplicaciones los utilizan para organizar y aislar sus datos. Los administradores y DevOps encuentran en los múltiples niveles de control de acceso basado en roles (RBAC) -a nivel de Bucket, Scope y Collection- una potente opción para alojar microservicios y tenants a escala.
La funcionalidad completa de esta función es ahora disponible en Couchbase Server 7.0. En la versión 6.5 ya estaba disponible una versión preliminar para desarrolladores con funciones limitadas, que algunos de ustedes ya habrán probado.
¿Qué son los ámbitos y las colecciones de Couchbase?
Los ámbitos y las colecciones son contenedores lógicos dentro de una aplicación Cubo Couchbase.
Es útil pensar en las colecciones como si fueran tablas de una base de datos relacional, pero sin la rigidez de los datos. Los ámbitos son un conjunto de colecciones relacionadas, lo que los hace similares a un esquema RDBMS. Pero en ambos casos, Scopes y Collections son más flexibles ya que almacenan documentos JSON.
La siguiente tabla muestra el mapeo de construcciones RDBMS familiares a Couchbase:
Mapeo de conceptos RDBMS a Couchbase
He aquí un ejemplo de organización de los datos de Couchbase Travel App con Scopes y Collections:
Ejemplo de ámbitos y colecciones con un conjunto de datos de ejemplo
Cómo crear y utilizar ámbitos y colecciones
Puedes crear Scopes y Collections desde cualquiera de los SDKs de Couchbase, couchbase-cliAPI REST, N1QL o desde la interfaz de usuario.
En particular, N1QLLas consultas N1QL son mucho más sencillas y sintácticamente más breves, puesto que ya no es necesario calificar los diferentes tipos de documentos utilizando donde tipo = xxx. En su lugar, basta con remitirse directamente a la Colección.
En el ejemplo que se muestra a continuación, utilizamos N1QL (he ejecutado las sentencias N1QL utilizando concha cbq) para crear un ámbito, un par de colecciones y algunos índices. A continuación, ejecutamos una consulta sencilla que une dos colecciones.
Una consulta N1QL para crear un Ámbito, Colecciones e índices
La escala de ámbitos y colecciones
Couchbase actualmente te permite tener 30 Buckets en un solo cluster. Los ámbitos y las colecciones te permiten crear un número de estas entidades superior en orden de magnitud.
Dado que las colecciones contienen los datos y los ámbitos organizan las colecciones relacionadas, normalmente hay menos ámbitos que colecciones. Los índices secundarios globales (GSI) se crean en las colecciones, y una colección suele tener varios índices.
Teniendo en cuenta estos requisitos, aquí tienes la escala de estas entidades que puedes crear en Couchbase 7.0 (¡muchas!):
-
- Número de colecciones permitidas por clúster: 1,000
- Número de ámbitos permitidos por clúster: 1,000
- Número de índices secundarios globales permitidos por clúster: 10,000
Multi-Tenancy a escala
Las aplicaciones modernas se escriben a menudo como microservicios, y cada aplicación consta de varios (y a veces cientos) de microservicios.
Con la llegada del SaaS y todas sus ventajas, muchas de estas aplicaciones son multiarrendatario. Para los equipos empresariales, es importante mantener bajos los costes de alojamiento de múltiples aplicaciones e inquilinos (es decir, el coste total de propiedad), al tiempo que se proporciona el aislamiento y la flexibilidad necesarios.
Couchbase Buckets, Scopes y Collections ahora proporcionan una jerarquía de contención de tres niveles para ayudarte a mapear tus aplicaciones, tenants y microservicios.
Funciones clave para la consolidación de multitenencia y microservicios
Vamos a sumergirnos en las capacidades ofrecidas por Scopes y Collections que hacen posible consolidar tenants y microservicios.
Aislamiento lógico e indexación
Las colecciones le permiten aislar sus datos por tipo mientras disfruta de la flexibilidad de un modelo de base de datos de documentos JSON que evoluciona con su aplicación.
Como se muestra en el ejemplo anterior, los documentos de la línea aérea van a la colección de líneas aéreas, los documentos del hotel van a la colección de hoteles, etc.
Cada colección también puede indexarse individualmente. Los distintos tipos de documentos suelen tener necesidades de indexación diferentes, y las Colecciones permiten definir índices distintos para cada tipo.
Gestión del ciclo de vida a múltiples niveles
Los ámbitos y las colecciones le permiten gestionar y supervisar sus datos en dos nuevos niveles, además del nivel de cubo existente.
La funcionalidad proporcionada incluye:
-
- Crear y soltar colecciones o ámbitos individuales
- Establecer la caducidad (tiempo máximo de vida, también conocido como Máx. TTL) a nivel de colección
- Supervise las estadísticas a nivel de Alcance y Colección. Aunque sólo se dispone de un conjunto completo de estadísticas a nivel de Cubo, se dispone de un subconjunto de estadísticas a nivel de Colección y Ámbito (por ejemplo, recuento de elementos, memoria utilizada, espacio en disco utilizado, operaciones por segundo).
Control de acceso detallado con RBAC
Uno de los aspectos más poderosos de Scopes y Collections es la capacidad de controlar la seguridad en múltiples niveles - Bucket, Scope, Collection - usando control de acceso basado en roles (RBAC). Esta es la clave para consolidar cientos de microservicios y/o inquilinos en un único clúster de Couchbase.
Ahora puede dar acceso a un usuario a todo un cubo, a un ámbito o a una colección. Hay varios roles de usuario disponibles, y más detalles en la documentación de RBAC).
Control detallado de la replicación con XDCR
Cross Data Center Replication (XDCR) permite controlar la replicación a nivel de Bucket, Scope o Collection.
Puede elegir replicar un Bucket completo, un Scope o sólo una Collection. Puedes mapear a una entidad de nombre similar en el destino o remapear a una entidad diferente. También tienes la flexibilidad del filtrado avanzado, que ya se introdujo para XDCR en la versión 6.5 de Couchbase.
La flexibilidad que proporciona XDCR es crucial para asignar microservicios y/o tenants a Colecciones y Ámbitos, ya que permite controlar cada microservicio y tenant individualmente.
Copia de seguridad/restauración a varios niveles
Continuando con el tema de la gestión del ciclo de vida en múltiples niveles, Couchbase 7.0 permite controlar las opciones de copia de seguridad y restauración también en cada uno de estos niveles.
Por lo tanto, puede realizar copias de seguridad (y restaurarlas) de un solo Bucket, Scope o Collection, además de filtrar los datos y reasignarlos durante la restauración.
Esté atento a los blogs más detallados sobre cada uno de estos temas (RBAC, XDCR y copia de seguridad/restauración) en las próximas semanas.
Despliegue de microservicios mediante colecciones
Un típico arquitectura de microservicios recomienda que cada microservicio sea sencillo (lo ideal es que tenga una sola función), esté débilmente acoplado a otros microservicios (lo que significa que tenga su propio almacén de datos) y escale de forma independiente.
Antes de Servidor Couchbase 7.0, podría alojar cada microservicio en un clúster independiente o en un Bucket independiente. Estas opciones de despliegue tienen límites inherentes en la densidad de la aplicación y puede que no siempre resulten en una utilización completa del hardware. Ahora con Couchbase 7.0, puedes mapear cada microservicio a una o más Colecciones. Y como puedes tener hasta mil Colecciones, puedes tener mil microservicios en un solo cluster(!).
Veamos el ejemplo de despliegue de microservicios que se muestra a continuación:
Consolidación de microservicios usando Couchbase Scopes y Collections
El ejemplo anterior muestra dos aplicaciones CRM (Ventas y Clientes) desplegadas en un único cluster. Cada una de las dos aplicaciones está asignada a un Bucket, lo que permite controlar la asignación global de recursos a cada aplicación.
La aplicación Ventas tiene dos microservicios: Pedidos y Envíos, y la aplicación Clientes tiene dos microservicios: Individuos y Cuentas. Asignamos cada uno de los microservicios a su propia Collection. En este ejemplo, no utilizamos Scopes. No es necesario definir ámbitos si no se necesita un nivel adicional de organización (en su lugar se utiliza el ámbito por defecto).
Despliegue multiusuario mediante ámbitos
Las aplicaciones multiarrendatario requieren distintos niveles de aislamiento entre los arrendatarios y distintos niveles de compartición de recursos de la infraestructura subyacente. La arquitectura de despliegue elegida es un compromiso entre el aislamiento y el coste total de propiedad (TCO).
Algunos inquilinos pueden requerir un aislamiento físico completo, en cuyo caso clusters separados para cada inquilino pueden ser la arquitectura correcta, aunque con un alto TCO. Los Buckets de Couchbase proporcionan un aislamiento físico parcial y un aislamiento lógico y de seguridad total, y pueden utilizarse para inquilinos separados, aunque con límites de escala y de sobrecarga por Bucket.
El aislamiento lógico y de seguridad entre inquilinos suele ser suficiente. Con los ámbitos, se obtiene seguridad y aislamiento lógico a niveles más granulares dentro de un bucket. Puede tener miles de ámbitos en un único bucket, lo que le permite alojar miles de inquilinos cooperativos (aquellos que no requieren aislamiento físico) en un único clúster.
Las compensaciones entre el coste total de propiedad y los niveles de aislamiento entre las distintas arquitecturas multiarrendamiento se recogen en la siguiente tabla.
Opciones de arquitectura multi-tenant usando Couchbase Scopes y Collections
Imagine que las aplicaciones CRM del ejemplo anterior necesitan convertirse en multi-tenant. Puede hacerlo fácilmente asignando cada inquilino a un ámbito independiente, como se muestra a continuación. (Cust1 y Cust2 son los dos inquilinos diferentes en este ejemplo).
Multi-tenancy con Scopes en Couchbase
Conseguir multi-tenancy con Scopes es bastante sencillo (sin requerir cambios en la aplicación, ya que se puede pasar un contexto Scope de un lado a otro). También es una solución escalable y rentable. Los nombres de las colecciones sólo deben ser únicos dentro de un ámbito. Por lo tanto, puede implementar fácilmente varios ámbitos con los mismos nombres de colecciones, como se muestra más arriba.
Próximos pasos
Espero que disfrutes de la nueva funcionalidad de Scopes y Collections en Couchbase. Abajo hay una lista de recursos para que empieces y esperamos tus comentarios sobre la nueva funcionalidad. Foros de Couchbase.
Documentación y artículos
Gran artículo.. pero me pregunto ¿cuándo estará listo el operador Couchbase para kubernetes para probarlo?
@Shivani, ¿El número de ámbitos está limitado a nivel de cluster o a nivel de bucket? Del mismo modo para la colección, es el número limitado a nivel de alcance o el nivel de clúster.
Si es a nivel de clúster, depende de la aplicación mantener cómo asignar colecciones y ámbitos en un clúster dado, lo que no me parece correcto.
Por favor, confírmelo.
El número máximo de ámbitos y de colecciones es a nivel de clúster. Así, si tienes 2 ámbitos en un cubo y cada ámbito tiene 500 colecciones, habrás alcanzado el límite con un total de 1000 colecciones en el clúster.
La estrategia de despliegue (ya sea para una sola aplicación o para microservicios y/o aplicaciones SaaS) debe tener en cuenta estos límites. Por supuesto, los microservicios y/o los inquilinos pueden dividirse en varios clústeres.
Gracias Shivani por este y el otro artículo sobre cómo emigrar. Es muy útil.
Documentos (https://docs.couchbase.com/server/current/developer-preview/collections/collections-overview.html) dicen que el límite es de 1000 colecciones por cubo. Puede usted pls comprobar y si eso es cierto, entonces conseguir esto y el artículo corregido?
Saludos
Me alegro de que los artículos te hayan resultado útiles. La página de documentación indica incorrectamente que el límite es de "1000 por cubo". En realidad son 1000 colecciones por clúster. Corregiremos la documentación, ¡gracias por señalarlo!
Me alegro de que los artículos te hayan resultado útiles. La página de documentación indica incorrectamente que el límite es de "1000 por cubo". En realidad son 1000 colecciones por clúster. Corregiremos la documentación, ¡gracias por señalarlo!
[...] entre los aspectos más destacados de Couchbase 7.0 se incluyen la mejora de la compatibilidad con el procesamiento de transacciones ACID, la incorporación de una nueva construcción Scopes para añadir un aspecto relacional a la base de datos de documentos, y varios [...]
[...] entre los aspectos más destacados de Couchbase 7.0 se incluyen la mejora de la compatibilidad con el procesamiento de transacciones ACID, la incorporación de una nueva construcción Scopes para añadir un aspecto relacional a la base de datos de documentos, y varios [...]
De este artículo, entiendo que con el uso de Bucket, Scope y Collections, se puede aumentar el número de microservicios de diferentes dominios.
Pero el artículo comenzaba con el aislamiento lógico, ¿significa que Couchbase 7.0 o versiones anteriores soportan el aislamiento para otros servicios de Couchbase (especialmente el servicio de índice)?
Lo que quiero decir es que, digamos que todos los dominios de una empresa determinada empiezan a utilizar un único clúster Couchbase, ¿puedo controlar y asignar los recursos del servicio de índice y los servicios de datos a nivel de bucket?
Los servicios de Couchbase como el servicio de índices y el servicio de datos (a través de buckets) siempre han permitido el aislamiento de recursos, por ejemplo, como mencionas, puedes controlar los recursos para el servicio de índices por separado del servicio de datos. Este sigue siendo el caso y no cambia con 7.0.
Con 7.0, lo que se obtiene son dos niveles adicionales dentro de un bucket llamados ámbitos y colecciones. Estos proporcionan aislamiento lógico y de seguridad, pero no aislamiento de recursos, ya que comparten los recursos asignados al bucket. Como se ha mencionado, para muchos microservicios esto es suficiente y, por tanto, pueden asignarse a colecciones en lugar de utilizar un bucket distinto para cada microservicio.
Podría tener un clúster de 100 o 1000 nodos, así que ¿cómo se explica la restricción de 30 cubos o una colección de 1000? ¿El límite es por nodo couchbase o por cluster? ¿Alguien puede explicarlo?
Tienes razón, los límites son los mismos tanto si el clúster tiene 100 nodos como 1000 nodos. Como usted está insinuando, sí hay recursos utilizados en cada nodo para cada colección y / o cubo. Es por eso que el límite realmente viene de lo que podemos manejar a nivel de nodo. Lo que cada nodo puede manejar determina lo que el cluster puede manejar ya que cada nodo en el cluster tiene que mantener todos los buckets y colecciones - Couchbase distribuye todo uniformemente a través de todos los nodos.
Hola Shivani,
Gracias por su artículo.
Estoy trabajando en una función para convertir una aplicación en una aplicación multi-tenant. Todo el sistema tiene un backend en Spring Boot 2.5.5 y una aplicación móvil. La base de datos es Couchbase 6.6.
Con Couchbase 7.0, los ámbitos y las colecciones parecen ser la respuesta a muchas de mis preguntas pero (siempre hay un pero... :)), Spring Data Couchbase 4.2.5 no es compatible con ámbitos o colecciones con nombre, ni tampoco SyncGateway 2.8 o 3.0 (https://docs.couchbase.com/sync-gateway/3.0/server-compatibility-collections.html#using-collections)
¿Sabe cuándo se lanzará Spring Data Couchbase 4.3.0 (la versión 4.3.0-M3 parece funcionar)?
¿Sabe cuándo se lanzará un Syncgateway compatible con ámbitos o colecciones con nombre?
Saludos,
Matthieu
Hola,
¿Cuántos ámbitos puedo crear para un cubo?