Open rkingsbury opened 1 year ago
Flagging @arosen93 in case this intersects with thoughts in #828
Thanks! Makes sense!!
I'm curious how one uses the file based stores in production though if multiple processes accessing the DB at the same time will cause issues (as is the case for MontyDB and Mongita). I guess these solutions really are just meant for the single-job, serial use case?
Thanks! Makes sense!!
I'm curious how one uses the file based stores in production though if multiple processes accessing the DB at the same time will cause issues (as is the case for MontyDB and Mongita). I guess these solutions really are just meant for the single-job, serial use case?
TBH I don't think anyone has used the file-based Store
enough to have encountered this problem yet!
Also my assumption 😄 To uncharted territory we go!
The performance of
MemoryStore
, which is currently powered bymongomock
, is relatively slow. This can particularly cause noticeable delays when connecting to aFileStore
, which usesMemoryStore
internally. It would be great to find an alternative tomongomock
that is more performant.I have begun working on this and will keep this issue updated with my findings.
Possible Alternatives
mongomock
(base case)mongita
montydb
(already a dependency; could refactorMemoryStore
to inherit fromMontyStore
)pymongo-inmemory
Notes so far
montydb
See https://github.com/davidlatwe/montydb/issues/14
montydb
does not supportbulk_write
orestimated_document_count
although those can be worked around.montydb
could not create more than 1 DB instance in memory. See https://github.com/davidlatwe/montydb/issues/79#issuecomment-1647742157mongita
mongita
does not support many query operations including$regex
or$exists
. It also doesn't supportbulk_write
orestimated_document_count
although those can be worked around.pymongo-inmemory
Not tested yet, butlooks quite promising because it actually usesmongo
(as opposed to mocking it) See #846