Seguro. Todo tipo de riesgos. En su mayoría pueden mitigarse, pero están allí.
Tenga en cuenta que si pregunta esto sobre cualquier sistema de base de datos, esa parte es verdadera.
Las cosas únicas de MongoDB …
- Sus desarrolladores pueden olvidar que las uniones son un antipatrón. Debe diseñar alrededor de la idea de que un registro comercial completo debe existir en un solo registro MongoDB.
- Su gente puede olvidar que la consistencia eventual significa que un Secundario dado puede tener datos obsoletos. Eso puede mitigarse leyendo exclusivamente desde el Primario o aceptando que los datos pueden estar obsoletos. De la misma manera que lo hace su banco cuando le dice que algunas transacciones pueden no haberse liquidado todavía.
- Su gente puede establecer la consistencia de escritura demasiado baja para aumentar la velocidad a las secundarias. Esto reduce la durabilidad de sus datos en caso de que el primario se caiga y no pueda recuperarse.
- Copias de seguridad; Si utiliza el servicio MongoDB, las copias de seguridad se realizarán mediante un cifrado SSL; sin embargo, no se cifran en reposo. La última vez que revisé estaban trabajando en esto.
- Si realiza copias de seguridad en el sitio (o envía copias de seguridad a la nube), entonces tiene el potencial de que los datos se eliminen … así que tiene problemas de seguridad. Podrías cifrar internamente tu aplicación, lo que mitigaría eso.
- No es fácil hacer que un registro o parte de un registro sea inaccesible para el personal que tiene acceso a los otros registros o partes del registro. Por lo tanto, su personal de primera línea puede tener más acceso del que usted pretende.
- Si desea toda la configuración de seguridad para Mongo, debe comprar una licencia empresarial para su clúster. Ese es un riesgo de costo adicional.
- Es posible que no elija la clave de fragmento correcta cuando desee escalar. Eso significa una migración completa cuando elige una nueva clave de fragmento.
- Cuando fragmenta, si elige la clave de fragmento incorrecta, puede obtener puntos calientes. (Ciertos servidores hacen la mayor parte del trabajo en lugar de distribuirlo).
- Es posible que algún tonto ejecute una consulta en la base de datos durante las horas de producción que no se planificó y ponga de rodillas al servidor. Entonces debes mitigar eso de varias maneras obvias.
- Es posible que su gente no se dé cuenta de que lo único atómico (con respecto a las transacciones) es un solo registro. Por lo tanto, pueden creer que están haciendo lo correcto al segregar los datos, pero pueden terminar fallando en sincronizar los datos. Por lo general, recomiendo que la aplicación ponga toda la transacción en un solo registro y luego la marque como válida o no.
- Corre el riesgo de que los relojes de los servidores no estén sincronizados. Eso no es un problema hasta que necesite cambiar las primarias. También se puede mitigar a través de cosas como ntp.
- Deberá actualizar periódicamente la versión de su base de datos. El riesgo de quedarse atrás es que si tiene un acuerdo empresarial, las personas que manejan el soporte pueden negarse a admitir su versión si es demasiado antigua. Sin embargo, el cronograma de actualización es bastante agresivo y debe actualizar al menos dos veces al año para mantenerse al día. Esto no sería un problema, excepto que no hay garantía de que sus controladores no necesiten actualizarse también.
- Si necesita escalar, administrará muchos servidores. Lo que quiero decir es que tienes un conjunto de réplicas que ejecuta tus datos. Eso significa tres servidores, de manera realista, todos exactamente iguales. Al menos para la producción. Puede hacer dos y un árbitro en entornos no prod. Luego lo fragmenta para poder lidiar con el crecimiento de los datos. Supongamos que se divide en cuatro fragmentos, dividiendo la mayor parte de los datos de cuatro maneras. Cada fragmento necesitará un conjunto de 3 miembros de réplica. Por lo tanto, tiene 12 servidores cuando solía estar en 3. Eso sin contar los 3 servidores de configuración (que son un riesgo propio) y los servidores MongoS que no están en un servidor de aplicaciones.
- Su gente puede escribir consultas que tengan expresiones regulares sin anclar. Estos matan una base de datos mongo. Esencialmente invocan un escaneo completo de la tabla.
- Sus consultas pueden omitir los índices después de un cambio en la lógica de la aplicación.
- Es posible que su gente no desnormalice adecuadamente los datos. En este caso, eso significa principalmente hacer copias y mantenerlas sincronizadas o no hacerlo. Por ejemplo; Si necesito una colección que muestre mis suscripciones y otra que muestre a mis clientes, no debería unirme a ellas, debería poner datos duplicados en cada una para mantener los métodos de Mongo. Sin embargo, si arruino mi código, puedo tenerlos en desacuerdo entre ellos para que la dirección de Bob Smith se actualice en la tabla de clientes pero no en la tabla de suscripción.
- Las copias de seguridad pueden ignorarse o eliminar la prioridad hasta el punto de que dejen de ser funcionales. La razón habitual es que la gente piensa que con los conjuntos de réplicas no necesitas una buena copia de seguridad. Sin embargo, eso no cubre todos los escenarios. Por ejemplo, ¿qué sucede cuando alguien corrompe algunos datos y necesita encontrar una copia recuperable? Cuando llegas a la “réplica retrasada”, te has atascado en tu clúster para esa emergencia, el límite de tiempo ha caducado y la corrupción se propaga. Entonces la copia de seguridad es tu único amigo. Si él no está cerca, entonces tu currículum es tu único amigo. Esto sucedió cuando un cliente importante eliminó algo a pesar de las pantallas de advertencia y quería que se recuperara.
Tiene que planificar sus consultas y alrededor de sus consultas. La mayoría de los problemas mencionados provienen de una decisión tomada que no parece mala en ese momento, pero luego se da cuenta de que fue una decisión incorrecta.
Eso está justo en la parte superior de mi cabeza. Como dije, la mayoría de ellos pueden mitigarse.
Y mongodb hace este tipo de trabajo para las personas. No digo que no lo uses. Estoy diciendo que haga que su gente sea consciente de los riesgos y aprenderán lo suficiente como para construir pruebas adecuadas y se asegurarán de que todo funcione sin problemas.
Mongo no es ciencia espacial. Solo tiene que tratarlo como si las seguridades estuvieran apagadas y tener cuidado. Al igual que cuando comienzas a trabajar con Linux y tienes mucho poder para arruinar las cosas.
