What is the best design for multitenancy in MongoDB with Rails?

Question

Anonymous · Answer

Simple one-to-many relationship.  If some of the fields are common to both types of users, place them in a main table.  For the field extensions you want to make, have a second table that stores name/value pairs (and possibly data type information) linked to the first using the primary key of the main table as a foreign key in the extension table.

While not as efficient as compared to explicit columns, it does allow you to add N fields to a linked record at-will.  So it works well as a generic data structure where you want the ability to be flexible in what you store.

As an example:

MAIN table (Common Fields)

ID PRIMARY KEY INTEGER
UserName VARCHAR(80)
StreetAddr1 VARCHAR(80)
BlahType INTEGER
...

EXTENDED_DATA table (Extensions)

DataID PRIMARY KEY INTEGER
MainID FOREIGN KEY to TenantID INTEGER
DataFieldName VARCHAR(30)
DataFieldValue VARCHAR(4096)

Then you would insert your common record info into the MAIN table and get its primary key.  Then insert the user-specific fields into the EXTENDED_DATA table for whatever user type or business data as needed.  Then write your software to configure what optional fields you're going to add to your structure for a given client user.

I've used this simple design for writing general purpose data capture systems such as audit trails or user activity logging.  I simply create a base object type that captures the generic structure and then extend those in my specific application with wrapper and data conversion functions for the extended fields.  It allows you to stand up a new application very quickly.  When we used this technique, it allowed us to "cookie cutter" an entire family of applications.  They all looked different and our users thought they were unique.  But under the hood, they used the same core and was built off a simple template.  We were able to crank out applications in a matter of days down from weeks.

Bhupal Reddy · Answer

There are several ways one can model a many-to-many relationship in MongoDB, and it all depends on the specific requirements of your application, such as how often does the data change, whether you want query performance or storage, among others.

Here is the human-friendly explanation of best and most efficient ways to handle many-to-many relationships in MongoDB:

Key Options for Many-to-Many Relationships:

1. Arrays of Embeds (Insecure but Easy)

In MongoDB, it could be conceptualized that one might model a many-to-many relationship by embedding arrays of related data inside of documents. This can be a very simple and efficient strategy if the number of related entities is limited or manageable in size.

Example:

Suppose you are working on a system for tracking students and courses, where each student can enroll in multiple courses, and each course can have multiple students.

You could store the courses each student is enrolled in as an array inside of the student document:

json

{

"_id": "student1",

"name": "John Doe",

"courses": ["course1", "course2", "course3"]

}

And on the course side you could store the list of students:

json

{

"_id": "course1",

"title": "Math 101",

"students": ["student1", "student2", "student3"]

}

Pros:

Very simple structure.

Lightning-fast lookups if you are continually reading this relationship.

Cons:Does not scale well if either the student lists or the course lists starts to get very large

It's more painful to maintain consistency when the same data is duplicated in several places. For example, a student can appear in many courses, and vice versa.

2. Reference IDs (Normalized Approach)

In MongoDB, the reference IDs can give much better scalability for representing many-to-many relationships than embedding the full data. That would be a bit similar to the normalized structure in a relational database and will efficiently handle big sets of data.

For instance, store the related IDs array inside each document rather than full data. It provides no duplication and much better scalability for big collections.

Example:

In the same students and courses example, each student document would include an array of course IDs and each course document an array of student IDs:

Student Document:

json

{

"_id": "student1",

"name": "John Doe",

"course_ids": ["course1", "course2", "course3"]

}

Course Document:

json

{

"_id": "course1",

"title": "Math 101",

"student_ids": ["student1", "student2", "student3"]

}

In this case, every time you need to query the many-to-many relationship, you would:

One would fetch the student, get the course IDs, and then use those to look up the courses. Or fetch a course, get the student IDs, and then query for those students. Pros: Efficient for large datasets - only reference IDs are stored. More maintainable for large-scale many-to-many relationships. Cons: Requires N+1 queries to fetch related data-one query to fetch the student for instance, and then another to fetch courses. Slightly more complex queries compared to simple embedded data.

3. Join Collection (Linking Collection):

If you have a more complex or dynamic many-to-many relationship, using a join collection will be effective. This interim collection stores references to both entities; it simplifies querying the relationship itself.

Example:

Create a new collection called enrollments whereby each document links a student to a course:

Enrollment Document:

json

{

"_id": "enrollment1",

"student_id": "student1",

"course_id": "course1",

"enrollment_date": "2024-09-09"

}

Now, if you wanted to see what courses a student is enrolled in, or what students are in a certain course, you would:

Query the enrollments collection for matching student or course IDs.

Use those IDs to fetch actual student or course documents.

Pros:

Very scalable, even for very large datasets.

Clean to maintain for complicated relationships.

Easy querying and management of metadata about the relationship-e.g., date of enrollment, status, etc.

Cons:

Additional queries are needed in order to link students to courses and vice-versa.

More complex structure than embedding arrays, but it's much more flexible.

Which Approach is Best?

If the lists are small and the data structure doesn't change often, you can use embedding arrays.

Reference IDs or a join collection will help keep the code base efficient and maintainable if you need scalability and flexibility. In an application that requires large-scale use with many-to-many relationships, a join collection is usually the best scalable and flexible way. This will at least help keep your data normalized without leading to any duplication of the data and support querying in an efficient manner while growing.

Gaëtan Gates Perrault · Answer

A document-oriented DB definitely has some nice features to offer here.

Note that this is not a "free lunch", as you still need some form of schema somewhere or your DB is just filled with garbage. So if you have specific client features you still need to wrap some tests around those features even without a schema in the DB.

Additionally you need to pay close attention to indexing requirements. MongoDB performs relatively poorly without indexes. If you have specific tenants trying to query on fields specific to their system, you will need to ensure that they are querying in a fashion that will still be responsive.

Also note two things from Martin Fowler's slides.
1. Devs are monitoring the MongoDB install, not operations. If this becomes a central part of your system, everyone will need training on it.
2. They are using Replication but not Sharding. Replication is relatively easy to set up and monitor. Sharding is dramatically more complex. Sharding also limits the type of queries you can reasonably perform.

Things to consider:
1. If the schema does not exist in the DB, where does it live? How can you can query on tenant-specific fields?
2. Where do the tenants "live"? Separate machines? Separate DBs in the same machine? In general, the NoSQL solutions are behind on the security front, so existing security models may need to be changed.
3. Tooling for NoSQL tools are nowhere near as sophisticated as it is for SQL. In most businesses, developers are not the only people digging around in DBs. Operations, QA, project management may all be trying to access DBs. So you'll need to ensure that all of these parties can still access their data.

ChatGPT · Answer

Designing a multitenant application with MongoDB and Ruby on Rails involves several considerations to ensure data isolation, scalability, and maintainability. Here are some common approaches, along with their pros and cons, to help you determine the best design for your use case:
1. Single Database, Shared Collections
Description: All tenants share the same database and collections. Each document includes a [code]tenant_id[/code] field to identify the tenant.
Pros:
- Simplicity: Easier to set up and maintain a single database.
- Cost-effective: Lower resource usage as all tenants share the same database.
- Easier to implement cross-tenant queries.
Cons:
- Data isolation: Requires careful access control to prevent data leakage between tenants.
- Performance: As the number of tenants grows, performance may degrade due to larger collections.
Implementation Example:
[code]# Migration to add tenant_id to a model
class AddTenantIdToUsers %3C ActiveRecord::Migration[6.0]
  def change
    add_column :users, :tenant_id, :string
    add_index :users, :tenant_id
  end
end[/code]
2. Single Database, Separate Collections
Description: Each tenant has its own collection within a single database.
Pros:
- Better data isolation: Each tenant's data is separated by collection.
- Easier to manage indexes and optimize queries for each tenant.
Cons:
- Increased complexity: Managing multiple collections can become cumbersome as the number of tenants grows.
- Potentially higher resource usage due to duplicate indexes and collection overhead.
Implementation Example:
[code]# Create a collection for each tenant
tenant_collection = "#{tenant_id}_users"
Mongoid::Clients.default[tenant_collection].insert_one({ name: "John Doe" })[/code]
3. Separate Databases for Each Tenant
Description: Each tenant has its own database.
Pros:
- Strong data isolation: Complete separation of data, which enhances security and compliance.
- Independent scaling: Each database can be optimized and scaled individually.
Cons:
- Higher resource usage: More databases can lead to increased overhead and management complexity.
- Complex migrations: Migrations need to be handled for each tenant's database separately.
Implementation Example:
[code]# Connecting to a tenant-specific database
Mongoid.configure do |config|
  config.clients = {
    default: {
      database: "shared_db",
      hosts: ["localhost:27017"],
      options: {}
    },
    tenant_db: {
      database: "#{tenant_id}_db",
      hosts: ["localhost:27017"],
      options: {}
    }
  }
end[/code]
4. Hybrid Approach
Description: A combination of the above methods, where some data is shared (e.g., user accounts) while tenant-specific data is isolated.
Pros:
- Flexibility: Can optimize for shared resources and tenant-specific needs.
- Improved performance: Shared resources can help reduce redundancy.
Cons:
- Complexity: More complicated to implement and maintain, requiring careful planning of data access patterns.
Considerations for Implementation
 * Authentication and Authorization: Ensure that each tenant can only access their own data. Use middleware or service objects to enforce tenant context.
 * Indexing Strategies: Optimize indexes based on the expected queries for each tenant. Consider the impact of tenant growth on performance.
 * Monitoring and Maintenance: Implement monitoring for tenant usage to identify performance bottlenecks or data issues.
 * Data Backup and Migration: Develop a strategy for backing up tenant data and handling migrations, especially if using separate databases.
Conclusion
The choice of multitenancy design in MongoDB with Rails largely depends on your application's specific needs regarding data isolation, scalability, and complexity. For smaller applications, a single database with shared collections may suffice, while larger, more complex applications might benefit from separate databases or a hybrid approach. Always consider the trade-offs in terms of maintenance and performance when making your decision.

Jesper Madsen · Answer

“What is the best way to insert documents into multiple collections at once using Mongoid (MongoDB)?”

When reading the question, the wording “at once” can be interpreted in different ways.

It could mean fastest possible way, which might mean bulk inserts, if you receive data in bulk. But if you receive documents 2 by 2, where each pair must be split and stored in their own collection, then the wait time before getting a full bulk might be undesirable. Going back to just inserting a document in each collection.

It can also mean “at the same time”, and thereby “in a transaction”. You can create a transaction and add commands to that. This can make sure that both documents in different collections are either inserted without errors or both fail.

Adam Gray · Answer

I personally believe MongoMapper is more stable than Mongoid with less bugs & odd outcomes. They are both great libraries and it really comes down to preference. There are a few key differences that each library developer pointed out in a pretty good post over at http://www.rubyinside.com.

** edit **

Found the post:

http://www.rubyinside.com/mongoid-vs-mongomapper-two-great-mongodb-libraries-for-ruby-3432.html

Gaëtan Gates Perrault · Answer

%3E What are some best practices for optimal performance of MongoDB...

1. Use Linux, Windows is poorly supported. The use of "infinite" virtual memory causes issues with Windows variants.
2. Lots of RAM, fast disks. This is true with all DBs, but MongoDB experiences a major performance drop-off when there is not enough RAM available. It's not a gradual drop-off, more of a cliff.
MongoDB tends not to be CPU-heavy and it only has one write thread, so the focus should be on RAM & IO.
3. Shard early. If you wait until your server is hammered, you simply will not be able to shard. If you know that you will need sharding in the future, do it now.
4. Be specific about write safety. You will want to choose, in advance, the core write safety. By default, MongoDB drivers use "Fire & Forget" mode which is fast but low safety. You probably want to use "Safe" mode or higher for anything that's not just logging. However, there are also mode to wait for journaling and wait for fsyncing to disk.
Research these modes in advance, they will have massive impact on your performance.
5. Start monitoring now. Take a look at tools like 10gen's MMS or ServerDensity. Without monitoring in place you will only know about perf problems after they happen and you will be flying blind. Start with Perf monitoring in place from day 1.
6. Look up the mongostat tool and learn how to read the output. This will be your primary debugging tool when something goes sideways.
7. Check all of your indexes in advance and avoid ad-hoc queries on large datasets. MongoDB is sub-optimal for ad-hoc unindexed queries. It has caps on the amount of un-indexed data it can sort and data can be non-contigous resulting in lots of disk seeks.

%3E ... particularly for queries that involve lots of documents

See point #7 above.

MongoDB is not optimal for doing "multi-document queries".

Think of it this way, MongoDB documents can be dispersed anywhere inside the set of DB files. Imagine that you have a query that returns 1000 documents and none of those documents are currently in memory (they're all in virtual memory, but not actually in memory). Those 1000 documents can all be on completely non-contiguous pages, so you can end up doing 1000 disk seeks to find your data.

From a performance perspective think of "multi-document queries" as "a series of key-value" lookups. It's not always this slow, but it can be, so you want to design accordingly.

Also if you are sharding, returning multiple documents means that queries can range over multiple servers which may not be optimal.

%3E I'm wondering what the best practices are for organizing documents so that querying is optimal?

1. Manage your indexes very carefully and limit queries only to things that are indexed.
2. Note that you can override the ID and often save yourself an index.I have often done this with some set of values that form a unique key. So I will have an ID like "20120405_FB_12345", which is easy to interpret and can even be used for range queries.
3. Leverage "sub-documents" when you don't need to query on the sub-document itself. Being able to get a document and its children is one of the key performance benefits of MongoDB as it can dramatically reduce query times.
4. Don't be afraid to de-normalize.

Anonymous · Answer

You can apply any hierarchical data modelling on MongoDB, as it is done on any relational db. Here are few methods illustrated :

An example hierarchical tree:

1) Storing references in the document.
a. Parent reference in the child node. {ele: "b", parent: ref_a}
b. Child node references in the parent node. {ele: "b", children: [ref_c, ref_e]}

Pros :  Easy to maintain tree modifications.
Cons :  Use recursion to get a sub-tree or get all parent nodes.

2) Storing the node path along with hierarchy level int the document.  
{ele: "a", path: "/a" , lvl:1} 
{ele: "b", path: "/a/b", lvl:2} 
{ele: "c", path: "/a/b/c", lvl:3}

Pros :  Easy to fetch a subtree of a given node. Traversing up a tree is not that difficult. Getting all parent nodes of c:db..find({"path" : {"$in" : ["/a", "/a/b"] } }).
Cons :  If hierarchical changes are frequent, then path update is needed but still easier than other models.

3) Nested Sets: Traverse tree in pre-order and number left and right edges of each node along with each node number.
{ele: "a", left: 1 , right: 10, n:1}
{ele: "b", left: 2 , right: 9, n:2}
{ele: "e", left: 3 , right: 4, n:3}
{ele: "c", left: 5 , right: 8, n:4}
{ele: "d", left: 6 , right: 7 , n:1}

Getting all child nodes of b:
db..find({left : { "$gt" : b.left}, right : { "&lt" : b.right}

Getting all parent nodes of c: 
db..find({left : { "$lt" : c.left}, right : { "&gt" : c.right}

Pros :  Easy to access a subtree. Easy to trace all parents.
Cons :  Difficult to maintain tree modifications.

4) If the tree is pretty much flat in shape, the you may consider nested documents
{dsg:"IT-MD" , name : "AA" , { dsg:"IT-Head" , name : "BB" , { dsg:"IT-Dev-Tester-Designer-Admin-Clerk-Poor-Fellow" , name : "CC" } } }

Pros :  If you access pattern is subtrees, then you can take advantage of caching and less lookups.
Cons :  Nested are not indexed.

Haris Amin · Answer

So I actually first used the Mongo Ruby driver for a pet project at the NYC Techcrunch Disrupt 2010 hackathon. I had a blast using it. Before then, I had been reading up a lot on Mongo but hadn't actually used it. Months after that I did a custom Rails quiz/questionnaire/postest app for tracking clinical trials. I used MongoMapper for that and have loved and used it since. Mongoid is cool, i did have a branch on that project that was using Mongoid instead. In my evaluation MongoMapper made more sense to me. It does stick veyr close to the ruby driver and I like how since version 0.8, there's a separate gem for querying which is designed specifically for querying MongoDB from the ground up. It wasn't an attempt to recreate activerecord or arel for querying Mongo.

So I definitely like that, and plus I actively follow the MongoMapper mailing list. Which is a great resource. Nunemaker and crew are working on the documentation efforts (which aren't as good as Mongoid) but really take one word of advice, read the specs in MongoMapper. They will answer a lot (if not most) of the questions you have about MM. Also, Kyle Banker, who is the author of the Ruby driver (and a really cool guy) seems to be more involved (or aware) of MM development than any other MongoDB ORM/ODM. So that's always a plus.

Scott McNulty · Answer

Understand your access patterns. Every CRUD operation your application will expect to do.

Avoid, like the plague, any kind of joins. Even basic ones inside your application. The exception being simple lookup table types stuff. Instead design around duplicating data.

Your access patterns come from your use cases. So you should carefully map out your use cases.

If it was going to be a join in a relational db, it needs to be a table/collection in mongodb.

You look at each use case and ask these questions:

How quickly must it complete?
How much data must it return?
How often will it be run?
What criteria will it use?
Does it need a transaction?

The last one can still be done. You just have to do it within a single record or you can’t have it be atomic.

Then you can start deciding what pieces of information go together, and what will have to be duplicated.

For example; if you have a student database and a use case that says you must be able to contact every student in a class when certain situations come up, such as a cancellation or a change in testing, or announcements. You then have to decide how they will be contacted and whether their contact information would be duplicated into the record for that class. Email or sms? Or both?

No doubt that will be infrequent. Once a week? Once a semester? Probably not something you should put as much thought in as something that is run twenty times a day per student. Like “what’s my schedule?”

You have the same db but you need to know what grade the student got for each class. You probably store the class and the result with the student record. You probably wouldn’t store every single test they took in the class with the student record but with the class record.

The short answer is use the above as ideas but apply your own common sense to what you are going to do.

John Nunemaker · Answer

MongoMapper sticks to the defaults recommended by 10Gen, as implemented in the ruby driver and is now the recommendation of 10Gen if you need more than the driver provides.

What it lacks currently in documentation (the tests are a great place to start) it makes up for in stability and predictability. It was born from an application (harmonyapp.com) and it will continue to be maintained and it's only going to get better.

Granted I am the creator of it, but those are my thoughts.

Krishna Raj Sharma · Answer

The multi-tenant application architecture can adopt one of three database architectures. The second option is to use the same database for all tenants, but give each tenant their own schema with individual tables.

Grouping means that a single instance of the software and its supporting infrastructure serves multiple clients. Each client shares the software application and also shares a unique database.

It is a common software architecture in cloud computing where a single software instance provides a service to multiple clients or "tenants". Lambda, a serverless technology provided by Amazon Web Services (AWS), is a notable example of multi-tenant software.

The multi-instance architecture is where multiple clients run their own separate instance of an application and an operating system that runs on a separate virtual machine, all on a common hardware platform.

Camille Roux · Answer

Mongoid - http://mongoid.org/

Art Kagel · Answer

This is like asking “What is the most efficient way to use an emery board nail file to tongue and groove an oak table top?” You are using the wrong tool for the job!

Relationships require …. wait for it ….. a Relational Database System. That is what it was designed to do! MongoDB was designed to maintain and query single monolithic, flexible schema, documents not relationships. Could it be done? Sure, and given enough years, you can use emery boards to tongue and groove that table top!

Gaëtan Gates Perrault · Answer

First, we need to think about this 500k number very carefully.

Here are some stats from the US census bureau: Statistics about Business Size (including Small Business) from the U.S. Census Bureau [ http://www.census.gov/econ/smallbus.html ]

If your client list included every company in America with 20+ employees, that would be roughly 500k to 600k different clients. Is that really your target for paying clients? Do you need to hit that number to be viable?

%3E Please i need a professional advice on the best approach to take for this system.

This really depends on your clients. Are you clients big companies? If you need to support a Fortune 500 company or a big bank, they will absolutely need their own hardware for reasons that have nothing to do with architecture or performance.

If your clients will vary dramatically in size, you will need to partition physical machines so that traffic from one client doesn't crush everyone else. And you'll need to partition machines to be able to manage DB connections correctly.

Managing 500k DB instances is a pain in the neck, but it is required in many cases. Of course, if you have 500k clients and they're paying you $10 / month, then you should have the money to pay for the people to make this happen :)

At then end of the day, there is no easy solution here. You will need to make partitioning decisions based on lots of factors that you're not talking about:
 * Data size
 * Data velocity
 * Data security
 * Connection management
 * Query speed
But you have make some trade-offs here and decide what you value. At some level, you're not going to manage 500k actual paying clients by yourself, so you should be asking the other experts on your team about the trade-offs they want to make.

Nuri Halperin · Answer

TL; DR: Sharding is the way to scale MongoDB.

Replica sets are for durability and availability - not scaling. In a replica set, any write would be applied to each of the members. So the workload doesn't decrease when you add more members. Read workloads don't typically “scale" either because sending a query to any node still competes with the same number of writes per second. Finally, the data size in each replica set member is exactly the same so you don't gain capacity by adding a replica set member.

Sharding distributes workloads across the farm. When you add a shard, the data is spread across more shards, and therefore the work each shard has to perform decreases. And since the data is spread across the shards, you gain capacity.

Mike Anderson · Answer

Hi, Thanks for the A2A!

First let me start off by saying I don’t use MongoDB, I use relational DB’s however I did some research and found out it really depends on the situation. How much data you have, how it is/should be organized it all is kind of situational.

I did find this though that may help you out: Mongodb: multiple collections or one big collection w/ index [ https://stackoverflow.com/questions/15314769/mongodb-multiple-collections-or-one-big-collection-w-index ]

and

What's wrong with just one collection? [ https://forums.meteor.com/t/whats-wrong-with-just-one-collection/5129/2 ]

It seem’s that mostly multiple collections is better on performance, however, again I dont have much experience with MongoDB or non relational DB’s

I hope this helps!

Ramon Tayag · Answer

@Multi-Tenant Data Architecture [ https://msdn.microsoft.com/en-us/library/aa479086.aspx ] describes three ways to make Multi-Tenant apps:

1. Shared DB, shared DB namespace (aka PostgreSQL schemas)
2. Shared DB, separate DB namespaces
3. Separate DBs

Especially when starting out, I am fond of #2. This is what the Apartment gem can do. My reasons are:

* The schema switching logic is not all over the place like it would be for shared namespace (#1). This lessens the possibility of wrongly creating code that fetches from the wrong schema.
 * You get to save on resources unlike having separate databases.
 * Because data is separated, it provides the flexibility to move to a tenant to a separate database.

I gave a talk on this a while back. I talked about the Apartment gem (influitive/apartment [ https://github.com/influitive/apartment ]), and my own very similar Storey gem (ramontayag/storey [ https://github.com/ramontayag/storey ]).

Good luck!

Peder Linder · Answer

I couldn't find any integration tools that didn't have too big drawbacks, so I had to come up with my own solution. Here is what I came up with.

I run both the main indexer and delta indexer continuously. The main indexer takes a long time to run (~2 h) and the delta indexer takes a few seconds depending on how many documents have been created since the last main indexer completed. I delete documents in the index by setting a deleted flag in the indexes. Thereby I have near real time indexing (except updates of the document data require a full main reindex).

My solution consists of five parts: 
1) Two daemons: main_indexer and delta_indexer. These just call the index_main and index_delta methods in the model class in an infinite loop.

2) A Thor class with these tasks: index_main, index_delta, xml_feed_main, xml_feed_delta. The first two work just like the daemons except only run once and they are use for setting up the indexes and for testing. The xml_feed tasks are called by the sphinx indexer and generate the appropriate feeds to be used by the sphinx xmlpipe2 utility.

3) An integer field called sphinx_id on the documents which is used as the document id in the sphinx indexes. This field is set during delta indexing.

4) Three global variables that i maintain in a mongodb collection called variables. 
- "sphinx_main_max_id" keeps track of the max sphinx_id of the main index,
- "sphinx_delta_min_id" keeps track of the min sphinx_id of the delta index
- "next_id" keeps track of what the next sphinx_id should be

5) Four public methods in the model: index_main, index_delta, xml_feed_main, xml_feed_delta. 
- The index_main method first executes the sphinx indexer for the main index. The sphinx indexer then executes xml_feed_main which outputs the appropriate xml and sets the "sphinx_main_max_id". The index_main metod then sets the "sphinx_delta_min_id" to be "sphinx_main_max_id" + 1. The delta_min_id has to be set after the indexer fully completes so that the delta indexer that runs in parallel does not exclude documents that are not yet picked up by the main index. 
- The index_delta method first loops through all the new documents that have a nil sphinx_id and updates this value. It then executes the sphinx indexer which calls the xml_feed_delta. The xml_feed_delta only includes documents that have a sphinx_id greater than or equal to the "sphinx_delta_min_id".

I use Riddle to communicate with Sphinx and Mongoid to communicate with MongoDB.

Any ideas for how this could be improved?

Atul Jain · Answer

What I've seen done, and what I currently use are embedded arrays with node id's in each document.
So document user1 has property groups: [id1,id2]
And document group1 has property users: [user1].  Document group2 also has property users: [user1].
This way you get a Group object and easily select all related users, and the same for the User.
This takes a bit more work when creating and updating the object.   When you say 2 objects are related, you have to update both objects.  
There's also a concept DBReferences in MongoDB and depending on your  driver, it'll pull referenced objects automatically when retrieving a  document

http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef

This is how some person documents would look in mongoDB [ http://mongodb.org ].

Modeling in relational database
In the past, I have modeled many-to-many relationships in relational databases using a junction table. A junction table is just the table that stores the keys from the two parent tables  to form the relationship. See the example below, where there is a  many-to-may relationship between the person table and the group table. The person_group table is the junction table.

Modeling in mongoDB
Using the schema-less nature of mongoDB [ http://mongodb.org ] and arrays, you can accomplish the same data model and create short  query times with the appropriate indexes. Basically, you can store an  array of the ObjectId’s from the group collection in person collection to identify what groups a person belongs to. Likewise, you can store an array of the ObjectId’s from the person collection in the group document to identify what persons belong to a group. You can also store DBRef [ http://www.mongodb.org/display/DOCS/Database+References ]’s in the array, but that would only be necessary if your collection names will change over time.

db.person.insert({  "_id": ObjectId("4e54ed9f48dc5922c0094a43"),  "firstName": "Joe",  "lastName": "Mongo",  "groups": [    ObjectId("4e54ed9f48dc5922c0094a42"),    ObjectId("4e54ed9f48dc5922c0094a41")  ]});

db.person.insert({  "_id": ObjectId("4e54ed9f48dc5922c0094a40"),  "firstName": "Sally",  "lastName": "Mongo",  "groups": [    ObjectId("4e54ed9f48dc5922c0094a42")  ]});

This is how some group documents would look in mongoDB [ http://mongodb.org ]

db.groups.insert({  "_id": ObjectId("4e54ed9f48dc5922c0094a42"),  "groupName": "mongoDB User",  "persons": [    ObjectId("4e54ed9f48dc5922c0094a43"),    ObjectId("4e54ed9f48dc5922c0094a40")  ]});

db.groups.insert({  "_id": ObjectId("4e54ed9f48dc5922c0094a41"),  "groupName": "mongoDB Administrator",  "persons": [    ObjectId("4e54ed9f48dc5922c0094a43")  ]});