La traducción del artículo ha sido preparada en la víspera del inicio del curso .
Puntos clave:
- Es crucial desarrollar un esquema a pesar de que en MongoDB no es obligatorio.
- De igual manera, los índices deben ajustarse a su esquema y patrones de acceso.
- Evite el uso de objetos grandes y matrices extensas.
- Tenga cuidado con las configuraciones de MongoDB, especialmente en lo que respecta a la seguridad y la confiabilidad.
- En MongoDB no hay un optimizador de consultas, por lo que debe tener cuidado al realizar operaciones de consulta.
He estado trabajando con bases de datos durante mucho tiempo, pero solo recientemente descubrí MongoDB. Hay algunas cosas que me hubiera gustado saber antes de comenzar a trabajar con ella. Cuando una persona ya tiene experiencia en un área determinada, tiene preconcebidas ideas sobre lo que son las bases de datos y lo que hacen. Con la esperanza de facilitar la tarea de comprensión a otras personas, presento una lista de errores comunes.
Crear un servidor MongoDB sin autenticación
Desafortunadamente, MongoDB se instala por defecto sin autenticación. Para una estación de trabajo accesible localmente, esta práctica es aceptable. Pero dado que MongoDB es un sistema multiusuario que tiende a consumir grandes cantidades de memoria, será mejor instalarlo en un servidor con la máxima cantidad de memoria posible en sus condiciones, incluso si solo planea usarlo para desarrollo. La instalación en el servidor a través del puerto por defecto puede ser problemática, especialmente si en la consulta se puede ejecutar cualquier código en JavaScript (por ejemplo, $where como idea para ).
Existen varios métodos de autenticación, pero la forma más sencilla es establecer un ID/contraseña para el usuario. Use esta idea mientras piensa en una autenticación más elaborada basada en . En términos de seguridad, MongoDB debe actualizarse constantemente, y siempre se deben revisar los registros en busca de accesos no autorizados. Por ejemplo, me gusta elegir otro puerto como el puerto por defecto.
No olvide vincular la superficie de ataque a MongoDB
contiene buenos consejos para reducir el riesgo de infiltración en la red y fuga de datos. Es fácil despreciar y decir que un servidor de desarrollo no necesita un alto nivel de seguridad. Sin embargo, no es tan simple y esto se aplica a todos los servidores de MongoDB. En particular, si no hay una razón convincente para usar , o , se debe desactivar el uso de código arbitrario en JavaScript, escribiendo en el archivo de configuración . Dado que en MongoDB estándar los archivos de datos no están cifrados, es razonable ejecutar MongoDB con , que tiene acceso completo a los archivos, con acceso limitado solo para él y la posibilidad de usar sus propios medios de control de acceso al sistema de archivos.
Error en el diseño del esquema
MongoDB no utiliza esquema. Pero esto no significa que el esquema no sea necesario. Si solo desea almacenar documentos sin un esquema coherente, se puede hacer de manera rápida y sencilla, pero luego recuperarlos puede ser .
El artículo clásico « vale la pena leerlo, y funciones como en la herramienta externa Studio 3T, deberían usarse para revisiones regulares de esquemas.
No se olvide del orden de clasificación
Olvidar el orden de clasificación puede ser lo más decepcionante y perder más tiempo que al usar cualquier otra configuración incorrecta. Por defecto, MongoBD utiliza . Pero seguramente no será útil para nadie. Las clasificaciones sensibles a mayúsculas, acentos, y binarias se consideraban curiosos anacronismos junto a cuentas, caftanes y bigotes rizados ya en la década de 1980. Ahora, su uso es imperdonable. En la vida real, 'moto' es lo mismo que 'Moto'. Y 'Britania' y 'britania' son el mismo lugar. La letra minúscula es simplemente el equivalente en mayúscula. Y no me obligues a hablar sobre la clasificación de diacríticos. Al crear una base de datos en MongoDB, utilice parámetros de clasificación que ignoren acentos y , que correspondan al idioma y . Así simplificará en gran medida la búsqueda de datos de texto.
Crear colecciones con documentos grandes
MongoDB se complace en albergar grandes documentos de hasta 16 MB en colecciones, y está diseñado para documentos que superan los 16 MB. Sin embargo, aunque se pueden almacenar grandes documentos allí, no es la mejor idea mantenerlos en ese lugar. MongoDB funcionará mejor si almacenas documentos individuales de unos pocos kilobytes, viéndolos más como filas en una amplia tabla SQL. Los grandes documentos pueden causar problemas con .
La creación de documentos con grandes arreglos
Los documentos pueden contener arreglos. Es mejor si la cantidad de elementos en el arreglo está lejos de alcanzar números de cuatro dígitos. Si se añaden elementos al arreglo con frecuencia, puede sobrepasar el documento que lo contiene, y necesitarás , lo que significa que tendrás que . Al reindexar un documento con un gran arreglo, los índices a menudo se sobrescriben, ya que existe una , que almacena su índice. Esta reindexación también ocurre cuando se inserta o elimina un documento.
En MongoDB existe lo que se llama el , que proporciona espacio para el crecimiento de los documentos, para minimizar este problema.
Puedes pensar que podrías prescindir de la indexación de arreglos. Desafortunadamente, debido a la falta de índices, pueden surgir otros problemas. Dado que los documentos se escanean de principio a fin, buscar elementos al final del arreglo tomará más tiempo, y la mayoría de las operaciones relacionadas con dicho documento serán .
No olvides que el orden de las etapas en la agregación es importante
En un sistema de base de datos con un optimizador de consultas, las consultas que escribes son explicaciones de lo que deseas obtener, no de cómo obtenerlo. Este mecanismo funciona de manera análoga a hacer un pedido en un restaurante: normalmente solo pides un plato, sin dar instrucciones detalladas al chef.
En MongoDB, tú instruyes al chef. Por ejemplo, debes asegurarte de que los datos pasen a través de reduce tan pronto como sea posible en la cadena de procesamiento con $match y $project, y que la clasificación ocurra solo después reduce, y que la búsqueda se realiza exactamente en el orden que necesita. La presencia de un optimizador de consultas que elimina el trabajo innecesario, ordena las etapas de manera óptima y elige el tipo de conexión, puede consentirlo. En MongoDB, tiene más control a expensas de la conveniencia.
Herramientas como simplificarán la construcción de consultas de agregación en . La función Aggregation Editor le permitirá aplicar operadores de tubería etapa por etapa, así como verificar los datos de entrada y salida en cada etapa para facilitar la depuración.
El uso de escritura rápida
Nunca configure en MongoDB parámetros de escritura con alta velocidad pero baja confiabilidad. Este modo «file-and-forget» parece rápido, ya que el comando devuelve antes de que se realice la escritura. Si el sistema falla antes de que los datos se escriban en el disco, se perderán y quedarán en un estado inconsistente. Afortunadamente, el MongoDB de 64 bits incluye registro.
Los motores de almacenamiento MMAPv1 y WiredTiger utilizan registro para prevenir esto, aunque WiredTiger puede recuperarse hasta el último punto de control consistente El registro garantiza que la base de datos esté en un estado consistente después de la recuperación y almacena todos los datos hasta el momento de la escritura en el registro. La frecuencia de las escrituras se ajusta mediante el parámetro
Para asegurarse de que las escrituras sean confiables, asegúrese de que el registro esté habilitado en el archivo de configuración .
, y que la frecuencia de las escrituras coincida con la cantidad de información que puede permitirse perder. )Ordenar sin índice
Al buscar y agregar, a menudo surge la necesidad de ordenar datos. Esperemos que esto se realice en una de las etapas finales, después de filtrar los resultados para reducir la cantidad de datos a ordenar. E incluso en ese caso, necesitará
. Puede utilizar un índice simple o compuesto. Si no hay un índice adecuado, MongoDB prescindirá de él. Hay una limitación de memoria de 32 MB en el tamaño total de todos los documentos en
la operación de ordenación un conjunto de registros vacío .
Поиск без поддержки индексов
Las consultas de búsqueda cumplen una función similar a la operación JOIN en SQL. Para un mejor rendimiento, necesitan un índice del valor de la clave que se utiliza como clave externa. Esto no es obvio, ya que el uso no se refleja en explain(). Dichos índices son un complemento al índice registrado en explain(), que a su vez es utilizado por los operadores de pipeline $match y $sort, cuando aparecen al principio del pipeline. Los índices ahora pueden abarcar cualquier etapa .
La renuncia al uso de actualizaciones múltiples
El método se utiliza para modificar parte de un documento existente o el documento completo, hasta la sustitución total según el parámetro que hayas definido . No es tan obvio que no procesará todos los documentos en la colección hasta que establezcas el parámetro para actualizar todos los documentos que cumplen los criterios de la consulta.
No olvides la importancia del orden de las claves en la tabla hash
En JSON, un objeto consiste en una colección no ordenada de cero o más pares nombre/valor, donde el nombre es una cadena y el valor puede ser una cadena, un número, un valor booleano, cero, un objeto o un array.
Desafortunadamente, BSON otorga gran importancia al orden al buscar. En MongoDB, el orden de las claves dentro de objetos incrustados , es decir, { firstname: "Phil", surname: "factor" } no es lo mismo que { { surname: "factor", firstname: "Phil" }. Es decir, debes mantener el orden de los pares nombre/valor en los documentos si deseas asegurarte de encontrarlos.
No confundas "null" y "undefined"
Valor "undefined" nunca ha sido válido en JSON, según JSON (ECMA-404, Sección 5), a pesar de que se usa en JavaScript. Además, para BSON, ha quedado obsoleto y se convierte en $null, lo cual no siempre es una buena solución. .
Uso $limit() sin $sort()
A menudo, cuando desarrollas en MongoDB, es útil simplemente ver un ejemplo del resultado que regresará de una consulta o agregación. Para esta tarea, necesitarás $limit(), pero nunca debería estar en la versión final del código, a menos que lo uses antes de él. $sort. Esta mecánica es necesaria, ya que de lo contrario no puedes garantizar el orden del resultado y no podrás revisar los datos de manera confiable. En la parte superior del resultado, recibirás diferentes registros dependiendo de la ordenación. Para un funcionamiento confiable, las consultas y agregaciones deben ser deterministas, es decir, deben producir los mismos resultados en cada ejecución. El código que contiene $limit(), pero no tiene $sort, no será determinista y puede causar errores que serán difíciles de rastrear.
Conclusión
La única forma de desilusionarse con MongoDB es compararla directamente con otro tipo de bases de datos, como las bases de datos relacionales, o acercarse a su uso con ciertas expectativas específicas. Es como comparar una naranja con un tenedor. Las bases de datos persiguen objetivos específicos. Lo mejor es entender y apreciar estas diferencias por uno mismo. Sería una lástima presionar a los desarrolladores de MongoDB por el camino que se vieron obligados a seguir adoptando la metodología de las bases de datos relacionales. Me gustaría ver formas nuevas e interesantes de resolver problemas antiguos, como asegurar la integridad de los datos y crear sistemas de datos resistentes a fallos y ataques maliciosos.
La introducción de la atomicidad de transacciones ACID en MongoDB en la versión 4.0 es un buen ejemplo de la implementación de mejoras importantes de manera innovadora. Ahora, las transacciones de múltiples documentos y operadores son atómicas. También se ha añadido la capacidad de regular el tiempo necesario para obtener bloqueos y finalizar transacciones colgadas, así como de modificar el nivel de aislamiento.
Leer más:
Fuente: habr.com
