Databases Reference
In-Depth Information
As usual, the default Essbase setting for data load I/O,
Buffered I/O
, is more than
adequate for most data load operations.
Buffered I/O
takes advantage of the file
cache settings discussed earlier and only in cases where there is an extremely large
amount of data to load will it be noticeable that the system needs to swap in and out
of virtual memory.
The
Direct I/O
setting is best for extremely large data loads.
Direct I/O
bypasses the
cache and accesses system memory directly. If your system has lots of extra memory
available, this option can provide a real boost to the data loading performance.
Data compression can also be a factor in system performance and once again Essbase
has several options for you. Obviously, the
No Compression
setting can be the
quickest for I/O because there is no extra process time required to compress or
uncompress the data as it is read. This is not recommended at all because the size of
even an average database would grow to unmanageable proportions very quickly.
Can you guess what the best all-around compression setting is? Yes, it is the Essbase
default setting for
Bitmap encoding
, what else? Overall, this setting uses space the
most efficiently when compared to other available compression types and has a
lower than average I/O cost as well.
Essbase does offer
Run-Length encoding
as well, and this setting may be preferable
for databases that have very low block density. Of course, you will need to do some
experimenting to see if this type of data compression is right for your situation.
Lastly, Essbase offers you the choice of
ZLIB
compression.
ZLIB
compression can
be useful if the density of your data blocks is extremely high. Again, you will need
to experiment with this setting.
Partitioning databases
If you are at all familiar with database terminology, you know that partitioning
a database, either relational or multidimensional, is almost always done as a
performance consideration. In the relational database world, you are usually taking
one very large database and partitioning it into smaller, more manageable databases.
In the Essbase multidimensional world, there are several reasons for partitioning:
• To split a large, cumbersome database into smaller, more manageable
pieces or slices
• To create, in one database, selected pieces or slices of data from several
similar but unrelated databases
• To provide a consolidated look at an overall enterprise process
