It would be better if you knew what kind of change will be involved. If your world is quasi-static you would like to distribute the basic map to all your clients and to comunicate the changes only to player that visit an area: this allow you setup map distribution services that don't use the same bandwith of your game server.
In this case you can validate the client version at login and redirect the user to the map sources if major changes to maps where happened since the last login.
The story is completely different if the contents are fully user generated.
In both cases you have to split the world in chunks: you probably do not load the whole world in memory when you render it. Don't do the mistake to size the map chunks tailored to the client needs, changes to client should not affect the server: add a level of indirection, the client probably have to load a few of chunks to work smoothly.
If you are on the web and you like to let your users to generate a lot of content, you may try to use couchdb as database backend.
Using Couchdb you get a rest json based api, filtrable change notifications and using indexes you may look up the data fast.
The main advantages are the unstructured data and the near real time scalability.
The first one let you to add data in a way that client can process only if they know how to, backward compatibility or ligth/full compatibility for example; the latter let you build a system that can grow from a couple of user to thousands.
This comes at the price of system design, the changes need time to propagate and collisions may occour so you have to think about this kind of advanced problems in the earlier stages of design: is the game worth the candle?
Intermediate cases exists, here you can try to mix the two strategies up so if immutable or near-immutable content exists, you should separate it from the rest of the contents and distribute them in an appropriate manner, while using from semi-structured to structured data provider for the contents more subject to changes.