Data Source Details
Use the following information when creating a data source for your Amazon Redshift database:
The JDBC URL must be in the following format:
Basic authentication is supported. Specify
If you use native authentication inside your cloud platform (for example, Google Cloud Platform, Amazon Web Services, or Microsoft Azure), you do not have to provide the username and password.
GoodData Cloud Native (GoodData.CN) uses the driver with version 184.108.40.2060.
GoodData.CN does not support the following features:
- Statistical functions:
- Statistical running functions:
- Period-over-period comparison with periodical date granularity (for example
- Window functions (running aggregations like
RUNVARP) with unbounded beginning of frames.
If your database holds a large amount of data, consider the following practices:
Denormalize the relational data model of your database.
This helps avoid large JOIN operations. Because Amazon Redshift is a columnar database, queries read only the required columns and each column is compressed separately.
- Use the columns that are most frequently used for JOIN and aggregation operations. Those columns are typically mapped to attributes that are most frequently used for aggregations in insights.
- If you have to build analytics for multiple mutually exclusive use cases, prepare a separate table for each use case.
Choose the best distribution style. At least, use a column with high cardinality so that loaded data is evenly distributed in your cluster.
Spin up databases/clusters based on user needs.
- Users with similar needs populate data into caches that are likely reused.
- Isolate data transformation operations running in your database from the analytics generated by GoodData.CN.
Because Amazon Redshift does not support partitioning, use a related
TIMESTAMPcolumn as one of the sort keys to improve performance of insights using only the recent data.
Query timeout is configurable per application instance. It is a parameter of the sql-executor service, default value is 160 seconds.
Query timeout is closely related to the ACK timeout. Proper configuration of the system requires that ACK timeout is longer than query timeout. Default ACK timeout value is 170 seconds.
NoteWhen a query fails on query timeout, the REST API call returns error code 500. Please note that this is subject to change in a future release.