2

I started studied MongoDB about 2~3 days ago, and I am feeling pretty happy about it :) However.. I do have some questions.. I already did some research, and they did not clarify much.. I am developing a browser game, and all databases were in MySQL, but I decided do migrate to MongoDB. But, well, to the questions.

1) In MySQL, I used to have a map table which had the fields *map_ndx*, column, row, terrain (terrain was a foreign reference to a terrain table). Basically, each *map_ndx* indicates a different map, and row and column represent their coordinates; terrain indicates like 'woods', 'desert', categorized on the other table. Now, on MongoDB, I have a map collection which has a field *map_ndx*, and embeds several tiles. Each tile have the fields col and row, and embeds a terrain. First of all, do you think this design is efficient for a map? I will do a lot of queries searching for "tile (x,y) on map z", for instance. Second, where do I place my indexes (such as row and column)? Do I place them in the tile collection, or in the map collection (using "index 'tile.row'", for example)? I ask this because on MySQL when I queried for "select * from maps where map_ndx=1 and row=1", I would have an answer instantly. On MongoDB, if I ask for "Map.where(:map_ndx => 1).first.tiles.where(:row=>1)" it takes almost a second to complete (obs.: that syntax there is for RoR, I am operating with mongoid)

2) In MySQL, I used to have a *global_units* table, which would have the description of several units, their attacks, defenses, costs, etc. And each player would have a *user_units*, which referenced that *global_units*, and informed the quantity of units the players had for this referenced *global_unit*. Now, on MongoDB, I considered embedding the *user_units* in the user collection, which seems the ideal. However, should I keep *user_units* only referencing *global_units*, or it would be best if *global_unit* was also embedded in each player's *user_units* collection? The problem is that I would have to access the units from *global_units* on other places, such as when the player is going to build them. Therefore, even If I had them embedded on the *user_units* collection, I would also need an exclusive non-embedded *global_units* collection, so I can access their information on other places. What is the best way out here?

I know these are very specific questions, but I would be glad if someone clarified those to me! Thanks in advance, Fernando.

FernandoH
  • 855
  • 1
  • 9
  • 17

1 Answers1

3

The question you're asking here is the complex "embed vs. reference" question. And the first problem is that there is no single correct answer here, it's a series of trade-offs. Sometimes it's better to reference, sometimes it's better to embed.

There's an answer here that details one example.

One of the big fundamental questions here revolves around "top-level" objects. Here's my personal rule of thumb:

  1. If an object is only useful in context of its parent, then you typically embed.
  2. If an object is useful without its parent, then you typically reference.

Question #2, I think you've found your answers here:

  • user_units is only useful in context of the user. If you're going to load the user, why not load the units at the same time.
  • global_units is useful without a user_unit context, so you probably want to reference. Sure you have a "global lookup" of units, but how many do you have? A few hundred? A few thousand? Do they all fit in memory?

So a user would have something like

{ _id: 'gates',
  units: { footman: 10, cannon: 3, horse: 5 }
}

That seems fine, if a user needs a new footman, is it really a hassle to look up the stats? Of course, if you really want to customize, you can store stats on my footmen if they're different.

Question #1: is a little dicier.

How exactly do maps relate to tiles? Does a single map contain many tiles? Are you comfortable building a hash table of tiles in a single map?

Here's what I'm seeing:

{ _id: 'map1',
  name: 'jungle',
  height: 20,
  width: 20
  tiles: { "0_0": { type: 'jungle' },
           "0_1": { type: 'jungle' },
           ...
           "19_19": { type: 'beach' }
         }
}

Notice how I'm not building an array of tiles, but an actual hashtable. I'm stuffing all tiles into one map and loading the whole thing into memory. Of course, this assumes that you want all tiles on a map.

I know your query looks at just a single row, but now it's a question of how often do you need a single row? Don't you generally need a square-like block of tiles?

Community
  • 1
  • 1
Gates VP
  • 44,957
  • 11
  • 105
  • 108
  • Thanks for your answers. Regarding #2, I guess I'll keep user_units embedded, referencing the global_units collection, indeed. Regarding #1, each map can have some thousands of tiles. I did not understand very well what you mean with a square-like block of tiles. I will have to access those tiles in 3 different ways, according to which operation I do: (i) access a single tile; (ii) access all map tiles; (iii) access a block of tiles which are in a certain distance from an origin. I think that I am not efficiently indexing those tiles by rows and columns; I have a slow response to fetch them. – FernandoH Jul 11 '11 at 02:06
  • obs.: my data structure was this: http://cl.ly/3x1Z1U1M2D402g3C3M0r Is the tiles array too ineffective? How to do it better? Thanks in advance! – FernandoH Jul 11 '11 at 03:18
  • So here's the problem you're facing. In MongoDB queries always return a document. Now you can limit the fields you return, but the server still has to load the entire `map` document into memory. At best you can save some bandwidth by transferring only the needed tiles. If you look at your structure, you have an array of objects. You cannot limit fields this way. With my version you can do `db.coll.find({_id:'map1'},{'tiles.0_1':1})` and return only that one tile. If `row`+`col` is unique, you can model it that way. Also it looks like the `terrain` object is heavily repeated, is this necessary? – Gates VP Jul 11 '11 at 07:32
  • I could also have a terrains collections, where I would have all those terrain information. But if I embed it as I am doing, won't I save a little of time? Or do you think it will be almost irrelevant? I am going to try your approach regarding the hashes, I just found it a little confusing because I am working with mongoid on RoR, and I did not find how to do it that directly, but there surely is a way! – FernandoH Jul 11 '11 at 18:07
  • ahw, I am experiencing this error now "Cannot serialize an object of class Tile into BSON.", when I try to use my previous Tile inside a Hash, instead of an array – FernandoH Jul 11 '11 at 18:43
  • Mongoid may not provide all of the low-level data access you require, you may need to drop down to the level of the Ruby driver and "roll your own" object. As to embedding terrain types, how many terrains do you have? If you only have say 100-200 terrain types, this probably belongs in an in-memory list somewhere. Sure it can be in the database, but the application will use this list so often, why make needless queries to the database? – Gates VP Jul 12 '11 at 03:43
  • I have no MongoDB experience, but from a web & game development standpoint, put all your tiles and units into memory, I assume you have only a handful of those. And put them into memcached if you can. Make them into singletons or factories, so you can do what @GatesVP said - `tiles: { "0_0": { type: 'jungle' }` and then just do `BackgroundImage = TileFactory->getTile('jungle')->getImagePath()` – analytik Dec 30 '11 at 09:59