sql >> Base de Datos >  >> NoSQL >> MongoDB

Novedades en MongoDB 4.2

Las actualizaciones de la base de datos vienen con funciones mejoradas para el rendimiento, la seguridad y con nuevas funciones integradas. Siempre es recomendable probar una nueva versión antes de implementarla en producción, solo para asegurarse de que se adapte a sus necesidades y no haya posibilidad de fallas.

Considerando muchos productos, aquellos que preceden a las primeras versiones secundarias de una nueva versión principal tienen las correcciones más importantes. Por ejemplo, preferiría tener la versión 4.2.1 de MongoDB en producción unos días después del lanzamiento que la versión 4.2.0.

En este blog vamos a discutir lo que se ha incluido y qué mejoras se han realizado en la versión 4.2 de MongoDB

Novedades de MongoDB 4.2

  1. Transacciones distribuidas
  2. Índices comodín
  3. Lecturas y escrituras reintentables
  4. Cifrado automático a nivel de campo del lado del cliente.
  5. Lenguaje de consulta mejorado para actualizaciones expresivas
  6. Vistas materializadas bajo demanda
  7. Operaciones de mantenimiento modernas

Transacciones distribuidas

Las transacciones son características importantes de la base de datos que aseguran la consistencia e integridad de los datos, especialmente aquellas que garantizan los procedimientos ACID. MongoDB versión 4.2 ahora admite transacciones de varios documentos en conjuntos de réplicas y un clúster fragmentado a través del enfoque de transacciones distribuidas. Se ha mantenido la misma sintaxis para el uso de transacciones que la versión anterior 4.0.

Sin embargo, las especificaciones del controlador del cliente han cambiado un poco, por lo tanto, si tiene la intención de utilizar transacciones en MongoDB 4.2, debe actualizar los controladores a versiones que sean compatibles con los servidores 4.2.

Esta versión no limita el tamaño de una transacción en términos de uso de memoria, sino que solo depende del tamaño de su hardware y la capacidad de manejo del hardware.

Ahora es posible reasignar la configuración regional global del clúster con la versión 4.2. Es decir, para una implementación de fragmentación de zonas geográficas, si un usuario que reside en la región A se muda a la región B, al cambiar el valor de su campo de ubicación, los datos se pueden mover automáticamente de la región A a la B a través de una transacción.

El sistema de fragmentación ahora permite cambiar una clave de fragmentación a diferencia de la versión anterior. Literalmente, cuando se cambia una clave de fragmento, es equivalente a mover el documento a otro fragmento. En esta versión, MongoDB envuelve esta actualización y si es necesario mover el documento de un fragmento a otro, la actualización se ejecutará dentro de una transacción en segundo plano.

El uso de transacciones no es un enfoque recomendable ya que degradan el rendimiento de la base de datos, especialmente si ocurren varias veces. Durante un período de transacción, hay una ventana extendida para operaciones que pueden causar conflictos al realizar escrituras en un documento afectado. Por mucho que se pueda reintentar una transacción, es posible que se realice una actualización en el documento antes de este reintento, y siempre que se produzca el reintento, es posible que se trate de la versión anterior del documento en lugar de la última. Los reintentos obviamente ejercen más costos de procesamiento además de aumentar el tiempo de inactividad de la aplicación a través de una latencia creciente.

Una buena práctica sobre el uso de transacciones incluye:

  1. Evite usar consultas no indexadas dentro de una transacción como una forma de garantizar que la operación no sea lenta.
  2. Su transacción debe incluir algunos documentos.

Con el formato de esquema dinámico de MongoDB y la función de incrustación, puede optar por poner todos los campos en la misma colección para evitar la necesidad de usar la transacción como primera medida.

Índices comodín

Los índices comodín se introdujeron en la versión 4.2 de MongoDB para mejorar las consultas en campos arbitrarios o campos cuyos nombres no se conocen de antemano, mediante la indexación de todo el documento o subdocumento. No pretenden reemplazar los índices basados ​​en la carga de trabajo pero conviene trabajar con datos que involucran un patrón polimórfico. Un patrón polimórfico es donde todos los documentos de una colección son similares pero no tienen una estructura idéntica. Los patrones de datos polimórficos se pueden generar a partir de aplicaciones, catálogos de productos o datos sociales. A continuación se muestra un ejemplo de datos de colección polimórfica

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

Al indexar todo el documento utilizando índices comodín, puede realizar una consulta utilizando cualquier campo arbitrario como índice.

Para crear un índice comodín

$db.collection.createIndex({“fieldA.$**”: 1})

Si el campo seleccionado es un documento anidado o una matriz, el índice comodín recurre al documento y almacena el valor de todos los campos en el documento o la matriz.

Lecturas y escrituras reintentables

Normalmente, una base de datos puede sufrir algunas interrupciones transitorias frecuentes de la red que pueden provocar que una consulta no se ejecute parcial o totalmente. Estos errores de red pueden no ser tan graves, por lo tanto, ofrecen la posibilidad de volver a intentar estas consultas una vez que se vuelva a conectar. A partir de MongoDB 4.2, la configuración de reintento está habilitada de forma predeterminada. Los controladores de MongoDB pueden volver a intentar lecturas y escrituras fallidas para ciertas transacciones cada vez que encuentren errores de red menores o, más bien, cuando no puedan encontrar algún primario en buen estado en el conjunto de réplicas/clúster fragmentado. Sin embargo, si no desea las escrituras reintentables, puede deshabilitarlas explícitamente en sus configuraciones, pero no encuentro una razón convincente por la que deba deshabilitarse.

Esta función es para garantizar que, en cualquier caso, los cambios en la infraestructura de MongoDB no afecten al código de la aplicación. Con respecto a un ejemplo explicado por Eliot Horowitz, el cofundador de MongoDB, para una página web que realiza 20 operaciones de base de datos diferentes, en lugar de recargar todo o tener que envolver toda la página web en algún tipo de bucle, el controlador debajo de las sábanas simplemente puede decidir volver a intentar la operación. Cada vez que falla una escritura, se volverá a intentar automáticamente y tendrá un contrato con el servidor para garantizar que cada escritura ocurra solo una vez.

Las escrituras reintentables solo realizan un único intento de reintento, lo que ayuda a abordar las elecciones de conjuntos de réplicas y los errores de red transitorios, pero no los errores de red persistentes.

Las escrituras que se pueden volver a intentar no abordan las instancias en las que el período de conmutación por error supera el valor de serverSelectionTimoutMs en las configuraciones de parámetros.

Con esta versión de MongoDB, se pueden actualizar los valores de la clave de fragmento del documento (excepto si la clave de fragmento es el campo _id inmutable) mediante la emisión de operaciones findAndModify/update de un solo documento, ya sea en una transacción o como escritura reintentable .

MongoDB versión 4.2 ahora puede volver a intentar una operación upsert de un solo documento (es decir, upsert:verdadero y múltiple:falso) que puede haber fallado debido a un error de clave duplicada si la operación cumple con estas condiciones clave:

  1. La colección de destino contiene un índice único que provocó el error de clave duplicada.
  2. La operación de actualización no modificará ninguno de los campos en el predicado de consulta.
  3. La condición de coincidencia de actualización es un predicado de igualdad único {campo:"valor"} o un AND lógico de predicados de igualdad {archivado:"valor", campo0:"valor0"}
  4. El conjunto de campos en el patrón de clave de índice único coincide con el conjunto de campos en el predicado de consulta de actualización.

Cifrado automático a nivel de campo del lado del cliente

MongoDB versión 4.2 viene con el cifrado automático de nivel de campo del lado del cliente (CSFLE), una función que permite a los desarrolladores cifrar de forma selectiva campos individuales de un documento en el lado del cliente antes de enviarlo al servidor. Por lo tanto, los datos cifrados se mantienen privados de los proveedores que alojan la base de datos y de cualquier usuario que pueda tener acceso directo a la base de datos.

Solo las aplicaciones con acceso a las claves de cifrado correctas pueden descifrar y leer los datos protegidos. En caso de que se elimine la clave de cifrado, todos los datos cifrados se volverán ilegibles.

Nota:esta función solo está disponible con MongoDB Enterprise.

Lenguaje de consulta mejorado para actualizaciones expresivas

MongoDB versión 4.2 proporciona un lenguaje de consulta más rico que sus predecesores. Ahora admite agregaciones y operaciones modernas de casos de uso en la línea de búsquedas basadas en geolocalización, búsqueda de gráficos y búsqueda de texto. Ha integrado un motor de búsqueda de terceros que hace que las búsquedas sean más rápidas teniendo en cuenta que el motor de búsqueda se ejecuta en un proceso/servidor diferente. Por lo general, esto mejora el rendimiento de la base de datos, al contrario que si todas las búsquedas se realizaran en el proceso mongod, lo que haría que la latencia de la operación de la base de datos fuera volátil cada vez que el motor de búsqueda vuelve a indexar.

Con esta versión, ahora puede manejar arreglos, hacer sumas y otras operaciones matemáticas directamente a través de una declaración de actualización.

Vistas materializadas bajo demanda

El marco de canalización de agregación de datos en MongoDB es una gran característica con diferentes etapas de transformación de un documento a algún estado deseado. La versión 4.2 de MongoDB presenta una nueva etapa $merge que, para mí, diré que me ahorró algo de tiempo trabajando con el resultado final que debía almacenarse en una colección. Inicialmente, la etapa $out permite crear una nueva colección basada en la agregación y llena la colección con los resultados obtenidos. Si la colección ya existe, sobrescribirá la colección con los nuevos resultados contrario a la etapa $merge que solo incorpora los resultados de la canalización en una salida existente en lugar de reemplazar completamente la colección. La regeneración de una colección completa cada vez con la etapa $out consume una gran cantidad de CPU e IO, lo que puede degradar el rendimiento de la base de datos. Por lo tanto, el contenido de salida se actualizará oportunamente, lo que permitirá a los usuarios crear vistas materializadas bajo demanda

Operaciones de mantenimiento modernas

Los desarrolladores ahora pueden tener una excelente experiencia operativa con MongoDB versión 4.2 con características integradas que mejoran la alta disponibilidad, la estrategia de copia de seguridad administrada en la nube, mejoran el poder de monitoreo y los sistemas de alerta. MongoDB Atlas y MongoDB Ops Manager son las plataformas que proporcionan estas funciones. Este último ha sido etiquetado como el mejor para ejecutar MongoDB en la empresa. También se integró con el operador de Kubernetes para usuarios locales que se mudan a la nube privada. Esta interfaz permite controlar directamente a Ops Manager.

Hay algunos cambios internos realizados en MongoDB versión 4.2 que incluyen:

  1. Lista de cursores abiertos.
  2. Eliminación del motor de almacenamiento MMAPv1.
  3. Mejora en la reparación del archivo de datos de WiredTiger.
  4. Los campos de diagnóstico ahora pueden tener queryHash
  5. Se eliminó el subproceso de división automática para los nodos mongos.

Conclusión

MongoDB versión 4.2 viene con algunas mejoras en cuanto a seguridad y rendimiento de la base de datos. Ha incluido un cifrado de nivel de campo del lado del cliente automático que garantiza que los datos estén protegidos desde el punto de vista del cliente. Más funciones, como un motor de búsqueda de terceros y la inclusión de la etapa $merge en el marco de agregación, mejoran el rendimiento de la base de datos. Antes de poner esta versión en producción, asegúrese de que todas sus necesidades estén cubiertas por completo.