Do you need that level of granularity or could you aggregate it to a higher level to reduce the amount of records?
Are all the columns required?
When you say it takes 12 minutes to render, is this after data has been retrieved? Or are you connecting live?
Unfortunately, this level of granularity is needed and yes all of these columns are needed (the table is actually 56 columns for which I need 29 of them). In an ideal world, I would be provided with dimension id's and dimension tables to blend inside of Tableau but this is not that case and my protestations to the contrary are falling on deaf ears which means a lot of unnecessary data being pulled from disc.
On rendering, currently connecting live so it takes a minimum of 12 mins for the query to return (worse in the afternoon) before the viz is rendered - apologies, that was misleading - and this is why I am looking at the extracts.
My thoughts are that they can be updated once, they would be significantly smaller but running from the beefy Tableau Server rather than the lower performing and heavier loaded db2 enterprise solution; it matters not to some degree how many users are opening the dashboard as they are not hitting the server; we can significantly reduce network latency as db2 (for updating) and Tableau Server are in Seattle whereas we are in London etc.
Essentially, I am using the benefits of the offline [type] extract and doing that which is not available to me for the server solution by breaking-down the table by [Segment_Name].
Are you proposing to create a separate extract for each segment just to speed it up or because you don't need data for all segments?
Why not just pull one extract of everything? Sure it would take more work upfront everyday, but once you've pulled it down all segments would be available.
Both but primarily from a speed perspective.
This book came to me to optimise and I have to admit that with such tight rules I am running into blockers. It was originally setup with the segment_name (segment) field as a context filter, the previous creator realising that this would significantly reduce the data being worked-on; the segments are used only to provide a basis for the viz so switching the segment only serves to adjust the view which is why in this instance I could ultimately get away with having a single extract per segment and a the same viz duplicated once per data-source.
I did originally look at loading all data into the extract; I had already been made aware by the head of data engineering that this had been tried but there was simply too much data to make this viable - tried this morning and got a rap across the knuckles as I was causing a bottle-neck and preventing other key areas from updating; also, given the way the data is coming in (from Hadoop) being processed through a convoluted etl process etc, incremental updates are unavailable meaning a full data refresh is needed each time.
So, this is what has brought me to what I perceive as being the only method left - individual extracts for each segment, individual viz's running from each extract and a parameter controlling which viz is in view