Built from the ground up with the single goal of providing FAST web services for geospatial Big Data.
Architected for Web Services
CubeSTOR is a set of database extensions that work with MariaDB. It extends the database’s native geospatial capabilities to provide support for ingesting and managing large collections of geospatial data.
Because the CubeSTOR engine is an integral part of the Stratos Geospatial Platform, it was designed from the beginning to support web services, not just to be a repository of data. Every aspect of it’s architecture is influenced by this guiding ethic.
Built for Big Data
When we built CubeSTOR, we first thought of the “Big Data” problems in GIS, particularly big imagery, which has traditionally been a difficult problem for the incumbent technologies to solve. CubeSTOR handles big imagery with ease, without just throwing hardware at the problem. It can easily build and manage mosaics made up of hundreds of thousands of source images, using very modest computational resources.
Cloud Ready
CubeSTOR scales with your businessCloud Optimized Design
CubeSTOR supports direct access to data formatted as Cloud Optimized GeoTIFF and stored in cloud objects. Cloud Optimized GeoTIFFs (COGS) are optimized for random access via HTTP range requests or direct file reads. They include built-in multi-resolution image pyramids for rapid viewing. For data sets such as large mosaics, COGs are registered in the CubeSTOR database, but remain in cloud object storage. The database handles everything required to create seamless web maps from any number of source images.
Brings the Database to the Data
Unlike most most other solutions, CubeSTOR does not need to extensively reorganize or load your data into the database. Data sources like large aerial imagery archives are loaded by reference, from where they already exist in your network-attached or cloud storage. Indexes, image overviews and map tile pyramids are created and managed in the database. Data integrity is always maintained. A modification or deletion of a source file is detected the next time it is accessed, and everything in the database is updated accordingly. An automatic internal registry keeps track of exactly which map tiles etc are affected by any update.
This architecture makes updates and maintenance a breeze. It keeps the size of the database quite small, while allowing the amount of actual data managed to grow enormously. Data volume is no longer a limiting factor. Collections can scale to petabytes with little to no loss of performance or maintainability.