ThinkGeo.com    |     Documentation    |     Premium Support

MsSQL2008FeatureLayer

#1

We are evaluating a method of loading shapefile features into a database so we can share the data between multiple applications and users easier than managing access to a shared shapefile.  What can we expect for performance drawing roads and features from a server compared to the shapefiles?  For instance, we have ~260,000 roads in the state we are loading into the database from the shapefile.  Will we get a markedly reduced performance attempting to go this route?  Has anyone else used a database to store a large number (100k+) shapes to be displayed on the map?



#2

Hi Jake, 
  
 Technically, SQL Server is little slower than shapefile; because we have optimized the ShapeFile a lot. But the SQL server doesn’t slower much. There are many variables to affect loading the data. Such as multiple app reading the same shape file might have conflicts. In this case SQL Server has a good supports on this. But Shape File is much stabler in our products, so we recommend using Shape File. To have a better performance, we’d like to recommend to split this Shape File by some condition and set a proper zoom level on different layer. 
  
 Hope it helpful. 
  
 Thanks and let me know if you have more queries. 
  
 Thanks, 
 Howard

#3

Jake, 
  
   I agree with most of what Howard is saying however to clarify our MS SQL support is stable.  I think what he meant was that more people use shape files versus SQL so he is more comfortable with the shape files as that is the majority of support questions we get. 
  
   The performance of MS SQL versus shape files has many layers.  The first is that shape files are local so they are faster from the standpoint of no network latency or transfer.  Shape files are also read directly from disk so there is not a general purpose parser like the SQL parser so that is a tab bit faster.  Local shape files have less contention for disk access since they are local.  A busy SQL server has to prioritize its disk ready based on how many clients are accessing it.  It is also hard to scale SQL Server beyond federation or more disks.  Besides those things the main difference resides in the index.  With shape files we use our own R-Tree index that we know is fast under a wide variety of conditions.  With MS SQL they have their own index scheme and the key is to have the right settings.  I am not an expert on these setting but in working with customers it makes the difference between good and bad performance.  The setting have to do with the kinds of tings are are storing.  Do you have all small things or some medium and small things or big, medium and small things etc.  Once you get the index right then you could have 1 million rows and it would be lightning quick to query 1,000 that are in a one mile area.  After the index is tweaked then the main difference is just network throughput and latency.  Just remember if you have a few milliseconds latency or transfer time that could double the render time versus direct disk access.  We have had customers get near shape file speeds using Postgre installed locally with their app.  It just goes to show that if you take the network out of the picture you get much better performance. 
  
   Another things to consider is that if you want to share the data between applications then you may want to consider our WMS Server product.  With our Wms Server you can isolate the rendering of various layer groups and have one set of servers store and render the data.  The rendered tiles are similar to Google’s tiling structure.  Once a tile gets generated it can be cached on the server, and client, so subsequent clients get the same tile without having to re-read or render the underlying data.  It is a very effecient system for lots of clients.  These servers can easily be load balanced using WMS clients by specifying multiple servers.  You can consume the tiles from anything that works with WMS which is almost everything 3rd party client out there and all of our products.  We also handle security, throttling, logging etc.  It is a great solutions for application that want to share maps internally or externally.  In that case you can still server the data via SQL or you could have the data in shapefiles on the WMS servers.  This is the same software we use for our maps.thinkgeo.com and it servers up millions of tiles with just a few machines and is really quick.   
  
 Let me know if you have any other questions. 
  
 David

#4

Thanks David, I would be interested in learning some more about the WMS server.  I will take a look at that product soon. 
  


#5

Jake, 
  
   Let me know if you have any questions after taking a look. 
  
 David