Under Vantage MAPS Architecture, every table uses a map that specifies which AMPs store the rows of the table. The map associates each AMP with a set of hash values. For each row of a table with a PI or PA, the values of the index columns are combined and hashed. Based on the map, the resulting hash value determines which AMP gets the row.
Tables and join indexes are assigned a map either explicitly or by default when created. For tables with fallback, the primary and fallback copies of the row are stored on different AMPs in the map. Secondary index tables use the same map as their base (indexed) table.
- Contiguous map
- This is a type of map that includes all AMPs within a specified range. Vantage creates contiguous maps during a system initialization or reconfiguration. Contact Teradata Support for help with defining contiguous maps using the Configuration (config) and Reconfiguration (reconfig) utilities.
- Sparse map
- This is a type of map that includes a subset of AMPs from a contiguous map. Vantage provides two sparse maps you can use, and you can also create new sparse maps if you have appropriate database privileges.
See CREATE MAP .
Use the DBC.MapsVX view to see a listing of the maps that are available to you. Users with appropriate permissions can create new maps.
- Consider a table of 10 rows that uses a 1000-AMP contiguous map. A query requiring a full-table scan requires all 1,000 AMPs to attempt to read their rows. The 990 AMPs that store none of the table rows consume and waste system resources.
- Consider a table of 10000 rows on this map. While rows may be evenly distributed, each AMP has only about 10 rows. Having 1,000 AMPs reading and processing a small amount of data may be inefficient.
Sparse Maps and Table Colocation
Rows from tables that have the same PI or PA and that share the same contiguous map are distributed to the same AMPs. This is called table colocation. Colocation provides a performance advantage when tables are joined on their PI or PA columns, because the join processing for corresponding rows happens within the same AMP. This avoids the row replication and redistribution steps required if the corresponding rows from the different tables in the join were stored on different AMPs.
For tables using sparse maps, there is an additional requirement for joins to take advantage of colocation.
To create a sparse map, specify the parent contiguous map and the number of AMPs to include in the sparse map. The AMPs in the sparse map are a subset of the AMPs in the parent contiguous map. The specific AMP subset is variable.
Each table that uses the same sparse map may have its rows distributed to a different subset of AMPs. For example, if multiple small tables use the same single-AMP sparse map, not all data from these tables is distributed to the same AMP. This helps to avoid a skewed data distribution among the AMPs in the parent contiguous map.
Because tables using the same multiple-AMP sparse map may not be stored on the same subset of AMPs, even if these tables have the same PI or PA, their corresponding rows do not benefit from colocation during joins. You can force rows of frequently-joined tables to be distributed to the same subset of AMPs by specifying a colocation name when you associate the tables with the sparse map. The colocation name forces tables that use the same sparse map to be stored on the same subset of AMPs, providing the same performance improvement for joins that tables using the same contiguous maps have.
Tools for Managing Maps
Tables may remain fixed in size after creation and population, or may change frequently. A table must use a map with a number of AMPs appropriate to the table size, leading to an even distribution of the table rows among the AMPs in the map. Tables that use contiguous maps are managed by Vantage. Contiguous maps can be changed and created only during a system reconfiguration. However, tables that use sparse maps must be periodically reassessed to make sure they use a map appropriate for the current table size and anticipated growth.
- Teradata provides views and SQL procedures that allow you to manage maps from an SQL command line tool, such as Teradata Studio or BTEQ. The tools consist of two main groups of related procedures:
Procedure Type Description Advisor Analyzes user tables, optionally using information from DBQL-logged query plans, and makes recommendations about moving tables to new maps. Mover Uses the output of Advisor procedures to move tables to new maps. This process generates ALTER TABLE statements to assign different maps to tables, and can use multiple concurrent worker sessions to speed the process and maintain database availability for other tasks during the changes, with a minimal impact on system performance.
See Database Administration and Map Procedures .
- To determine what maps are defined on the system, query the DBC.MapsV or DBC.MapsVX views. See MapsV[X].