Design a partition structure that supports the quick loading and scale-out of data

-
Scaling-out the data refers to the mechanism put in place to spread the processing of data
across as many servers as necessary to improve querying and data loading performance. It should not be confused with scaling-up, which refers to increasing the resources of a server, such as CPU and memory resources. Scaling-up is usually the initial step towards scaling a database. As resource utilization demand increases, additional hardware, such as processing power and memory, can satisfy this need.

 There are several factors that can dictate what data scale-out solution can be implemented. The first factor depends on how often data changes. If data changes frequently certain scale out solutions that require data replication might not work because data contention might increase. Data that is inserted or updated frequently needs to be constantly replicated across multiple databases. The cost of replicating changes might be too high and degrade performance instead.

 A second factor to consider is the ability to implement a scale-out solution that is transparent to the user or reporting applications. Some scale-out solutions might require changes to table relationships, stored procedures, and the way user queries are written. Certain reporting applications might not be able to support a scale-out solution that requires executing distributed queries or querying linked servers.

 A third factor is the ability to partition the data in a way that aligns to typical query patterns. An effective scale-out solution involves partitioning data across several databases located on separate servers to handle queries that require a portion of the data. For example, data that is partitioned by customer geography, where each database on each server contains only customers from a region such as North America or European regions, works if all queries filter on region. If the queries typically select customers and their transactions across regions, this partition strategy does not work because it requires that all databases across all servers be queried.

 In this last case, no performance benefits can be observed from partition elimination because no databases are eliminated from the query execution plan. There might still be a performance benefit from this scale-out solution if the combined processing power of all servers exceeds the added processing overhead of assembling the results.

 A fourth and last factor in the type of scale-out solution that can be implemented is the interdependence of the data. In this scale-out solution, data is split based on how data is typically related and used within areas of the database. For example, fact tables use foreign key relationship constraints to enforce referential integrity. A partition strategy that involves splitting dimension and fact tables on different databases does not work in this case because referential integrity enforcement across databases is not supported. A better partition approach is to group related tables together that only relate to each other and don’t have relationships to the rest of the data model. This group of related tables that are isolated from the rest are often referred to as data marts.

 There are many options to scale-out the data, but the six more frequently implemented scale-out solutions involve the following mechanisms:

  1. Allowing multiple database engines to access a single copy of the database.
  2. Replicating the database to multiple database servers.
  3. Implementing linked servers and executing distributed queries.
  4. Implementing distributed partitioned views.
  5. Routing queries to the correct database using some middleware service.
  6. Implementing a stretch database with Azure.

Comments

Post a Comment

Popular Posts

Non-blocking, semi-blocking, and blocking transforms in SSIS

-
Not all Data Flow transforms are created equal. In fact, some are much faster and require a  lot less memory (non-blocking transforms). Others are slower while consuming much more  memory (blocking transforms), and some are in between (semi-blocking transforms). We don’t  always have a choice if we need to use a certain transform to do a certain specified task, but  it is good to know the differences between these types of transforms so that we can better  understand performance and resource utilization issues. Synchronous and asynchronous There is another related aspect about Data Flow transforms, which is their ability to quickly  process a row as they are coming into the transform, independently of any other rows that  came before or after (synchronous transforms). The other type of transform needs to be  dependent on some or all of the rows that come before and after (asynchronous transforms). On the whole, non-blocking transforms are also synchronous, thus are fast and
Read more

Implement additive, semi-additive, and non-additive measures

-
Additive Additive measures are numeric values that can be summed up by all the dimensions in the  fact table, for example the Sales Amount. These are the most common measures and they are  the easiest to understand and implement. Semi-additive Semi-additive measures are numeric values that can be summed up by some dimensions  in the fact table, but not all. In most cases, they can be aggregated by any other dimension  except time.  An example of a semi-additive measure is Account Balance. You can determine  the ending balance of an account at the end of a month, but adding up these monthly account  balances do not make sense. Semi-additive measures are usually found in fact tables that store  periodic snapshots of data. Non-additive Non-additive measures, as the name implies, are measures that cannot be summed up.  These measures include percentages such as Discount Percent, ratios such as Profit Margin, and  averages such as Average Unit Cost. Exam 70-767
Read more

Design an appropriate storage solution, including hardware, disk, and file layout

-
Image
The data warehouse storage’s performance can be measured by  analyzing the time it takes for read and write operations to complete, known as latency , and by  analyzing how much data volume it can read or write in each time frame, known as throughput .  High latency and low throughput can be an indication of an improper selection for the  storage infrastructure or incorrect hardware and software configurations. Performance of a storage subsystem can  be estimated based on several criteria: Volume of data Rate of change and growth of the data Data retention policy Number of concurrent users Typical workloads expected Two important metrics associated with storage are throughput and Input/Output Per  Second (IOPS) . Throughput is a measure of the amount of data that can be transferred in a  period. This is typically measured in megabytes or gigabytes per second. IOPS is the number of  I/O read or write operations that can complete in a second.  It is important
Read more