Case Study: 1
Scenario 1
Background
You are developing a flight information consolidation service. The service retrieves flight information from a
number of sources and combines them into a single data set. The consolidated flight information is stored in a
SQL Server database. Customers can query and retrieve the data by using a REST API provided by the
service. The service also offers access to historical flight information. The historical flight information can be
filtered and queried in an ad hoc manner. The service runs on a Windows Azure Web Role. SSL is not used.
Business Requirements
A new data source for historical flight information is being developed by a contractor located on another
continent.
If a time zone is not specified, then it should be interpreted as Coordinated Universal Time (UTC).
When you upgrade a service from a staging deployment to a production deployment, the time that the service
is unavailable must be minimized.
The default port must be used for HTTP.
Technical Requirements
The existing sources of flight information and the mechanism of exchange are listed below.
Blue Yonder Airlines provides flight information in an XML file.
Consolidated Messenger provides flight information in a Microsoft Access database that is uploaded every 12
hours to the service using SFTP. The company uses port 22 for SFTP.
Margie’s Travel provides and consumes flight information using serialized ADO.NET DataSets. Data is
periodically synced between the service and Margie’s Travel.
Trey Research provides data from multiple sourcesserialized in proprietary binary formats. The datamust be
read by using .NET assemblies provided by Trey Research. The assemblies use a common set of
dependencies. The current version of the Trey Research assemblies is 1.2.0.0. All assemblies provided by
Trey Research are signed with a key pair contained in a file named Trey.snk, which Trey Research also
supplies.
The application specification requires that any third-party assemblies must have strong names.
Application Structure
********************************************************
DRAG DROP
Historical flight information data will be stored in Windows Azure Table Storage using the FlightInfo class as
the table entity. There are millions of entries in the table. Queries for historical flight information specify a set of
airlines to search and whether the query should return only late flights. Results should be ordered byflight
name. You need to specify which properties of the FlightInfo class should be used at the partition androw keys
to ensure that query results are returned as quickly as possible. What should you do? (To answer, dragthe
appropriate properties to the correct location or locations in the answer area. Each property may be used once,
more than once, or not at all. You may need to dragthe split bar between panes or scroll to view content.)
A.
Airline
B.
WasLate
C.
Flight
D.
Arrival
Explanation:
primari key: clave primaria y unica indica que no puede ver otro codigo de vuelo con el mismo codigo. si no era de manera unica.
I think the correct answer is ” Airline , Flight”.
Correct answer is ” Airline , Flight”.
I agree with Mat and Sunil because…
The Row key must be unique within the partition. So ‘flight’ is only valid answer for that.
Partitions affect performance, more partitions helps the load balancers allocate partitions to servers, so using ‘WasLate’ would create two partitons. That is not good. In this case, as part of the request filter will be the airline, it makes sence that this is in the PK of the data (PK is partition key concatenated with row key), it also gives us as many partitions as there are airlines (which helps performance), so the valid answer here for partition key is Airline.
question has requirement to provide fastest solution for current query. So if it is straight question the partition key should be WasLate
For a flexible system, probably airline and flight…but I think scbeast is right: If the goal is to find either the flights that were late or not then the partition should be wasLate.