MongoDB es rápido, pero solo cuando su conjunto de trabajo o índice puede caber en la memoria RAM. Entonces, si mi servidor tiene 16G de RAM, ¿eso significa que los tamaños de todas mis colecciones deben ser menores o iguales a 16G? ¿Cómo se dice "ok, este es mi conjunto de trabajo, el resto se puede" archivar? "¿Qué significa ajustar "working set" en la memoria RAM para MongoDB?
"Working set" es básicamente la cantidad de datos AND índices que estarán activos/en uso por su sistema.
Por ejemplo, supongamos que tiene datos de 1 año. Para simplificar, cada mes se relaciona con 1 GB de datos que dan 12 GB en total, y para cubrir los datos de cada mes tiene índices de 1 GB que suman un total de 12 GB para el año.
Si siempre está accediendo a los últimos 12 meses de datos, entonces su conjunto de trabajo es: 12 GB (datos) + 12 GB (índices) = 24 GB.
Sin embargo, si solo tiene acceso a los últimos 3 meses de datos, entonces su conjunto de trabajo es: 3 GB (datos) + 3 GB (índices) = 6 GB. En este escenario, si tenía 8 GB de RAM y luego comenzó a acceder regularmente a los últimos 6 meses de datos, entonces su conjunto de trabajo comenzaría a exceder su memoria RAM disponible y tendría un impacto en el rendimiento.
Pero en general, si tiene suficiente RAM para cubrir la cantidad de datos/índices a los que espera acceder frecuentemente, estará bien.
Editar: Respuesta a la pregunta en los comentarios
No estoy seguro de que comprendo muy bien, pero voy a tener un ir en responder. En primer lugar, el cálculo para el conjunto de trabajo es una "figura del parque de bolas". En segundo lugar, si tiene un índice (por ejemplo) de 1GB en user_id, entonces solo la porción de ese índice que se accede comúnmente debe estar en RAM (por ejemplo, supongamos que el 50% de los usuarios están inactivos, entonces 0.5GB del índice será más frecuente requerido/necesario en RAM). En general, mientras más memoria RAM tengas, mejor será el conjunto de trabajo que probablemente crezca con el tiempo debido a un mayor uso. Aquí es donde entra en juego la fragmentación: divida los datos en múltiples nodos y puede escalar de forma rentable. Su conjunto de trabajo se divide en varias máquinas, lo que significa que se puede mantener más en la memoria RAM. ¿Necesitas más RAM? Agregue otra máquina a shard on a.
Gracias por usar ejemplos ;-) ... ¿Qué pasa si el sitio es algo similar a, digamos, un sitio de redes sociales? (No debatamos si NoSQL es la herramienta adecuada para el trabajo, etc.). Tienes millones de usuarios, supongo que tiene que ser una gran mesa. ¿Cómo definirías el conjunto de trabajo? Supongo que mi pregunta es, ¿cómo defines un conjunto de trabajo?Si indico "user_id", obviamente eso implica una colección de usuarios para todos mis usuarios. No puedo especificar, solo retiro usuarios de hace 3 meses, ¿podría? – luckytaxi
@luckytaxi - ¡(Con suerte) he respondido un poco más en mi actualización anterior! – AdaTheDev
Doh, se olvidó de sharding. Supongo que mi pregunta era más hacia "¿cómo le dices a mongo que guarde los siguientes datos como tu 'conjunto de trabajo?'". Si el 50% de los usuarios están inactivos, ¿cómo NO cargas eso en la RAM? – luckytaxi
El conjunto de trabajo es básicamente el material que está utilizando más (frecuentemente). Si utiliza el índice A para la colección B, busque un subconjunto de documentos, entonces podría considerar que su conjunto de trabajo. Siempre y cuando las partes más comúnmente utilizadas de esas estructuras puedan caber en la memoria, las cosas serán extremadamente rápidas. Como las piezas ya no caben en su conjunto de trabajo, como muchos de los documentos entonces eso puede ralentizar. Generalmente las cosas se volverán mucho más lentas si sus índices exceden su memoria
Sí, puede tener muchos datos, donde la mayoría está "archivada" y rara vez se usa sin afectar el rendimiento de nuestra aplicación o impactando su conjunto de trabajo (que no incluye los datos archivados).
Entendí que el índice es un B-Tree. Si los datos van más allá del tamaño que cabe en ram, ¿por qué debería importar tanto? B-Tree es bastante rápido y reduce los accesos al disco en gran medida. ¿Por que preocuparse?
Considere publicar esto como una pregunta separada, en lugar de como una respuesta. Para abreviar, si el tamaño del índice excede el tamaño de la memoria disponible, será necesario leer desde el disco para acceder a partes del índice. Leer desde el disco es órdenes de magnitud más lento que leer desde la memoria. – Puhlze
FYI, para estimar el tamaño actual del conjunto de trabajo, ejecute: "db.runCommand ({serverStatus: 1, workingSet: 1})". Por documentos, "El conjunto de trabajo para una base de datos MongoDB es la parte de sus datos a la que los clientes acceden con mayor frecuencia" http://docs.mongodb.org/manual/faq/diagnostics/ – AnneTheAgile