Eventos sencillos pero potentes:
Eventos permite a los pequeños guiones superar problemas difíciles de resolver.
Si está familiarizado tanto con Couchbase como con Eventing, no dude en omitir la breve descripción general y pasar a la parte siguiente. ejemplos.
Visión general:
En primer lugar, veamos lo básico Ciclo de vida de los eventos.
Los siguientes pasos muestran lo fácil que es escribir y utilizar una función de eventos
- Añade (o importa) una función de eventos a través de la interfaz de usuario de Couchbase Server.
- Asigne una fuente de datos, un cubo de bloc de notas y algunos enlaces para manipular documentos o comunicarse con el mundo exterior.
- Implementar algún código JavaScript para procesar la mutación recibida.
- Guarde su nueva función y pulse "Desplegar".
Eso es todo, ahora tiene una función distribuida que responde a las mutaciones en su conjunto de datos en tiempo real en todo su clúster.
El servicio de Eventing proporciona una plataforma sin infraestructura que puede escalar sus funciones de Eventing a medida que su negocio experimenta un crecimiento, ya sea un pico de una sola vez o un aumento mensual en los almacenes de datos o clientes atendidos sin preocuparse por el hecho de que sus funciones de Eventing basadas en JavaScript se están ejecutando de una manera robusta, fiable y distribuida en paralelo. Para obtener más información sobre Couchbase Eventing, consulte la página Concurso completo en nuestra documentación.
Los ejemplos de este artículo muestran que en algunos casos Eventing puede actuar como una gota de aceite para "liberar" las partes móviles de sus aplicaciones.
Couchbase una base de datos que se construye por encargo:
Me gusta pensar en un clúster de Couchbase como un conjunto de "microservicios" escalables e interoperables. Estos servicios pueden conectarse entre sí y dimensionarse para satisfacer un conjunto específico de necesidades operativas y empresariales.
Couchbase proporciona escalado multidimensional, o MDS, a través de seis servicios clave con una interferencia mínima de recursos entre ellos. Además, cada servicio de Couchbase es escalable de forma independiente, simplemente añadiendo más nodos. Esto permite a los clientes crear el clúster multinodo ideal con el menor coste total de propiedad posible para la tarea o tareas en cuestión.
- Los nodos de datos se escalan fácilmente para proporcionar operaciones KV conscientes de JSON a escala para búsquedas de uno o varios registros es extremadamente rápido. ¿Acabo de mencionar que "para búsquedas de uno o varios registros es extremadamente rápido"Sí, lo hice, pero realmente quiero hacer hincapié en esto.
- Los nodos de consulta se escalan fácilmente para proporcionar índices y también N1QL, una mejora de SQL que funciona de forma nativa con documentos JSON, que permite a los programadores ponerse en marcha rápidamente sin tener que aprender una nueva forma de pensar.
- Los nodos de índice se escalan fácilmente para proporcionar índices flexibles que aceleren algunas o todas las consultas N1QL.
- Los nodos de búsqueda se amplían fácilmente para ofrecer búsquedas de texto completo en lenguaje natural con: búsqueda en función del idioma, puntuación de los resultados e índices rápidos basados en FTS,
- El nodo Analytics se escala fácilmente a la capacidad de gestión paralela de datos para ejecutar de forma eficiente consultas complejas: grandes operaciones ad hoc de join, set, agregación y agrupación en grandes conjuntos de datos.
- El servicio Eventing se escala fácilmente para proporcionar un paradigma informático que los desarrolladores pueden utilizar para gestionar los cambios (o mutaciones) de datos y reaccionar ante ellos en tiempo real.
Como todas las líneas de productos, los nuevos servicios de Couchbase Query, Search, Eventing y Analytics tienen algunos defectos, pero en conjunto, la cesta completa proporciona una suite unificada, o una ventanilla única para resolver un sinfín de problemas. En serio, si no te importa un producto unificado y todo lo que vas a hacer es usar FTS, podrías considerar usar Elasticsearch, pero una vez que necesites integrar tus resultados de FTS con N1QL (SQL para JSON), podrías haber empezado mucho mejor con Couchbase.
Hoy vamos a utilizar sólo dos servicios 1) el servicio primario de KV proporcionado por los nodos de datos 2) el servicio de eventos. Voy a destacar a través de unas pequeñas funciones de JavaScript cómo se puede superar algunos problemas difíciles a escala aprovechando el servicio de eventos.
Requisitos previos / Aprendizaje del concurso completo:
En este artículo vamos a utilizar la última versión de GA, es decir, Couchbase versión 6.5.1
Sin embargo, si usted no está familiarizado con Couchbase o el servicio Eventing por favor camine a través de GET STARTED y un ejemplo Eventing específicamente se refieren a los siguientes:
- Configure un servidor Couchbase 6.5.1 que funcione según las instrucciones de Comience aquí
- Comprender cómo desplegar una función básica de Eventing según las instrucciones de la sección Enriquecimiento de datos ejemplo específicamente "Caso 2" donde sólo utilizaremos un cubo el cubo 'fuente'.
Enriquecimiento de datos mediante eventos:
Un problema típico de un cliente
Un sistema de producción en vivo ha almacenado miles de millones de documentos. Ha surgido una nueva necesidad empresarial que exige enriquecer los datos existentes. Esta necesidad de datos adicionales afecta a todo el conjunto de documentos. El impacto operativo abarca tanto los datos antiguos o históricos como los nuevos o mutantes. La empresa necesita mantener el sistema de producción en funcionamiento ininterrumpido y responder continuamente a los nuevos datos en tiempo real.
Consideremos un ejemplo de aplicación un tanto artificioso: un servicio de búsqueda GeoIP. Esta utilidad necesita un conjunto de datos que permita buscar países por rangos de direcciones IPV4. La implementación inicial almacenaba los registros de la siguiente manera:
|
1 2 3 4 5 6 |
{ "tipo": "mapa_país_ip", "país": "RU", "ip_start": "7.12.60.1", "ip_end": "7.62.60.9" } |
Meses o más tarde cambian los nuevos requisitos empresariales. Ingeniería necesitaba enriquecer los documentos JSON con nuevos campos. El requisito era incluir las representaciones numéricas de las dos direcciones IPV4 existentes.
|
1 2 3 4 5 6 7 8 |
{ "tipo": "mapa_país_ip", "país": "RU", "ip_end": "7.62.60.9", "ip_start": "7.12.60.1", "ip_num_start": 118242305, "ip_num_end": 121519113 } |
Eventing al rescate
Una simple función de eventos de catorce (14) líneas JavaScript (2 de las cuales son comentarios) puede escribirse e implementarse para resolver el problema con recursos mínimos.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
función OnUpdate(doc, meta) { si (doc.tipo !== "mapa_país_ip" ) devolver; doc["ip_num_start"] = get_numip_first_3_octets(doc["ip_start"]); doc["ip_num_end"] = get_numip_first_3_octets(doc["ip_end"]); // src es un alias del cubo de origen en la configuración, escribe en él src[meta.id]=doc; } función get_numip_first_3_octets(ip) { si (!ip) devolver 0; var piezas = ip.dividir('.'); // Número IP = A x (256*256*256) + B x (256*256) + C x 256 + D devolver = (piezas[0]*(256*256*256)) + (piezas[1]*(256*256)) + (piezas[2]*256) + parseInt(piezas[3]); } |
Al desplegar la función anterior con un "límite de alimentación" establecido en "Todo", todos los documentos de tipo "ip_country_map" son procesados y enriquecidos.
La función de eventos se deja "desplegada" reaccionando a todas las nuevas inserciones o actualizaciones (o mutaciones) en tiempo real enriqueciendo los nuevos elementos y también actualizando los elementos existentes en los cambios de "ip_start_num" o "ip_end_num" a las representaciones "numéricas" adecuadas.
Como los documentos están enriquecidos (los campos antiguos siguen presentes), las aplicaciones de producción existentes seguirán funcionando. Todos los datos nuevos o modificados se actualizan en tiempo real al nuevo esquema. Los componentes de la aplicación GeoIP se desacoplan a través de esta sencilla función de eventos, de modo que pueden actualizarse de uno en uno.
Cuando todos los componentes de producción han sido actualizados, la función de eventos puede ser desinstalada y dada de baja.
Purga de datos obsoletos mediante eventos:
Un problema típico de un cliente
Un sistema de producción en vivo ha almacenado más de 7.000 millones de documentos. Todos los documentos tienen una caducidad automática (o TTL para el tiempo de vida). El entorno de producción recibe constantemente datos nuevos y expira constantemente datos antiguos.
Se cometió un error operativo que provocó la creación de 2.000 millones de documentos sin fecha de caducidad.
El cliente no tenía los recursos (ni deseaba pagar por los recursos) para crear un gran índice para utilizar N1QL para identificar seleccionar y purgar los datos que carecían de un TTL activo (distinto de cero) cuando ya no eran útiles.
Eventing al rescate
Una simple función de eventos de seis (6) líneas JavaScript (2 de las cuales son comentarios) se implementó y resolvió el problema con recursos mínimos.
|
1 2 3 4 5 6 |
función OnUpdate(doc, meta) { si (meta.caducidad !== 0) devolver; // eliminar todos los elementos que tienen TTL o caducidad de 0 // src es un alias de cubo para el cubo de origen en la configuración, eliminar de ella. borrar src[meta.id]; } |
Al desplegar la función anterior con un "Límite de alimentación" establecido en "Todo", se escaneó todo el conjunto de documentos del bucket de origen. Todos los documentos con un TTL distinto de cero (lo que significa que no tenían caducidad) fueron ignorados. Sólo se eliminan los documentos coincidentes con un TTL superior a cero.
Una vez limpiado el bucket de origen, se desinstaló la función de eventos, ya que se utilizaba como herramienta administrativa.
Tenga en cuenta que podríamos reemplazar la prueba de expiración !== 0 en nuestro JavaScript para filtrar los datos para cualquier propósito necesario.
Es bastante fácil adivinar lo que estamos haciendo a continuación:
|
1 2 3 4 5 6 |
función OnUpdate(doc, meta) { si (!(doc.tipo === "cliente"&& doc.activo === falso)) devolver // archivar el cliente en el bucket aias arc y eliminar del bucket alias src arco[meta.id] = doc; borrar src[meta.id]; } |
De hecho, podríamos actualizar fácilmente lo anterior para realizar un archivo en cascada y eliminar no sólo del cliente sino de cualquier otra información relacionada como pedidos, devoluciones y direcciones de envío. Consulte el ejemplo Cascada Suprimir en la documentación de Eventing.
Eliminación de datos sensibles mediante Eventing:
Un problema típico de un cliente
Una empresa que ejecuta Couchbase on-premises en producción necesitaba compartir información de perfiles de clientes (150M y creciendo). Su socio comercial también ejecuta Couchbase, pero en un proveedor en la nube, AWS.
Dado un registro de perfil típico como el siguiente:
|
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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
{ "tipo": "perfil_maestro", "nombre": "Peter", "apellido": "Chang", "id": 80927079070, "perfil_básico": { "partner_id": 80980221, "servicios": [ { "música": verdadero }, { "radio": verdadero }, { "video": falso } ] }, "perfil_sensible": { "ssn": "111-11-1111", "tarjeta_crédito": { "número": "3333-333-3333-3333", "caduca": "01/09", "ccv": "111" } }, "dirección": { "home": { "calle": "4032 Kenwood Drive", "ciudad": "Boston", "zip": "02102" }, "facturación": { "calle": "Calle Bronx 541", "ciudad": "Boston", "zip": "02102" } }, "teléfono": { "home": "800-555-9201", "trabajo": "877-123-8811", "celda": "878-234-8171" }, "locale": "en_US", "zona horaria": -7, "género": "M" } |
No podían compartir todo el perfil, ya que contenía datos sensibles sobre las preferencias de los usuarios y los métodos de pago. Solo necesitaban compartir un subconjunto limitado como el siguiente:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "tipo": "perfil_compartido", "nombre": "Peter", "id": 80927079070, "perfil_básico": { "partner_id": 80980221, "servicios": [ { "música": verdadero }, { "radio": verdadero }, { "video": falso } ] }, "zona horaria": -7 } |
El cliente quería sustituir la solución SPARK de desgaste intermedio, que requería horas en caso de fallo para inicializarse y sólo ofrecía un lento proceso por lotes (horas para reflejar las actualizaciones) y sincronizar la información del perfil en tiempo real.
Eventing al rescate
Una simple función de eventos de nueve (9) líneas JavaScript (3 de las cuales son comentarios) fue desplegada y resolvió el problema con recursos mínimos.
|
1 2 3 4 5 6 7 8 9 |
función OnUpdate(doc, meta) { // procesar sólo nuestros documentos de perfil si (doc.tipo !== "perfil_maestro") devolver; // aws_bkt es un alias del bucket de destino para replicar a AWS a través de // XCDR. Escribe el documento de perfil mínimo (no sensible) en el bucket para AWS. aws_bkt["perfil_compartido::"+doc.id] = { "tipo": "perfil_compartido", "nombre": doc.nombre, "id": doc.id, "perfil_básico": doc.perfil_básico, "zona horaria": doc.zona horaria }; } |
Al desplegar la Función anterior con un "Límite de alimentación" establecido en "Todo", se escaneó todo el conjunto de documentos del bucket de origen y se procesaron todos los documentos de tipo: "master_profile" y sólo se copió en el bucket de destino compartido un subdocumento de cada perfil sin la información sensible.
La función de eventos siempre se deja desplegada reaccionando a todos los cambios (o mutaciones) de perfil de usuario en tiempo real y reenviando todas y cada una de las mutaciones al bucket de destino de AWS.
En este caso de uso se realiza una sincronización final de cubo a cubo a través de Couchbase XCDR Los datos confidenciales no salen en ningún momento del clúster local y nunca se transmiten a AWS.
Recursos
- Descargar: Descargar Couchbase Server 6.5.1
Referencias
- Documentación de Couchbase Eventing:
https://docs.couchbase.com/server/current/eventing/eventing-overview.html - Couchbase Server 6.5 Novedades:
https://docs.couchbase.com/server/6.5/introduction/whats-new.html - Blogs de Couchbase sobre Eventing:
https://www.couchbase.com/blog/tag/eventing/
