perf(db-mongodb): improve performance of all operations, up to 50% faster

[r1tsuu]

This PR improves speed and memory efficiency across all operations with the Mongoose adapter.

How?

• Removes Mongoose layer from all database calls, instead uses MongoDB directly. (this doesn't remove building mongoose schema since it's still needed for indexes + users in theory can use it)
• Replaces deep copying of read results using JSON.parse(JSON.stringify(data)) with the transform operation: 'read' function which converts Date's, ObjectID's in relationships / joins to strings. As before, it also handles transformations for write operations.
• Faster hasNearConstraint for potentially large where's
• traverseFields now can accept flattenedFields which we use in transform. Less recursive calls with tabs/rows/collapsible

Additional fixes

• Uses current transaction for querying nested relationships properties in buildQuery, previously it wasn't used which could've led to wrong results
• Allows to clear not required point fields with passing null from the Local API. Previously it didn't work in both, MongoDB and Postgres

Benchmarks using this file https://github.com/payloadcms/payload/blob/chore/db-benchmark/test/_community/int.spec.ts

Small Dataset Performance

Metric	Before Optimization	After Optimization	Improvement (%)
Average FULL (ms)	1170	844	27.86%
payload.db.create (ms)	1413	691	51.12%
payload.db.find (ms)	2856	2204	22.83%
payload.db.deleteMany (ms)	15206	8439	44.53%
payload.db.updateOne (ms)	21444	12162	43.30%
payload.db.findOne (ms)	159	112	29.56%
payload.db.deleteOne (ms)	3729	2578	30.89%
DB small FULL (ms)	64473	46451	27.93%

---

Medium Dataset Performance

Metric	Before Optimization	After Optimization	Improvement (%)
Average FULL (ms)	9407	6210	33.99%
payload.db.create (ms)	10270	4321	57.93%
payload.db.find (ms)	20814	16036	22.93%
payload.db.deleteMany (ms)	126351	61789	51.11%
payload.db.updateOne (ms)	201782	99943	50.49%
payload.db.findOne (ms)	1081	817	24.43%
payload.db.deleteOne (ms)	28534	23363	18.12%
DB medium FULL (ms)	519518	342194	34.13%

---

Large Dataset Performance

Metric	Before Optimization	After Optimization	Improvement (%)
Average FULL (ms)	26575	17509	34.14%
payload.db.create (ms)	29085	12196	58.08%
payload.db.find (ms)	58497	43838	25.04%
payload.db.deleteMany (ms)	372195	173218	53.47%
payload.db.updateOne (ms)	544089	288350	47.00%
payload.db.findOne (ms)	3058	2197	28.14%
payload.db.deleteOne (ms)	82444	64730	21.49%
DB large FULL (ms)	1461097	969714	33.62%

[franciscolourenco]

Any chance of exporting the transform utility in @payloadcms/db-mongodb for consumers? It would be useful in cases where we need to perform direct operations with mongo/mongoose.

[r1tsuu]

Don't see why we can't! See 3a68670
Additionally, ensured options.timestamps prop is respected, since it's mongoose-only, I think you use it

I'd say, actually the only problem with exporting things like this is that they aren't meant to be public and may receive breaking changes.

[franciscolourenco]

Thank you for considering the timestamps and exporting! The drawback you mention makes sense. I think we have been using mongoose more as an escape hatch when the adaptor doesn't support what we needed. As more options are added to the adaptor (e.g. select, batchsize, timestamps) we could replace some of those usages with the adapter.

[DanRibbens]

I think it is fine to export it as-is and add an @expiremental flag to the jsdocs so that anyone using this knows it may change in the future.

[DanRibbens]

I looked very close at your agregations very closely and it appears you are staying within the API limitations of AWS DocumentDB and Azure Cosmos DB. Great enhancements.

I would only rename the vars cursor to something else since those aren't being used as DB cursors, just an aggregation.
We can add export and experimental flag as a separate PR for @franciscolourenco to use the new transform, though you could do it now if you want.

[github-actions]

🚀 This is included in version v3.10.0