Application Architectures - Introduction

Transcription

1 Application Architectures - Introduction Pages Introduction Case Monolithic Segmented by Detail Segmented by Subject Segmented by Detail & Subject Data Reduced Introduction The following pages outline several application architectures that can be deployed as part of QlikView solutions. There are many combinations of these techniques possible. This document only covers some of the possible solutions. Combining these techniques can provide high performing, massive scaling QlikView solutions. The document chaining concept included in many of these scenarios is also covered in the Document Segmentation.doc in the Enterprise Library. There are demo applications that utilize this functionality also in the Enterprise Library under the Development\Application Architecture topic. These pages are meant to help provide a backdrop for application architecture discussions related to enterprise deployments with QlikView. Author: BPN, QlikTech NA.

2 Application Architectures Case Application Case Below are some details about the solution. These form the basis for the different architecture scenarios on the subsequent pages. User Base Executives Business analysts Sales Operations Total Users: QlikView Server Single QVS server 8 CPU cores 64 GB Tabs included in the scope of the solution QlikView Data model (row counts shown on each table) 59 Expectations 18, ,232, Executives only need high level metrics Executives need fast response times BA s need most details and data Sales and Operations are mostly high level and reporting needs 12,

3 Monolithic - Single Document This scenario includes a single QlikView document called s Dashboard, which contains all subject matter in the data model across all 609 million rows of data. This would be a very large document and would provide the worst performance of the scenarios presented here. This would be the easiest to develop (single QV document) This would be the hardest to performance tune to meet the executives needs and also drill down to the transactional details that the business analysts sometimes need. Since the footprint of this application would be large, less capacity for concurrent would be supported than some of the subsequent scenarios. 0 Number of Users 80 Users 80 _Details 609,040,000 s Dashboard TOTAL USED: 108 GB

4 Segmented by Detail This scenario includes three QlikView documents called s Dashboard (1.8 million rows), s (46 million rows) and s Detail (609 million rows). The data model for these QlikView documents would be almost identical, though the granularity of the data would differ drastically. Notice the concurrency volume of goes down as drill from the dashboard to the analysis app and then again down to the details app. This is a normal distribution pattern for segmented documents. Supports a higher concurrency, since the smallest app is in memory with the most instances. Also has a high performance since smallest app is fastest. Need to build 3 QlikView documents with mostly shared code. 0 Number of Users 80 Summ 1,850,000 Users 24 s 46,000,000 Users 3 s Dashboard doc _Details s doc 609,040,000 TOTAL USED: 25 GB s Detail

5 Segmented by Subject This scenario includes five QlikView documents. The first one is the dashboard (5 million rows), and the next four are subjectoriented analysis applications, each having 50 million rows. The data model for the analysis applications would be very similar, but aggregated by different dimensions from the base data model. Aggregation of the four analysis applications could take place from a detailed set of QVDs, or the QVDs could be pre-aggregated and supplied to these analysis applications. Supports a higher concurrency, since the smallest app is in memory with the most instances. Also has a high performance since smallest app is fastest. Need to build 5 QlikView documents - mostly shared code. No detail transaction document. 0 Number of Users 80 Summ - bymonth 1,850,000 s Dashboard high low Users 6 Proftability Market Basket Users 8 Users 6 Product s

6 Segmented by Subject and Detail This scenario includes five QlikView documents. The first one is the dashboard (5 million rows), and the next three are subjectoriented analysis applications (50 million rows each), and the last one is the details application (600 million rows). The data model for the analysis applications would be very similar, but aggregated by different dimensions from the base data model. Aggregation of the three analysis applications could take place from a detailed set of QVDs, or the QVDs could be preaggregated and supplied to these analysis applications. Supports a higher concurrency, since the smallest app is in memory with the most instances. Also has a high performance since smallest app is fastest. Need to build 5 QlikView documents - mostly shared code. 0 Number of Users 80 Summ - bymonth s Dashboard 1,850,000 Users 4 high low Proftability Market Basket Users 8 Users 8 Product s Detail low high

7 Data Reduced This scenario includes two QlikView documents. The first one is the dashboard (5 million rows), and the next one is the region detailed analysis application (600 million rows). Each of the four regionalized versions shown at the bottom contain roughly 150 million rows. These are dynamically by QlikView, so there is no need to create each of the four applications. Only the dashboard and detailed analysis application are needed for development. The data model for the analysis apps is identical. Supports a higher concurrency, since the smallest app is in memory with the most instances. Also has a high performance since smallest app is fastest. No full detail transaction document, although the Region Detail app could be made available for this. 0 Number of Users 80 Summ - bymonth 1,850,000 s Dashboard high To each low s West Region s Midwest s Region Detail East Region Users 6 s South Region