MongoDB Examples¶
Real scenarios showing what the MongoDB connector does with deployments and collections arranged in different ways. Pick a tab to see how the connection is set up and what to expect from the Sync, the Profile, and the Scan.
Connecting a MongoDB Atlas cluster¶
Context. A team runs its application database on MongoDB Atlas. Atlas gives the cluster a single address of the form cluster0.abcde.mongodb.net and expects clients to look up its members through DNS. The team creates a database user for Qualytics in Atlas and adds the Public addresses shown in the Qualytics form to the Atlas IP access list.
What happens. They enter the cluster address in Host, with no port, and set DNS Seed List (SRV) to Yes (mongodb+srv, e.g. Atlas). Qualytics looks up the cluster's members through DNS and connects to them over TLS, even though SSL Connection was left off. Auth Source stays at admin, where Atlas defines its database users. Once the connection test passes, the Database dropdown lists the cluster's databases, and they pick orders.
Why it works. With SRV, the address names the cluster rather than any one server, so members can be added or replaced in Atlas without touching the connection. Port is ignored with SRV, and TLS is always on, which is what Atlas requires.
A self-hosted replica set¶
Context. A three-member replica set runs in the team's own network, on mongo-1.internal, mongo-2.internal, and mongo-3.internal. Two members listen on 27017 and one on 27018.
What happens. They enter all three members in Host, each with its port: mongo-1.internal:27017,mongo-2.internal:27017,mongo-3.internal:27018. Port stays empty, because each member already carries its own, and DNS Seed List (SRV) stays at No. The servers use TLS, so they turn on SSL Connection. Qualytics discovers the replica set from whichever listed members answer, and follows it when another member becomes primary.
Why it works. Listing several members means the connection can still be opened when one of them is down, which a single host name would not allow. The Port field only applies to a single host written without a port, so leaving it empty avoids any ambiguity.
A collection whose documents do not all look the same¶
Context. A customers collection has grown over several years. Older documents store phone as text, newer ones as a sub-document with mobile and home, and a few documents store a preferences sub-document with dozens of keys that differ from customer to customer.
What happens. The Sync samples up to 10,000 documents and settles on one type per field. preferences has more than 20 different keys across the sample, so it is read as a map, and the keys that appear in enough documents are promoted to fields of their own. A profile then reports the completeness of each field. Where a document holds a value of a type that does not fit the field and cannot be converted, that field reads as empty for that document, and its other fields are read normally.
Why it works. The fields stay as the Sync found them until the next Sync, so profiles and scans compare like with like. When the team later adds a loyalty sub-document to new customers, it does not appear until they run a Sync again, at which point it becomes a field that checks can use.
Monitoring several databases on one deployment¶
Context. One MongoDB deployment holds a database per business unit: sales, support, and billing. The team wants each to have its own owners and checks in Qualytics.
What happens. On a new connection, they select all three databases in the Database dropdown. Name turns into Name Template, and they enter mongo_{{schema}}, which creates mongo_sales, mongo_support, and mongo_billing. Each datastore is assigned to the team that owns the business unit. Later, a fourth database is added to the same connection through Add with an Existing Connection.
Why it works. All the datastores share one saved connection, so the password lives in one place and changing it is a single edit. Each database is still its own datastore, with its own teams, schedules, and enrichment destination.
See Also¶
-
Best Practices
Recommendations for planning the connection, getting stable fields from the sample, and keeping operations fast.
-
Permissions
The access your MongoDB deployment must grant, plus the Qualytics user role and team permission needed to manage the datastore.
-
Authentication
User and password sign-in, the Auth Source database, and when to leave both credentials empty.