Databases Reference
In-Depth Information
Understanding Your Performance
Requirements
If you didn't ask what your performance requirements were to start with, ask now! If you are interested in
following best practices, understand the application and the performance requirements of the database.
Are you dealing with more OLTP or OLAP requirements? All performance decisions are tradeoffs. You
can't make any performance decisions without understanding these requirements. The next few sections
will guide you through a set of questions that will give you a good grounding for the situation that you
are in. Most of these recommendations are focused on OLTP requirements that support the concepts of
normalization discussed in Chapter 8.
HowMany UsersWill theDatabase Support?
The number of users that a software product is designed to support is a critical design data point for
software development and is just as important for database modeling and support. The number of users
and the nature of how they will use this database will provide valuable clues about how resources will
be consumed in the database. Resource contention is typically the biggest issue that you are trying to
minimize when performance tuning any database after the fact. Spending time up front to understand
the user scale will provide some of this insight.
UserScale
A user scale describes a category of users that perform certain use cases in a system. A simple count of
the estimated users is not what you are interested in. You need to know which one of these three typical
user scale groupings you should anticipate as you approach designing from the start.
Mom and pop single user scale:
This user scale describes a single user performing sequential
actions dictated by use cases. The user need not be a human being. Automated services that
perform database activities should also be counted as a single user. If this is your only user scale,
you don't have too many distinct users, and you are not going to have to worry too much about
inter-user resource conflicts. This category is the most forgiving for bad design decisions.
❑
❑
Corporate user scale:
This user scale describes multiple users performing parallel actions. Here's
where you need to dig into what the users in this pool are doing. This can be done easily if you
are provided with the use cases defined by the software development processes. Understanding
the use cases helps determine how the data will proliferate into the system and provides insight
about what data flows occur in parallel, in serial, or in batch modes. The advantage to this group
is that the number of users is predictable. You should be able to plan and stress test existing
designs when users are increased.
Infinite user scale:
In this user scale, you have the same concerns as with the corporate user, but
the difference is that the number of users can't be predicted. You'll find this user scale around
web apps that are exposed on the Internet. This user scale requires extra thought and planning
to deal with the performance challenges of not being able to predict the loads on design patterns.
You'll find that programming to this user-scale is challenging and not many shops do this well.
❑
UserRolesorPersonas
A user role provides a model for the way a user will interact with the database. Alan Cooper in
The
Inmates Are Running the Asylum
introduces a similar concept of the persona for interface development.
Search WWH ::
Custom Search