Considere colocar sus operaciones masivas de inserción en lotes manejables de, por ejemplo, 500 porque los comandos de escritura no pueden aceptar más de 1000 operaciones (de los documentos ), tendrá que dividir las operaciones masivas en múltiples lotes, en este caso puede elegir un tamaño de lote arbitrario de hasta 1000.

El motivo para elegir 500 es garantizar que la suma del documento asociado de Bulk.insert() sea menor o igual que el tamaño máximo del documento BSON , aunque no hay ninguna garantía de que se utilicen las solicitudes de operaciones predeterminadas de 1000 . encajar por debajo del límite de BSON de 16 MB. Sin embargo, las operaciones Bulk() en el shell mongo y los métodos comparables en los controladores no tienen este límite.

Al hacer los cálculos, querrá asegurarse de que esas 500 solicitudes de operación de inserción en sí mismas no creen un documento BSON de más de 16 MB, es decir, para un documento de entrada con 365 valores, debe determinar el factor de escala que traerá el tamaño total de documentos a 16 MB o menos. Para mí, parece que 365x500 es una suposición razonable para que un tamaño sea inferior a 16 MB, a diferencia de 365x12000:

 bulk = db.test.initialize_unordered_bulk_op() counter = 0 for i in range(1, 12000): # process in bulk bulk.insert(TimeSeries.getDict(i)) counter += 1 if (counter % 500 == 0): bulk.execute() bulk = db.test.initialize_unordered_bulk_op() if (counter % 500 != 0): bulk.execute()

--ACTUALIZAR--

En realidad, el límite no se aplica a la API masiva , sino a

Si un grupo excede este límite, MongoDB lo dividirá en grupos más pequeños de 1000 o menos.

Gracias a @Styva ne por señalar esto.