I am working with an GIS oganization within the Bureau of Indian Affairs to help set up a geodatabase for a potentially large national landbase and surveying system and we need some guidance as to how to allocate the physical storage of this data so that ArcMap does not potentially come to a crawl or lock up for our GIS users accessing this data in our regional offices.
This dataset is nationally a total of 700GB to a 1TB of GIS data consisting of 50 feature layers, all vector and no raster data comprised of 9 BIA national regions, containing anywhere from 30-50 reservations in this system. Of this data, 30 of these feature layers will be read only basemap data, whereas the other 20 layers are editable survey and cadastral data. We have a example dataset in-house for of this data for an "average" sized reservation which consists of about 500-800 MB which seems seems to work fine under a minimal local user load.
We are looking at serving this data up through either a set of MXDs exposed as ArcGIS services and/or a possble combination of other, possible custom GIS viewer technolgy options and for a workflow, we are looking at potentially anyway 2-5 GIS users per reservation hitting against this dataset concurrently using a combination of desktop and mobile cleint platforms, running ARcGIS 9.3 through 10.1 respectively against a backend ArcSDE 10.0 or 10.1 relational database (oracle or SQL server based on the stiping option selected)
The three main physical design options we are looking at is
1. The entire 700GB - 1TB dataset in one geodatabase.
2. One geodatabase for each of the 9 regions
3. An individual geodatabase for each of the 30-50 reservations
(some of the smaller and contiguous reservations could possibly be clustered into one geodatabase)
Unfortunately, we only have the one example dataset in house and do not have any load testing tools available to us at current to test the data loading further. We are finding plenty of PLSS and other types of survey landbase data model, domain and data storage option information out there but no large scale data storage topology or architecture information out there for this type of application that would be potentially useful for us.
Any thoughts on these architecture options for a potentially large landbase would be gladly appreciated.
James Fox
DBA (contractor)
Bureau of Indian Affairs- Division of Water and Power
Golden, Colorado
