![MDC Purpose ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
What's hot
What's hot (13)
Viewers also liked
Viewers also liked (8)
Similar to Multi-Dimensional Clustering: A High-Level Overview
Similar to Multi-Dimensional Clustering: A High-Level Overview (20)
Recently uploaded
Recently uploaded (20)
Multi-Dimensional Clustering: A High-Level Overview
- 1. Multi-Dimensional Clustering A High-Level Overview Zoran Kulina DB2 CE Kernel Development
Editor's Notes
- Multi-dimensional clustering (MDC) provides a way to cluster data along multiple dimensions. MDC is primarily intended for data warehousing and decision support systems, but it can also be used in OLTP environments. As the name implies, Multidimensional Clustering allows users to physically partition data into clusters or dimensions based one or more values. It is all about physically grouping together data which are related according to their dimension values. When data is inserted into MDC table, records having different dimension values are put into separate blocks. This way, each block contains data that has a particular combination of dimension values. This particular set of dimension values will ONLY be found in that block.
- Block A block is the smallest allocation unit of an MDC. A block is equivalent of extent (a consecutive set of pages on the disk). The block size determines how many pages are in a block. Block index The structure of a block index is almost identical to a regular index. The main difference is that regular indexes entries point to data rows, while block index entries point to extents. Because each block index entry points to an extent, whereas the regular index entry points to a row, block indexes are much smaller than regular indexes, while still pointing to the same number of rows. Block indexes, however, cannot enforce the uniqueness of rows. For that, a regular index on the column is necessary. Block indexes are system generated and cannot be dropped. (If block index gets corrupted it will have to be marked for recreation using the db2dart /MI option).
- Dimension block indexes are automatically created when the table is created. They cannot be dropped. However, they can be renamed (as a system generated name is assigned to them for you). They contain block identifiers (BID) that point to blocks of data (vs RIDs in regular indexes that point to individual rows of data). A composite block index will also automatically be created, containing all columns across all dimensions. It will be used to maintain the clustering of data during insert and update operations.
- Block Map is a control structure which contains information about the usage status of each block (e.g. free, in-use etc). One block map per table or partition is created. Status bits include: In-use - Block is assigned to a cell System – Reserve blocks Load - Block is recently loaded; not visible by scans Constraint - Block is recently loaded; constraint checking is required Refresh - Block is recently loaded; MQTs need to be refreshed Can be dumped using the db2dart /DM option
- A dimension is an axis along which data is organized in an MDC table. A dimension is an ordered set of one or more columns, which you can think of as one of the clustering keys of the table. Data having particular dimension values can be found via that dimension's axis in the grid. This cube is a way of presenting a logical view of how the data is organized in an MDC table having 3 dimensions.
- A slice is the portion of the table that contains all the rows that have a specific value for one of the dimensions.
- The highlighted cell contains all records that match the key (1997,Canada,yellow).
- All you have to do to create an MDC table is to define the dimension columns (or key definitions) using the ORGANIZE BY clause.
- DB2_MDC_ROLLOUT registry variable determines what kind of rollout deletion is used for MDC tables.
- Improved Query Performance Block indexes are much smaller than row-based indexes. They are smaller because they point to extents rather than rows. Smaller indexes mean faster index lookups. Also, because block indexes are smaller and simpler, they are less likely to get corrupted than row-level indexes. Data is guaranteed to be clustered. Data with particular dimension values are guaranteed to be found in a set of blocks that contain only records having those values. Clustering is automatically maintained over time by inserting into existing blocks that already contain the dimension values as the record being inserted. Reorg is not required to recluster data; however, reorg can still be used to reclaim space. A new feature in V9.7 (RECLAIM EXTENTS ONLY) allows users to reclaim space without taking the table offline and doing a full reorg. Prefetching is more efficient with MDC tables . Because the data is clustered by the dimension column values, all the rows in the fetched blocks pass the predicates for the dimension columns. This means that, compared to a non-MDC table, a higher percentage of the rows in the fetched blocks are selected. This translates into less I/O, which yields better query performance. Reduced logging Block indexes have much less overhead associated with them for logging and maintenance because they only need to be updated when adding the first record to a block, or removing the last record from a block. There is no update of the dimension block indexes on a table insert unless there is no space available in a corresponding block. This results in fewer log entries than when the table has row-level indexes, which are updated on every insert. When performing a mass delete on an MDC table by specifying a WHERE clause containing only dimension columns (resulting in the deletion of entire cells), less data is logged than on a non-MDC table because only a few bytes in the blocks of each deleted cell are updated. Logging individual deleted rows in this case is unnecessary.
- Reduced table maintenance Because blocks in MDC tables contain only rows with identical values for the dimension columns, every row inserted is guaranteed to be clustered appropriately. This means that, unlike a table with a clustering index, the clustering effect remains as strong when the table has been heavily updated as when it was first loaded. Thus there is no need to reorganize data for the purpose of reclustering. Reduced application dependence on index structures Because the dimensions in an MDC table are indexed separately, the application does not need to reference them in a specific order for optimum usage. When the table has a multi-column clustering index, in comparison, the application needs to reference the columns at the beginning of the index to use it optimally.
- Performance Although MDC is suitable for both environments, the DSS environment usually realizes greater performance gains. This is because the volume of data processed is generally larger and queries are more complex and longer running. MDC is very effective in that environment because it reduces the amount of I/O that is required to satisfy queries. The OLTP environment, however, is more dominated by intensive insert/update activity and rapid query response. MDC can improve query response times, but it can impact update activity when the value in a dimension column is changed. In that case, the row must be removed from the cell in which it currently resides and placed in a suitable cell. This might involve creating a new cell and updating the dimension indexes. Disk space An MDC table takes more space than the same table without MDC because extents may contain fewer values (due to clustering). In addition, more indexes are created. Table design To design an MDC table properly, one must analyze the SQL that is used to query the table. Improper design may lead to lots of wasted table space, resulting in much larger space requirements. For example, a key that yields too many distinct values may lead to many sparsely used blocks (due to too allocating too many blocks that are occupied by a single value) and no performance improvement.