Page tree
Skip to end of metadata
Go to start of metadata

In the GoodData Platform, enterprise data is stored at the granularity of the source data. Records and transactions remain in their basic form in the GoodData datastore.

  • Input to the datastore supports both columnar and records-based interfaces, and partitioning is managed by data columns.
  • Interfaces are provided through an abstraction layer, so that developers do not need to interact or manage the physical schemas.
  • The framework for managing the structure of the datastore is available through CloudConnect, where developers build and publish the logical data model for each project. The LDM becomes the abstraction layer for interaction with the datastore.

Project data and metadata are stored in a multitenant, extensible data store that is easy to use and optimized for the GoodData Platform.

  • The platform provides optimized SQL. Query breakdown and normalization, SQL generation, and indexing strategies (subqueries, inlining, joins) are optimized for PostgreSQL and Vertica backends.
  • Users can define structures for performance optimization within the semantic layer, including pre-aggregated tables, specific data type selections, and logical model aspects (hints) for physical model generation.
  • Data backups are managed automatically within the platform.

Sizing

GoodData resolves resource sizing requirements for customers using the following parameters:

  • Concurrent usage: Total number of users and largest number of users per datamart
  • ETL frequency: Frequency of incremental and full data loads
  • Data increment size: Size of individual incremental loads
  • Total data size: In terms of GB, row count, and distribution among different datamarts, fact tables, and dimension tables.
  • Total ADS size: For Agile Data Warehousing Service implementations, data footprint including all solution-specific overhead such as projections and staging tables.

The above factors are combined together to determine the appropriate hardware, database solution, and other key implementation decisions.

In complex scenarios, a proof-of-concept solution can be deployed in a matter of days to validate the sizing requirements and other aspects of the implementation.

  • No labels