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?
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
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
