Tile Request Cascade

Background

The development of MOL has required careful planning to deal with very large datasets, broad scalability requirements, and relatively minimal technology budget. Expert range maps require attention in each of these three areas. All range maps require high resolution information and the ability to explore quickly and pleasantly in a browser window. Some range maps will have high levels of requests (i.e. popular species ranges or individual species ranges embedded on external pages) and some range maps will be modified and updated frequently while others are rarely accessed. In order to deal with these requirements, we have begun development of the Tile Request Cascade.

Permanent Layers

1. All range maps are stored as SHP files in a spatial enabled database on the backend server.
2. All range maps are tiled for 5 zoom levels.  
3. Zoom and bounding box metadata is registered with the frontend server to be communicated to the user interface.

Request Cascade

The request cascade is meant to allow frequently or recently requested layers to be served using the fastest available methods, while rarely accessed layers will be stored in the most efficient manner. This balance will allow MOL to serve data rapidly while minimizing scalability costs. In the cascade, a layer request is made to the frontend server, following that request each of these stages is fired, if a tile is found it is returned to the client and the cascade ends.

1. Frontend checks for tile in Mamcache
2. Frontend checks for tile in Datastore
3. Backend checks for tile in Cache
4. Backend checks for tile in TileStore (technology undetermined, harddisk, couchdb, pg wkt)
5. Backend performs to BBox tile job for layer using Mapnik