Se me ocurren algunas estrategias:
1) Use una colección/base de datos distinta para los documentos 'calientes'.
Si sabe qué documentos están en el conjunto activo, entonces sí, moverlos a una colección separada ayudará. Esto asegurará que los documentos activos sean co-residentes en las mismas extensiones/páginas. También hará que el índice de esos documentos sea más probable que esté completamente en la memoria. Esto se debe a que es más pequeño y se usa (¿completamente?) con más frecuencia.
Si los documentos calientes se mezclan aleatoriamente con otros documentos, es probable que tenga que fallar en más de los elementos de hoja del índice B-Tree al cargar un documento, ya que la probabilidad de que otro documento se haya cargado o accedido recientemente al bloque de índice es pequeña.
2) Acortar los valores indexados .
Cuanto más corto sea el valor del índice, más valores caben en un solo bloque B-Tree. (Nota:las claves no están incluidas en el índice). Cuantas más entradas haya en un solo depósito, menos depósitos y menos memoria total se necesitarán para el índice. Eso se traduce en una mayor probabilidad/vidas más largas de que los bloques permanezcan en la memoria. En su ejemplo, una reducción de 20->8 caracteres es mejor que un ahorro del 50%. Si puede convertir esos 8 bytes en largos, hay un poco más de ahorro, ya que los largos no tienen un prefijo de longitud (4 bytes) y un valor nulo final (5 bytes en total).
3) Acorte los nombres de las claves.
Cuanto más cortos sean los nombres de campo, menos espacio ocupará cada documento. Esto tiene el desafortunado efecto secundario de disminuir la legibilidad.
4) Fragmento
Esta es realmente la única forma de mantener el rendimiento frente a las lecturas en todo un corpus que agotan la memoria y el ancho de banda del disco eventual. Si fragmenta, aún querrá fragmentar la colección 'caliente'.
5) Ajuste la lectura anticipada en el disco a un valor pequeño.
Dado que las lecturas 'no activas' están cargando un documento aleatorio desde el disco, realmente solo queremos leer/fallar en la memoria ese documento y la menor cantidad posible de documentos a su alrededor. La mayoría de los sistemas intentarán leer por adelantado un gran bloque de datos una vez que el usuario lea una parte de un archivo. Esto es exactamente lo contrario de lo que queremos.
Si ve que su sistema falla mucho pero la memoria residente para el proceso mongod no se acerca a la memoria disponible del sistema, es probable que vea el efecto del sistema operativo leyendo datos inútiles.
6) Trate de usar valores monótonamente crecientes para las claves.
Esto desencadenará una optimización (para índices basados en ObjectId) que cuando el bloque de índice se divida, lo hará en 90/10 en lugar de 50/50. El resultado es que la mayoría de los bloques en su índice estarán cerca de su capacidad y necesitará menos de ellos.
Si solo conoce los 50 000 documentos "calientes" después del hecho, agregarlos a la colección separada en orden de índice también activará esta optimización.
Rob.
