Database Reference
In-Depth Information
As you can see, managing exceptions can be a bit tricky. However, these exception helper classes
provide a good mechanism to store exceptions and return a collection of exceptions that the client code
can consume.
Managing Performance
So far, you've seen how the shard library works and how you can use it in your code. But it's important to
keep in mind why you go through all this trouble—after all, there is nothing trivial in creating a shard
library. This shard library does something important: it allows a client application to grow parts (or all)
of a database horizontally, with the intention of improving performance, scalability, or both.
What does this mean? It means the shard library can help an application keep its performance
characteristics in a somewhat consistent manner as more users use the application (scalability), or it can
help an application perform faster under a given load (performance). If you're lucky, the shard library
may be able to achieve both. However, this won't happen without proper planning. The shard library by
itself is only a splitter, in the sense that it spreads calls to multiple databases.
Shards don't necessarily help performance; in certain cases, a shard hurts both performance and
scalability. The reason is that a shard imposes an overhead that wouldn't otherwise exist. Figure 10-9
shows the difference between a standard ADO.NET call selecting records and best case and worst case
scenarios when fetching the same records from a shard. In the best case scenario, all records are
assumed to be split in three distinct databases; the shard is able to concurrently access all three
databases, aggregate the three resultsets, and filter and/or sort the data. The shard must then manage all
of the following, which consumes processing time:
•
Loops for connecting to the underlying databases
•
Loops for fetching the data
Data aggregation, sorting and filtering
In the worst case scenario, all these operations can't be executed in parallel and require serial
execution. This may be the case if the TPL detects that only a single processor is available. Finally, you
may end up in a situation that mixes worst and best case scenarios, where some of the calls can be made
in parallel, but not all.
•
