La validación de datos es un tema interesante para una tecnología NoSQL, ya que los principios básicos del sistema giran en torno a una arquitectura "sin esquemas". Durante muchos años, SQL y los esquemas han controlado los datos de las aplicaciones, garantizando la conformidad de la información dentro de la base de datos. Estas restricciones impedían la modernización de la mayoría de las aplicaciones al ralentizar el tiempo de desarrollo.
En cualquier caso, sigue siendo necesario gobernar y validar la información subyacente a las aplicaciones. Teniendo esto en cuenta, ¿cómo lo conseguimos con Couchbase?
La flexibilidad de una arquitectura sin esquemas hace más difícil imponer la estructura de la información procedente de múltiples fuentes, como la interacción entre sensores y dispositivos de borde, donde el número de puntos de comunicación es enorme. Hay formas de lograr validación de datos en la propia base de datosutilizando el servicio Couchbase Eventing. El servicio, por sí solo, es extremadamente potente y flexible, dando al administrador el control sobre los detalles de la validación en los documentos y las acciones resultantes a tomar.
La entrada del blog le guiará por un ejemplo de uso del servicio de eventos para validar la información que vive en su clúster. Como verás, hay muchas maneras diferentes de construir esto, pero vamos a centrarnos en una para empezar.
Fundamentos de NoSQL
En el centro de cualquier base de datos están los datos: la información real que deseamos almacenar. Antes de adoptar NoSQL, introducíamos los datos en nuestro sistema, pero tenían que ajustarse a la estructura definida por los desarrolladores o los DBA. Los DBA dedicaban tiempo a normalizando la información hasta la 6ª forma normal para reducir la redundancia de datos. Toda esta estructura se conocía comúnmente como esquema y era estupenda para validar la integridad de la información, garantizar la calidad del sistema de registros y convertirse en fuente de verdad.
A pesar de las ventajas, la arquitectura basada en esquemas presentaba algunos inconvenientes, introducidos principalmente cuando las aplicaciones empezaron a funcionar a un nivel superior y las empresas empezaron a innovar con mayor rapidez. El enfoque estructurado para almacenar datos empezó a ralentizar el desarrollo, y los cambios de esquema se convirtieron en una molestia.
Aquí es donde empezó a primar el enfoque de los esquemas, que permite a los usuarios almacenar cualquier información que deseen y favorece la aceleración del desarrollo innovador.
SQL pero NoSQL
A pesar del cambio a una base de datos más flexible y ágil, algunos atributos del viejo modelo se desean con el nuevo enfoque; la Validación de Datos es uno de esos temas. Couchbase ha introducido cambios considerables en las últimas versiones para tender un puente entre las tecnologías SQL y NoSQL.
Ámbitos y colecciones lanzado en Couchbase Server 7.0 y abrió la puerta a una mayor organización lógica y casos de uso multi-tenancy. Nos permitió mapear datos de esquema a esquema sin dejar de mantener las prácticas de desarrollo flexible en el núcleo.
Garantías ACID de un sistema distribuido fue otro gran paso, garantizando la semántica de todo o nada a través de datos no relacionados para cargas de trabajo transaccionales ya en la v6.5.1.
Validación de datos es otro tema que aparece junto a estos. ¿Cómo evalúo la información de mi base de datos cuando no hay un esquema que lo imponga? Al igual que las características anteriores que complementaban el enfoque del esquema, la posibilidad de elegir si se dispone de él o no es beneficiosa. Aunque no es necesario incorporarlo a los fundamentos de la propia aplicación.
Con la proliferación de la red 5G y los dispositivos Mobile/Edge, lo más probable es que el requisito de gobernanza y gestión de datos siga ahí. Utilizar herramientas del arsenal de Couchbase puede proporcionarte un método fácil y totalmente controlado para aplicar esta validación sin afectar al rendimiento ni de la aplicación ni de los nodos de la base de datos.
Edge Computing con múltiples fuentes de aplicaciones
Antes de sumergirnos en las divertidas formas de validar en el servidor, hablemos de la otra opción disponible. La validación a nivel de aplicación será probablemente el primer pensamiento que nos venga a la mente. Si queremos asegurarnos de que la información es adecuada para ser almacenada, ¿por qué no la comprobamos antes de insertar los documentos en la base de datos? Aplicar la lógica de la aplicación a los datos antes de que el sistema los ingiera garantizaría que ningún documento se acerque a la base de datos a menos que el sistema ya lo haya validado.
En teoría, parece una buena idea: .... para una única aplicación que hable con un único conjunto de datos. Sin embargo, cuando se empieza a considerar el espacio de las aplicaciones móviles, donde podríamos estar hablando con varios dispositivos de borde, todos hablando con múltiples conjuntos de datos, en una sola base de datos, la capacidad de mantenimiento se verá afectada. Todos los equipos que escriban en la base de datos tendrán que mantener y compartir la lógica de validación de forma coherente, y se empezarán a perder las garantías que existían en el caso de una única aplicación.
Servicio de concursos
Teniendo en cuenta los problemas de validación de la aplicación, necesitamos una forma de conseguir el mismo resultado pero en un punto diferente; aquí es donde entra en juego el servicio eventing. Para aquellos que no lo conozcan, el servicio de eventos permite actuar sobre mutaciones de datos en la base de datos mediante programación. Estas acciones se definen dentro de los controladores de eventos de JavaScript y se activan en cualquier actualización o eliminación de los datos.
| función OnUpdate(doc, meta) { log(docIdmeta.id); } función OnDelete(meta, opciones) { } |
Dado que el servicio de eventing puede ejecutar esta lógica después de que los datos hayan llegado a la base de datos, nada nos impide incorporar la lógica de la aplicación a estas funciones. Pasaremos la responsabilidad al servicio de eventing para que compruebe la información cada vez que se inserte o modifique.
Esto hace dos cosas:
- Elimina la duplicación de la lógica de validación en varias aplicaciones.
- Centralización de la configuración y mantenimiento de lo que se consideran datos "válidos".
Ahora podemos utilizar el servicio eventing para comprobar los campos y valores de los documentos dentro de un bucket, independientemente de la procedencia de los datos. Pero todavía hay una consideración, ¿qué hacemos con los documentos si decidimos que son inválido? A nivel de la aplicación, un documento no válido no pasaría las comprobaciones y arrojaría un error o excepción que se le comunicaría, y que usted podría gestionar de la forma que fuera necesaria.
Como la información ya está en el cubo, tenemos que marcar la validez del documento sin empañar la integridad de los datos. Depende de ti cómo decidas manejar esta parte, pero en mi ejemplo, podemos mantener un registro de los documentos no válidos en una colección separada, y podemos eliminar el registro cuando se haya limpiado a un estado válido.
Aplicación
En primer lugar, tenemos que crear una función eventing en el conjunto de datos de destino. Para este ejemplo, he elegido la función Usuarios colección. También tendremos que especificar una ubicación para almacenar los metadatos de eventing (véase la sección Documentación sobre eventos).
Por último, tendré que definir un alias para la ubicación de los datos no válidos, al que pueda hacer referencia; para ello, tenemos el comando Usuarios_Invalidos colección.
Una vez creada la estructura, necesitamos crear algo que represente un válido documento. De este modo, podemos cotejar todos los documentos nuevos con éste para garantizar que la información es correcta. En este caso, crearé un documento que enumere todos los campos obligatorios y los tipos que deben contener. Si lo desea, puede correlacionar esto con el esquema que hemos discutido antes, por lo tanto, voy a llamar a esto el Esquema_Usuarios.
| { "fields": [ { "Nombre": "Nombre", "tipo": "cadena" }, { "Nombre": "Edad", "tipo": "número" }, { "Nombre": "Abonado", "tipo": "booleano" } ] } |
Lo siguiente que hay que crear es la lógica de validación. Eventing ejecutará la lógica cada vez que haya una mutación de documento en la colección de origen, Usuarios. Comprobará si el documento tiene asociado un documento de esquema relacionado. En caso afirmativo, comprobará todos los tipos de campo y valor y los comparará con el documento al que se hace referencia. Si alguno de los campos no existe, o alguno de los tipos no coincide con lo esperado, entonces creamos un registro en el directorio Usuarios_invalidos colección.
Hay una condición al final del script que intenta eliminar el registro si la lógica devuelve un resultado válido. Se elimina de los registros no válidos cuando el documento se ha limpiado o fijado en un estado válido.
| función OnUpdate(doc, meta) { log(docIdmeta.id); var esquema, válido, motivo //Coger el documento del esquema esquema = inv[doc.tipo + '_schema'] razón = ” válido = verdadero //Iterar por los campos para(const campo de schema.fields) { //Comprobar si el campo existe si (nombre.campo en doc) { //Comprobar si el tipo de campo es correcto si (tipode doc[field.name] == field.type) { válido = verdadero } si no { razón = Tipo incorrecto de campo: ' + field.name + '. Esperado: ' + field.type + '. Actual: ' + tipode doc[nombre.campo] válido = falso romper } } si no { razón = 'Campo: ' + field.name + no existe válido = falso romper } } si (válido == verdadero){ borrar inv[meta.id] } si no { var docContenido = { "id": meta.id, "razón": razón } inv[meta.id] = docContenido } } |
Todo lo que hay que hacer ahora es probarlo, insertar un Usuario documento con campos/tipos no válidos y comprobar que se crea un registro en el Usuarios_invalidos colección". Intente corregir los documentos no válidos y compruebe que se elimina el registro. En general, esto le permite lograr la validación asíncrona de datos después del punto de guardado, en 3 sencillos pasos.
Yendo más allá...
Ahora, como usted probablemente puede decir, este es un ejemplo muy simple, y no tengo ninguna duda de que podría haber escrito JavaScript de manera más eficiente. Sin embargo, todavía era capaz de validar toda la información dentro de un cubo contra lo que podríamos llamar un esquema, manteniendo la integridad de la información y asegurando que no había datos perdidos en el proceso.
Este enfoque era el que yo quería seguir, pero podría modificarse y ampliarse de varias formas distintas...
- Validación de los valores reales de los campos (por ejemplo, la edad debe estar comprendida entre 1 y 100, etc.)
- Eliminar los documentos por completo de la colección
- Mover todo el documento fuera de la colección
- Envío de notificaciones a través de cURL a un servicio externo (¿Respuesta por correo electrónico quizás?)
- Escribir lógica adicional para corregir de forma autónoma los datos no válidos con enriquecimiento.
Esta entrada del blog ha demostrado un par de cosas:
- Validación asíncrona de datos tras el punto de guardado
- El poder del servicio de eventing en su conjunto
Volviendo a los puntos originales, tender puentes entre las tecnologías SQL y NoSQL es cada vez más habitual, no como cambios arquitectónicos, sino como herramientas para lograr lo que antes era una implementación fundamental.
