Puedo confirmar que nada ha cambiado en 3.6Persiste el problema de ejemplo lento $.
~40 millones de colección de documentos pequeños, sin índices, Windows Server 2012 x64.
almacenamiento:wiredTiger.engineConfig.journalCompressor:zlibwiredTiger.collectionConfig.blockCompressor:zlib
2018-04-02T02:27:27.743-0700I COMANDO [conn4] comando mapas.lugares
comando:agregado { agregado:"lugares", tubería:[ { $muestra:{ tamaño:10 } } ] ,
cursor: {}, lsid: { id: UUID("0e846097-eecd-40bb-b47c-d77f1484dd7e") }, $readPreference: { mode: "secondaryPreferred" }, $db: "maps" } planSummary: MULTI_ITERATOR keysExamined:0 docsExamined:0 cursorExhausted:1 numYields:3967 nreturned:10 reslen:550 locks:{ Global: { acquireCount: { r: 7942 } }, Database: { acquireCount: { r: 3971 } }, Collection: { acquireCount: { r: 3971 } } }
protocolo:op_query 72609ms
Instalé Mongo para probar este "DBMS moderno y eficaz" en un proyecto serio. Cuán profundamente frustrado estoy.
Explicar el plan está aquí:
db.command('aggregate', 'places', pipeline=[{"$sample":{"size":10}}], explain=True)
{'ok': 1.0,
'stages': [{'$cursor': {'query': {},
'queryPlanner': {'indexFilterSet': False,
'namespace': 'maps.places',
'plannerVersion': 1,
'rejectedPlans': [],
'winningPlan': {'stage': 'MULTI_ITERATOR'}}}},
{'$sampleFromRandomCursor': {'size': 10}}]}
