Now that we have seen how QlikView works from the point of view of a business user, it is time to get a little more technical. Let's take an in-depth look at the various components that QlikView consists of.
One of the key elements of QlikView is that it utilizes an in-memory database. Compared with a disk-based database, this offers a great advantage when it comes to performance. While disk-access time is measured in milliseconds, RAM access time is measured in nanoseconds, making it many orders of magnitude faster.
"But hold on—" you may say, "my hard disk has much more space than I have RAM in my PC; won't that mean that I can only load limited amounts of data into memory?"
This is a very valid question. Fortunately, there are two factors which counter this potential problem:
Cheap memory and the advancement of 64-bit processors and operating systems: While 1 megabyte of memory, in 1957, would have cost a staggering US$ 411 million, nowadays, a gigabyte can be had for less than US$ 5 (source: http://www.jcmit.com/memoryprice.htm). Coupled with 64-bit operating systems, which can address much larger amounts of RAM than 32-bit systems (up to 2 terabyte on Windows 2008 R2), it is feasible and (relatively) affordable to load huge amounts of data into RAM.
Clever compression: QlikView utilizes some sophisticated compression algorithms (and some common sense, such as de-duplicating data) to significantly reduce the amount of memory that is required to store data. Typically, on-disk data is compressed to 10 percent of its original size when it is loaded into QlikView.
These two factors make it possible to create QlikView applications that contain hundreds of millions—even billions—of records.
While the in-memory database is excellent technology, it cannot function on its own. Functionally, data flows through QlikView in the following manner (also shown in the following image):
It starts with the source data. QlikView can load data from a large variety of sources, including ODBC, OLEDB, Flat Files (Excel, CSV, and so on), and XML. There are also many different connectors, ranging from big enterprise applications such as SAP, to social networks such as Twitter.
The data is loaded into QlikView using a load script. This script can be used to extract, transform, and load data into the in-memory data model or to store it to the disk in intermediary data files called QVD files.
Data in the in-memory database is stored in an unaggregated format, meaning all aggregations are calculated on the fly. This simplifies data modeling in QlikView, as there is no need for separate aggregation tables.
Selections made by the user automatically cascade throughout the entire data model and these changes are shown by QlikView's presentation engine.
QlikView applications can be presented in multiple clients. The Windows application we used earlier is an example of a client; other similar examples will be covered in the next section.
While QlikView deployments within an organization often start with a single (or few) local installations, they often do not stay that way. As the use of QlikView expands, keeping track of different versions, dealing with huge amounts of data, reloading and distributing applications, and making sure that only the right people have access to applications becomes increasingly hard when using only the Windows client.
Fortunately, QlikTech offers a large range of components which ensure that QlikView can scale from a local deployment on a laptop all the way to an enterprise-wide solution. These components can be classified into three classes (also shown in the following screenshot):
The Windows application we used earlier to navigate and analyse the data in Movies Database can not only be used to consume content, but it is also the main tool with which to create QlikView documents. As this book is focused on developers, this will be the main focus for the remaining chapters.
When QlikView deployments expand, it becomes impractical to update and distribute files manually. Also, data is loaded into RAM when using a local Windows application to open QlikView files. When working with huge amounts of data, each PC would also need a huge amount of RAM. This might work for developer PCs, but it is hardly a cost-effective solution to outfit each user in the organization with large amounts of RAM.
Fortunately, QlikView has three components to mitigate these potential roadblocks to broader adoption:
QlikView Publisher: This component can take care of reloading, reducing, and distributing the QlikView documents. Jobs can be scheduled or triggered by external events. When QlikView Publisher has not been licensed, QlikView Server can handle the task of reloading QlikView documents.
QlikView Server: This is a centralized server which can load QlikView documents into memory and allows clients to interact with these documents remotely by using one of the QlikView clients. In addition to providing a central place where documents are stored, this also has the advantage of clients not needing huge amounts of RAM and CPU cores. The clients do not need to load all of the data locally and the processing power of the server is used for calculating and aggregating data.
QlikView Access Point: This is a portal through which users can access their documents.
QlikView documents can be consumed in multiple ways. While this book mainly focuses on the QlikView Desktop Windows application, it is interesting to take note of the other possibilities for deployment:
Web browser—plugin or AJAX client: There are two options for consumption of QlikView documents via a web browser. The first option is an ActiveX plugin. While this plugin offers an experience that is closest to the native Windows application, it only works in Internet Explorer and requires the QlikView plugin software to be installed on each client PC. Because rolling out software to each client PC might not be practical, and because there are web browsers other than Internet Explorer, there is also a second option: the AJAX client. This client does not require any software to be installed and works with most modern browsers.
iPad and other tablets: Tablets can access QlikView by using the AJAX client in their browser. The AJAX client automatically detects when a tablet is being used and switches to a touch-enabled interface. This makes it possible to develop a single QlikView document which can then be rolled out to both regular computers and mobile devices.
iPhone, Android, and BlackBerry: Mobile devices with a smaller screen, such as most smartphones, can use a special version of the AJAX client: the Small Device version. Instead of displaying complete worksheets, which would be unreadable on a small screen, this client shows each of the objects (chart, table, and so on.) one by one.
QlikView Workbench and SharePoint Web Parts: Using QlikView Workbench, objects from QlikView documents can be embedded within .NET-based web solutions. The SharePoint Web Parts can be used to embed objects from QlikView documents into SharePoint sites.
PDF: In addition to all clients that allow interaction with the QlikView documents, and with an additional license, there is also an option to distribute static PDF reports from QlikView Publisher.
When going through this list of clients, you probably noticed that the AJAX client is the most versatile of all clients. While it hasn't always been that way, nowadays, the visual and functional differences between the AJAX client and the ActiveX client are small enough for the AJAX client to be considered the preferred client for consumption of QlikView documents by users.