Después de desarrollar su aplicación y modelo de base de datos (cuando sea el momento de mover el entorno a producción), hay un par de cosas que deben hacerse primero. A menudo, los desarrolladores no tienen en cuenta los pasos adicionales importantes de MongoDB antes de implementar la base de datos en producción. En consecuencia, es en el modo de producción donde terminan encontrando contratiempos subyacentes que no se presentan en el modo de desarrollo. A veces puede ser demasiado tarde o, más bien, se perderían muchos datos si ocurre un desastre. Además, algunos de los pasos discutidos aquí permitirán medir la salud de la base de datos y, por lo tanto, planificar las medidas necesarias antes de que ocurra un desastre.
Usar la versión actual y los controladores más recientes
Por lo general, las versiones más recientes de cualquier tecnología vienen con características mejoradas con respecto a la funcionalidad subyacente que sus predecesores. Las últimas versiones de MongoDB son más sólidas y mejoradas que sus predecesoras en términos de rendimiento, escalabilidad y capacidad de memoria. Lo mismo se aplica a los controladores relacionados, ya que son desarrollados por los ingenieros de la base de datos central y se actualizan con más frecuencia incluso que la propia base de datos.
Las extensiones nativas instaladas para su idioma pueden establecer fácilmente una plataforma para procedimientos rápidos y estándar para probar, aprobar y actualizar los nuevos controladores. También hay software para automóviles, como Ansible, Puppet, SaltStack y Chef, que se pueden usar para actualizar fácilmente MongoDB en todos sus nodos sin incurrir en gastos profesionales ni en tiempo.
También considere usar el motor de almacenamiento WiredTiger, ya que es el más desarrollado con funciones modernas que se adaptan a las expectativas de las bases de datos modernas
Suscríbase a una lista de correo de MongoDB para obtener la información más reciente sobre cambios en nuevas versiones y controladores y corrección de errores, por lo tanto, manténgase actualizado.
Utilice un sistema de 64 bits para ejecutar MongoDB
En los sistemas de 32 bits, los procesos de MongoDB están limitados a unos 2,5 GB de datos porque la base de datos utiliza archivos asignados en memoria para el rendimiento. Esto se convierte en una limitación para los procesos que podrían sobrepasar el límite que conduce a un enamoramiento. El impacto principal será:en caso de error, no podrá reiniciar el servidor hasta el momento en que elimine sus datos o migre su base de datos a un sistema superior como el de 64 bits, por lo tanto, un mayor tiempo de inactividad para su aplicación.
Si tiene que seguir usando un sistema de 32 bits, su codificación debe ser muy simple para reducir la cantidad de errores y la latencia de las operaciones de rendimiento.
Sin embargo, para las complejidades del código, como la tubería de agregación y los datos geográficos, se recomienda utilizar el sistema de 64 bits.
Asegúrese de que los documentos estén encuadernados en un tamaño de 16 MB
Los documentos de MongoDB están limitados al tamaño de 16 MB, pero no es necesario que se acerque a este límite, ya que implicará una degradación del rendimiento. En la práctica, la mayoría de los documentos tienen un tamaño de KB o menos. El tamaño del documento depende de la estrategia de modelado de datos entre la incrustación y la referencia. Se prefiere la incrustación cuando no se espera que el tamaño del documento crezca mucho. Por ejemplo, si tiene una aplicación de redes sociales donde los usuarios publican y tiene comentarios, la mejor práctica será tener dos colecciones, una para guardar la información de la publicación.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}y el otro para guardar comentarios para esa publicación.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Al tener dichos modelos de datos, los comentarios se almacenarán en una colección diferente de la publicación. Esto evita que el documento en la colección posterior crezca fuera de límite en caso de que haya tantos comentarios. Asegúrese de evitar patrones de aplicación que permitan que los documentos crezcan sin límites.
Asegúrese de que el conjunto de trabajo quepa en la memoria
Es posible que la base de datos no pueda leer los datos de la memoria virtual (RAM), lo que genera errores de página. Los errores de página obligarán a la base de datos a leer datos de un disco físico, lo que provocará un aumento de la latencia y, en consecuencia, un retraso en el rendimiento general de la aplicación. Las fallas de página ocurren debido a que se trabaja con un conjunto grande que no cabe en la memoria. Esto puede deberse a que algunos documentos tienen un tamaño ilimitado o una estrategia de fragmentación deficiente. Los remedios para las fallas de página serán:
- Asegurarse de que los documentos estén limitados al tamaño de 16 MB.
- Garantizar una buena estrategia de fragmentación seleccionando una clave de fragmentación óptima que limitará la cantidad de documentos a los que estará sujeta una operación de rendimiento.
- Aumente el tamaño de la instancia de MongoDB para acomodar más conjuntos de trabajo.
Asegúrese de tener conjuntos de réplicas en su lugar
En el mundo de las bases de datos, no es ideal confiar en una sola base de datos debido al hecho de que puede ocurrir una catástrofe. Además, esperaría un aumento en el número de usuarios de la base de datos, por lo que es necesario garantizar una alta disponibilidad de los datos. La replicación es un enfoque fundamental para garantizar una alta disponibilidad en caso de conmutación por error. MongoDB tiene la capacidad de servir datos geográficamente:lo que significa que los usuarios de diferentes ubicaciones serán atendidos por el host en la nube más cercano como una forma de reducir la latencia de las solicitudes.
En caso de que el nodo principal falle, los nodos secundarios pueden elegir uno nuevo para mantenerse al día con las operaciones de escritura en lugar de que la aplicación tenga un tiempo de inactividad durante la conmutación por error. En realidad, algunas plataformas de alojamiento en la nube que son bastante consideradas con la replicación no admiten MongoDB no replicado para entornos de producción.
Habilitar registro en diario
Por mucho que el diario implique una degradación del rendimiento, también es importante. El registro en diario mejora las operaciones de escritura anticipada, lo que significa que, en caso de que la base de datos falle en el proceso de actualización, la actualización se habrá guardado en algún lugar y, cuando vuelva a estar activa, el proceso se podrá completar. El registro en diario puede facilitar fácilmente la recuperación de fallos, por lo que debe activarse de forma predeterminada.
Asegúrese de configurar una estrategia de copia de seguridad
Muchas empresas no pueden continuar después de la pérdida de datos debido a la falta de sistemas de copia de seguridad oa la falta de ellos. Antes de implementar su base de datos en producción, asegúrese de haber utilizado cualquiera de estas estrategias de copia de seguridad:
- Mongodump :óptimo para implementaciones pequeñas y cuando se producen copias de seguridad filtradas según necesidades específicas.
- Copia subyacente :óptimo para implementaciones grandes y enfoque eficiente para realizar copias de seguridad completas y restaurarlas.
- Servicio de administración de MongoDB (MMS) :proporciona una copia de seguridad en línea continua para MongoDB como un servicio totalmente administrado. Óptimo para un clúster fragmentado y conjuntos de réplicas.
Los archivos de respaldo tampoco deben almacenarse en el mismo proveedor de host de la base de datos. Backup Ninja es un servicio que se puede utilizar para esto.
Prepárese para consultas lentas
Difícilmente se pueden realizar consultas lentas en el entorno de desarrollo debido al hecho de que hay poca información involucrada. Sin embargo, este puede no ser el caso en producción considerando que tendrá muchos usuarios o una gran cantidad de datos estarán involucrados. Pueden surgir consultas lentas si no usó índices o usó una clave de indexación que no es óptima. Sin embargo, debemos encontrar una manera que le muestre el motivo de las consultas lentas.
Por lo tanto, decidimos habilitar MongoDB Query Profiler. Por mucho que esto pueda conducir a una degradación del rendimiento, el generador de perfiles ayudará a exponer los problemas de rendimiento. Antes de implementar su base de datos, debe habilitar el generador de perfiles para las colecciones que sospecha que pueden tener consultas lentas, especialmente aquellas que involucran documentos con muchas incrustaciones.
Conéctese a una herramienta de monitoreo
La planificación de la capacidad es una tarea muy esencial en MongoDB. También necesitará conocer la salud de su base de datos en cualquier momento. Para mayor comodidad, conectar su base de datos a una herramienta de monitoreo le ahorrará algo de tiempo para darse cuenta de lo que necesita para mejorar su base de datos con el tiempo. Por ejemplo, una representación gráfica que indica un rendimiento lento de la CPU como resultado de un aumento de consultas le indicará que agregue más recursos de hardware a su sistema.
Las herramientas de monitoreo también tienen un sistema de alerta a través de correo o mensajes cortos que lo actualizan convenientemente sobre algunos problemas antes de que se conviertan en una catástrofe. Por lo tanto, en producción, asegúrese de que su base de datos esté conectada a una herramienta de monitoreo.
ClusterControl proporciona monitoreo gratuito de MongoDB en Community Edition.
Implementar medidas de seguridad
La seguridad de la base de datos es otra característica importante que debe tenerse estrictamente en cuenta. Debe proteger la instalación de MongoDB en producción asegurándose de que se cumplan algunas listas de verificación de seguridad previas a la producción. Algunas de las consideraciones son:
- Configuración del control de acceso basado en funciones
- Habilitación del control de acceso y autenticación obligatoria
- Cifrado de conexiones entrantes y salientes (TLS/SSL)
- Limitar la exposición de la red
- Cifrado y protección de datos
- Tenga un plan de seguimiento sobre el acceso y los cambios en las configuraciones de la base de datos
Evite inyecciones externas ejecutando MongoDB con opciones de configuración seguras. Por ejemplo, deshabilitar las secuencias de comandos del lado del servidor si no se utilizan operaciones del lado del servidor de JavaScript, como mapReduce y $where. Utilice el validador JSON para los datos de su colección a través de algunos módulos como mongoose para asegurarse de que todos los documentos almacenados estén en formato BSON válido.
Consideraciones de hardware y software
MongoDB tiene pocos requisitos previos de hardware, ya que está diseñado explícitamente con gran consideración sobre el hardware básico necesario. Las siguientes son las principales deliberaciones de hardware para MongoDB que debe tener en cuenta antes de la implementación en producción.
- Asigne RAM y CPU adecuados
- Utilice el motor de almacenamiento WiredTiger. Diseñado para usar la memoria caché del sistema de archivos y la memoria caché interna de WiredTiger, por lo tanto, aumenta el rendimiento. Por ejemplo, cuando se opera con un sistema de 4 GB de RAM, la caché de WiredTiger usa 1,5 GB de RAM (0,5 * (4 GB -1 GB) =1,5 GB), mientras que un sistema con 1,2 GB de caché de RAM WiredTiger usa solo 256 MB.
- Hardware NUMA. Existen numerosos problemas operativos que incluyen un rendimiento lento y un alto uso de procesos del sistema, por lo tanto, se debe considerar configurar una política de intercalado de memoria.
- Disco y sistema de almacenamiento:use disco de estado sólido (SSD):MongoDB muestra una mejor relación precio-rendimiento con SATA SSD
Conclusión
Las bases de datos en producción son muy importantes para garantizar el buen funcionamiento de una empresa, por lo que deben tratarse con muchas consideraciones. Se deben establecer algunos procedimientos que puedan ayudar a reducir los errores o, más bien, proporcionar una manera fácil de encontrar estos errores. Además, es recomendable configurar un sistema de alerta que muestre el estado de la base de datos con tiempo para planificar la capacidad y detectar problemas antes de que se conviertan en una catástrofe.
