una - Estrategias para búsquedas rápidas de miles de millones de documentos pequeños en MongoDB

insertar varios documentos en mongodb

Question

Necesito almacenar varios miles de millones de pequeñas estructuras de datos (alrededor de 200 bytes cada una). Hasta ahora, el almacenamiento de cada elemento como un documento separado funciona bien, y Mongo proporciona alrededor de 10.000 resultados por segundo. Estoy usando un hash de 20 bytes como el _id para cada documento y un índice único en el campo _id. En las pruebas, esto funciona para conjuntos de datos con 5,000,000 de documentos.

En operación, realizaremos alrededor de 10,000 solicitudes por segundo, actualizaremos los documentos existentes aproximadamente 1,000 veces por segundo e insertaremos nuevos documentos tal vez 100 veces por segundo o menos.

¿Cómo podemos administrar conjuntos de datos más grandes, cuando no podemos almacenar un índice completo en la RAM? ¿MongoDB funcionará mejor si combinamos varios elementos en cada documento, para una búsqueda más rápida a través del índice, pero se devuelven más datos en cada consulta?

A diferencia de otras preguntas sobre SO, no solo me interesa la cantidad de datos que podemos incluir en Mongo. Puede gestionar claramente la cantidad de datos que estamos viendo. Mi preocupación es cómo podemos maximizar la velocidad de las operaciones de find en grandes colecciones, dada la RAM restringida.

Nuestras búsquedas tenderán a ser agrupadas; alrededor de 50,000 elementos satisfarán aproximadamente el 50% de las consultas, pero el 50% restante se distribuirá aleatoriamente entre todos los datos. ¿Podemos esperar una ganancia de rendimiento al mover ese 50% en su propia colección, para mantener un índice más pequeño de los datos más utilizados siempre en RAM?

¿Reducir el tamaño del campo _id de 20 bytes a 8 bytes tendría un impacto significativo en la velocidad de indexación de MnogoDB?

Answer 1

Algunas estrategias vienen a la mente:

1) Utilice 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 candentes 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 elementos de hoja del índice B-Tree cuando cargue un documento, ya que la probabilidad de que otro documento haya cargado recientemente o haya accedido al bloque del índice es pequeña.

2) Acortar los valores indexados.

Cuanto más corto sea el valor del índice, más valores encajarán en un solo bloque B-Tree. (Nota: las claves no están incluidas en el índice). Cuantas más entradas en un solo cubo, menos cubos y menos memoria total se necesita para el índice. Eso se traduce en la mayor probabilidad / vida útil más larga que los bloques permanecerán en la memoria. En su ejemplo, una reducción de 20-> 8 caracteres es mejor que un 50% de ahorro. Si puede convertir esos 8 bytes en un largo, hay un poco más de ahorro ya que los largos no tienen un prefijo de longitud (4 bytes) y un nulo final (5 bytes en total).

3) Acortar los nombres de las teclas.

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 manera de mantener el rendimiento frente a las lecturas en todo el cuerpo que agota la memoria y el ancho de banda del disco. Si haces shard, todavía querrás shard la colección ''hot''.

5) Ajuste la lectura anticipada en el disco a un valor pequeño.

Ya que las lecturas "no calientes" están cargando un documento aleatorio del 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 de que el sistema operativo lea datos inútiles.

6) Trate de usar valores monótonamente crecientes para las teclas.

Esto activará una optimización (para los índices basados ​​en ObjectId) que cuando el bloque de índice se divida, lo hará a 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 ''actuales'' después del hecho, al agregarlos a la colección separada en orden de índice también se activará esta optimización.

Robar.