Skip to main content
Woohoo! Qlik Community has won “Best in Class Community” in the 2024 Khoros Kudos awards!
Announcements
Nov. 20th, Qlik Insider - Lakehouses: Driving the Future of Data & AI - PICK A SESSION
cancel
Showing results for 
Search instead for 
Did you mean: 
vkolasani
Contributor III
Contributor III

Qlikview Caching and real time data

I’d like to understand how frequent QV can be configured to ingest data into its in-memory data db/engine.  On the flip side, what are QV’s capabilities of forgoing it’s in-memory data engine in favor of accessing data in real-time.  Any drawbacks to this?


Thank you

1 Solution

Accepted Solutions
Peter_Cammaert
Partner - Champion III
Partner - Champion III

QlikView isn't meant to replace the operational dashboards or the direct data access screens of a large centralised application like CRM or ERP or a BigData cloud solution. QlikView is better at consolidating data from different sources and creating a consistent picture that is not necessarily a real-time snapshot. You can shorten the delay between data modification and the following update of dashboards in QlikView by devising a slick strategy to extract just the modifications from a large data set. But since QlikView is never embedded in the central data store or the transactional system, there will always be a data transfer & processing delay to take into account. And I think you can see it coming: the more data to update, the longer the delay.

I know of dashboards that take all of 2 minutes to update and whose reload runs in a closed loop ("continuously"). But I also know of dashboards that take 4 to 6 hours to update and tax the source systems in such a way that administrators prefer to refresh them at night only. Which isn't a problem at all.

There is one technique available that mimics a real-time extraction of source systems, but only for limited data sets (e.g. "get me the details of this transaction amongst a few billion"), not for entire reloads of large documents. It's called Direct Discovery and supports live data connections to data sources of choice. See: Direct Discovery - QlikView

Best,

Peter

View solution in original post

1 Reply
Peter_Cammaert
Partner - Champion III
Partner - Champion III

QlikView isn't meant to replace the operational dashboards or the direct data access screens of a large centralised application like CRM or ERP or a BigData cloud solution. QlikView is better at consolidating data from different sources and creating a consistent picture that is not necessarily a real-time snapshot. You can shorten the delay between data modification and the following update of dashboards in QlikView by devising a slick strategy to extract just the modifications from a large data set. But since QlikView is never embedded in the central data store or the transactional system, there will always be a data transfer & processing delay to take into account. And I think you can see it coming: the more data to update, the longer the delay.

I know of dashboards that take all of 2 minutes to update and whose reload runs in a closed loop ("continuously"). But I also know of dashboards that take 4 to 6 hours to update and tax the source systems in such a way that administrators prefer to refresh them at night only. Which isn't a problem at all.

There is one technique available that mimics a real-time extraction of source systems, but only for limited data sets (e.g. "get me the details of this transaction amongst a few billion"), not for entire reloads of large documents. It's called Direct Discovery and supports live data connections to data sources of choice. See: Direct Discovery - QlikView

Best,

Peter