Is there any documentation covering the pros and cons of using the above as a data source or rules of thumb when what source provides the best performance (and as a bonus factoring in 'cost' of maintaining data)?
Hi GIS Support,
Your question is pretty broad - what do you mean as a "data source"? In what context? For general data storage of GIS content, to be used by ArcGIS Desktop (ArcMap/ArcGIS Pro)? To support editing workflows for example? Or as a data source to power web services in ArcGIS Server? And for just data visualization or to support web editing workflows?
Enterprise geodatabases and file geodatabases are data storage options that can be used for GIS content to be used by ArcGIS Desktop. The former supports multi-user editing capabilities such as versioning and geodatabase replication. Both can also be used as "data stores" to power web services, but only enterprise geodatabases support web editing workflows.
Types of geodatabases—ArcGIS Help | ArcGIS Desktop
The ArcGIS Data Store is meant as a data storage option to support Web GIS, specifically in the context of an ArcGIS Enterprise base deployment (e.g., Portal for ArcGIS + Hosting Server + ArcGIS Data Store). It is used and managed by the ArcGIS Enterprise software to support the storage of hosted feature layers, scene services, and content generated by the Portal Map Viewer analysis tools. The ArcGIS Data Store is NOT a replacement of enterprise geodatabases.
What is ArcGIS Data Store?—Portal for ArcGIS (10.5.x) | ArcGIS Enterprise
Hope this helps,
Hi Derek Law
Thanks for the prompt reply.
My short answer would be that I was looking for the table in the first link, with an additional column for the Data Store.
A longer answer is that we do a bit of everything. We are starting (to try, in spare time) to look at system performance and an initial suggestion has been to move read only* data sets from the enterprise geodatabase to application specific file geodatabases. Or maybe make more tiles caches or vector tile caches. Or maybe more RAM. Ultimately will probably just have to time how the different options perform and then factor in the over heads for keeping everything up to date. Ideally some profiling before making structural changes.
*these bases datasets are updated at least weekly
Can I ask something similar: If I have over a million records, each with upwards of 60 attributes, is my best bet for maximum performance to use a spatiotemporal data store? If so, must I then deploy geoevent-server to get data into it, or is there another way? (my data isn't high throughput/streaming type stuff, it's small 50-100 batches of records inputted a few times a day)
Apologies for the late reply. I was out on vacation since Dev Summit 2019, then out on business travel.
> If I have over a million records, each with upwards of 60 attributes, is my best bet for maximum performance to use a spatiotemporal data store? If so, must I then deploy geoevent-server to get data into it, or is there another way?
Yes, the workflow you're proposing will require using either GeoAnalytics or GeoEvent Server to write to the spatiotemporal Data Store. There is no other way to write data to it. Sorry.
What are you looking to do with your data in the spatiotemporal big data store? Are you just looking for a data repository or to do analysis, or to create a feature layer from it, or other? How would you need new records to be added (and where are they coming from?)
It'd be ad-hoc analysis, most likely through Insights for ArcGIS or GeoAnalytics.
New records would come from other Enterprise GDBs, getting merged into this S/T datastore most likely using scripting and/or GeoEvent.
Thanks Andrew. Depending on where the data is coming from (if it's supported as input into GeoAnalytics analysis/tools), there's also the option of using the Copy to Data Store tool in GeoAnalytics. Or if it's GA analysis you're interested in, you could also keep the data in place so long as it's located somewhere that is supported by big data file shares.
We're looking at adding support for enterprise geodatabases as input for GeoAnalytics in the future. Feel free to email me if you have any requirements around this (hcurtis at esri).
Retrieving data ...