I'm currently speccing out the architecture for a project. Its on a fairly tight timeline, will need to support a few hundred thousand users fairly soon after launch, and its business logic and model are tied tightly to an extended tree structure. I know I can do this in Mongo in a variety of ways as listed in the documentation. The best seems to be a hybrid approach of a parent field + one of the following: materialized path or array of ancestors. Right now my test implementation is using an array of ancestors, with the array being populated with the ObjectIds of the related documents. On a sample dataset some of the query times are a tad higher than I would like, but still acceptable. Does anyone have any tips for optimizing this structure? I tried the full materialized path, but once my tree went past 10 or so levels performance really seemed to crash. All my test data sets were 500k documents. The other components that might be relevant is a web front-end powered by Rails, using Mongoid for the majority of the interface between Rails and Mongo.
Asked
Active
Viewed 220 times
1
-
sounds like you should take a look at other databases like http://www.orientdb.org/ – phoet May 06 '13 at 19:45
-
I took a look at OrientDB, it doesn't appear to be Ruby/Rails friendly off the bat which hurts. I've considered using a pure Graph DB like Neo4j for the relationships; however, it is well outside my team's skill set and we would like to use tools we are more familiar with. – loneaggie May 07 '13 at 17:19