Native Support for Amazon Redshift Databases Coming to DevExpress Dashboards

DevExpress Data Blog
12 February 2015

Analyzing large amounts of data is rather difficult. We have added a number of features to make this much easier with our dashboard component. Coming in the next minor release we will add support for Amazon Redshift. The beauty of this addition is that there really isn’t much to do to hook up a dashboard to Redshift:

Data Provider Wizard

It is simply a new data provider that will be available soon!

Amazon Redshift Provider Parameters

Why The Fuss?

Great question! Amazon Redshift “is a fast, fully managed, petabyte-scale data warehouse solution that makes it simple and cost-effective to efficiently analyze all your data using your existing business intelligence tools” (emphasis added). In essence the DevExpress Dashboard Component can interact with a system that can potentially store petabytes of data and allow the type of analysis that can reveal real insight. Clearly there are memory limitations on the client, so how can this be accomplished? The key is in the amount of data that the dashboard needs to render the actual elements: it is generally much less than the whole data set on the server. In an earlier release we added Server Mode support to the dashboard. Let me show you how this works in the context of Redshift.

Consider the following dashboard (bound to a Redshift Database):

Amazon Redshift Bound Dashboard

In a traditionally bound dashboard, any filtering would trigger aggregations to happen on the web server (or client machine) directly in memory in order to return updated visualizations. In contrast, the server mode setting essentially “dumbs-down” the web server (or client) by offloading the filtering and aggregation to the provider (or database server). Any click to filter in the case of this revenue dashboard generated a query that was returned to the server:

Amazon Redshift Query Log

This is also the case for the Amazon Redshift provider! In fact, the query trace above was generated by exploring several different combinations of filters. Each time a filter was set, a new query was generated and sent back to the provider.

A Word on Speed

As you peruse the log of queries issued back to Redshift, notice that we are completely at the mercy of the database provider. In other words, we can only render the dashboard elements as fast as the data is returned (notice a couple of queries took ~3s to complete). Please use common sense and best practices for optimizing query speed in order to reduce refresh latency of dashboard elements.

We are very excited about this new addition!

As always, if there are any comments and/or questions, feel free to get a hold of me!

Seth Juarez
Email: sethj@devexpress.com
Twitter: @SethJuarez

3 comment(s)
Jonatas Hudler
Jonatas Hudler

I think this is a great addition. Event better would be if we could bind an IQueryable object (or any other object that we could parse the dashboard criterias) as the dashboard source. There are lots of real-time analytics databases emerging (MonetDB, MemSQL, VoltDB, VectorWise, Hive) as alternatives to this exact case - it seems reasonable to give developers options to non-standard alternatives.

12 February, 2015
Seth Juarez (DevExpress)
Seth Juarez (DevExpress)

Jonatas:

 The great thing about this particular addition is the fact that our dashboard component leverages what we call internally our "data access API and tools." Our goal is to eventually have all of our complex bound controls use this API in order to have a consistent feel when it comes to accessing and shaping data. This means that this (and other data access innovations) will be immediately available to all controls that use the interface. I think this makes this all doubly exciting.

-Seth

12 February, 2015
Mike Littlewood
Mike Littlewood

Will this connection type be available for the VCL as well?

5 October, 2016

Please login or register to post comments.