Esta es una pregunta básica, pero muy importante, y no estoy seguro de que realmente consigue el punto.

En la documentación oficial podemos leer

MongoDB guarda todas las de la mayoría de los datos usados recientemente en la RAM. Si se han creado índices para sus consultas y de tu trabajo conjunto de datos se ajusta en la memoria RAM, MongoDB sirve todas las consultas de la memoria.

La parte no estoy seguro de entender es

Si se han creado índices para sus consultas y de tu trabajo conjunto de datos se ajusta en la memoria RAM

¿qué significa «índices» aquí?

Por ejemplo, si yo actualización de un modelo, entonces me consulta, porque me han actualizado, ahora es en la memoria RAM por lo que vendrá a partir de la memoria, pero esto no es muy claro en mi mente.

¿Cómo podemos estar seguros de que los datos que nos consulta vendrá de la memoria o no? Entiendo que MongoDB utiliza la memoria caché de datos sobre la memoria, que es libre en el momento, pero, ¿alguien podría explicar un poco más el comportamiento global ?

En cuyo caso podría ser mejor usar una variable en nuestro nodo servidor que almacene datos de confianza de la MongoDB sistema de caché?

¿Cómo globalmente recomendamos el uso de MongoDB para tráfico enorme?

InformationsquelleAutor Ludo | 2013-07-08

2 Comentarios

  1. 27

    Nota: Esto fue escrito en el año 2013 cuando MongoDB era aún muy joven, no tenía las características que tiene hoy, mientras que esta respuesta sigue siendo válido para el mmap, no para las otras tecnologías de almacenamiento de MongoDB ahora implementa, como WiredTiger, o Percona.


    Un buen lugar para empezar a entender exactamente lo que es un índice: http://docs.mongodb.org/manual/core/indexes/

    Después de haber cepillado en que udersand por qué son tan buenas, sin embargo, salto hacia adelante a algunas de las más intrincadas preguntas.

    ¿Cómo podemos estar seguros de que los datos que nos consulta vendrá de la memoria o no?

    Una forma es buscar en la yields campo en cualquier consulta explain(). Esto le dirá cómo muchas veces el lector dado su bloqueo debido a que los datos no estaba en la RAM.

    Otra forma más profunda es buscar en programas como mongostat y otros programas. Estos programas le dirá acerca de lo que los fallos de página (cuando los datos debe ser paginado en la memoria RAM del disco) están sucediendo en su mongod.

    Entiendo que MongoDB utiliza la memoria caché de datos sobre la memoria, que es libre en el momento, pero, ¿alguien podría explicar un poco más el comportamiento global ?

    Esto es realmente incorrecto. Es más fácil decir simplemente que MongoDB hace esto pero en realidad no lo hace. De hecho, es el sistema operativo y su propio algoritmos de paginación, generalmente el LRU, que hace esto para MongoDB. MongoDB no caché índice de los planes para un cierto período de tiempo, por lo que no tiene que estar constantemente revisando y pruebas para los índices.

    En cuyo caso podría ser mejor usar una variable en nuestro nodo servidor que almacene datos de confianza de la MongoDB sistema de caché?

    No está seguro de cómo se espera que funcione…me refiero a las dos cosas bastante diferentes y si usted va a leer los datos de MongoDB en su aplicación en el inicio en que var entonces yo definitivamente no lo recomendaría.

    Además OS algoritmos para la gestión de la memoria son muy maduros y rápido, así que está bien.

    ¿Cómo globalmente recomendamos el uso de MongoDB para tráfico enorme?

    Hmm, esta es una gran pregunta. Realmente le recomiendo que en Google un poco en este tema, pero como la documentación indica que usted necesita para asegurarse de que su trabajo se ajusta en la memoria RAM para uno.

    Aquí es un buen punto de partida: ¿Qué significa el ajuste «espacio de trabajo» en la memoria RAM para MongoDB?

    • Creo que probablemente era obligatorio, al menos, mencionar el WiredTiger y Percona la memoria de los motores en una discusión acerca de la caché de…
    • este fue un buen tiempo antes de MongoDB había nada de eso…
    • buen punto. Pero tal vez usted podría editar una nota acerca de él, como una actualización? Esto es muy visitado con frecuencia, la respuesta…
    • la feria, aunque una mejor solución, si este es frecuentado, es para que esta respuesta sea editado o alguien con más tiempo en sus manos para escribir un hasta la fecha de respuesta
  2. 6

    MongoDB intenta mantener colecciones enteras en la memoria: la memoria se asigna a cada página de la colección. Para que todo sea en la memoria, tanto en las páginas de datos, y los índices que hacen referencia a ellos, deben ser guardados en la memoria.

    Si MongoDB devuelve un registro, usted puede estar seguro de que está ahora en la memoria (si era antes de su consulta o no).

    MongoDB no mantener un «caché» de los registros de la misma manera que, por ejemplo, un navegador web. Cuando usted comete un cambio, tanto de la memoria y el disco se actualizan.

    Mongo es gran cuando se combina con el uso adecuado de los casos. Es muy de alto rendimiento si usted tiene suficiente memoria del servidor de caché de todo, y declina rápidamente más allá de ese punto. Muchos, muchos de alto volumen de sitios web uso de MongoDB: es una buena cosa que la memoria es tan barato, ahora.

    • «es la memoria se asigna a cada página de la colección» asigna cosas virtual de la memoria RAM no, son dos las cosas de manera diferente y este es un error común por la gente, MongoDB no es una base de datos en memoria!
    • Así, se asigna direcciones de memoria, independientemente de si son virtuales o físicos. Cuando un núcleo de dirección se hace referencia a un error de página se produce, y que el disco de la página se mueve entonces en la memoria física. MongoDB se chupan hasta casi toda la memoria física que el servidor tiene (reservando un poco para el propio sistema operativo y otros procesos). Para MongoDB para ser eficiente, la memoria física disponible debe exceder el tamaño de base de datos.
    • Se chupan hasta la memoria debido a que el sistema operativo lo permite. Sin embargo, sólo se carga el conjunto de trabajo en la memoria RAM, si su conjunto de trabajo es pequeña, MongoDB, en realidad, el uso de una pequeña cantidad de, mucho, mucho, mucho más pequeño que el tamaño de los datos
    • Totalmente de acuerdo con @Sammaye — Curt, no es necesario que la memoria física para superar el tamaño de base de datos (como la mayoría de las bases de datos). Lo ideal sería que se ajusta al tamaño del conjunto de trabajo como Sammaye mencionado.
    • No creo que realmente estamos en desacuerdo. En mi primaria MongoDB aplicación, el tamaño de base de datos es de alrededor de 300 GB, pero desde mi trabajo (en el día a día de la producción) es considerablemente menor que el tamaño de la instancia es generalmente inferior a 5 gb. Sin embargo, si hago las consultas ad-hoc contra el conjunto de datos para el análisis (o cualquier otra razón), el tamaño de la instancia crece a consumir todo de mi memoria del servidor y, a continuación, algunos. El gran peligro para la memoria viene cuando usted consulta de expedientes por no indizados campos-que es más o menos garantizada para leer cada registro en la memoria.
    • Cuál es el límite para que la memoria caché? Me refiero a que no puede almacenar en caché todos los datos, ya que definitivamente sale de recursos, a la derecha ?
    • Estoy asumiendo que este es para el viejo, obsoleto MMAPv1 motor de almacenamiento y no el valor predeterminado actual, WiredTiger (que parece tener un caché específica)? (Dado que a partir de 2013)

Dejar respuesta

Please enter your comment!
Please enter your name here