NOPI in Teradata
NOPI in Teradata
Teradata has introduced NOPI (NO Primary Index) in its V2R13
release. The purpose of this feature allows us to create tables
with no primary index in teradata is improved performance of
FastLoad and Teradata Parallel Data Pump Array INSERT data loading
operations.We can use this feature in creating staging tables in
any data warehousing project which is using Teradata as
database.
Syntax for NOPI table - CREATE TABLE
We can write the CREATE TABLE syntax with explicitly specified
NO PRIMARY INDEX clause in the CREATE TABLE statement. Below is the
example of one sample NOPI table- Table Sales_Tmp1 will be created
as a NoPI table.
CREATE MULTISET TABLE Sales_Tmp1, FALLBACK, NO BEFORE JOURNAL,
NO AFTER JOURNAL, CHECKSUM = DEFAULT ( ProductNbr INTEGER NOT NULL,
SaleDate DATE FORMAT 'MM/DD/YYYY' NOT NULL, ProductCount INTEGER)NO
PRIMARY INDEX;
We can create NOPI tables with using TABLE AS statement as shown
in the example below, table Sales_Tmp2 will be created as a NoPI
table. In this example, table Sales acting as the source table can
be a PI table or a NoPI table.
CREATE MULTISET TABLE Sales_Tmp2 AS (SELECT * FROM Sales)WITH
DATA NO PRIMARY INDEX;Advantage of NoPI Table-There are several
benefits in supporting a NoPI table:
As there is no primary index for the rows of a NoPI table, its
rows are not hashed to an AMP based on their primary index value.
Instead, Teradata Database either hashes on the Query ID for a row,
or it uses a different algorithm to assign the row to its home AMP
once it reaches the AMP onto which it has been FastLoaded. The
Teradata Database then generates a RowID for each row in a NoPI
table by randomly selecting an arbitrary hash bucket that an AMP
owns and using it to generate a RowID.The result is faster and more
efficient data loading. NoPI tables are also useful as so-called
sandbox tables when an appropriate primary index has not yet been
defined for the primary-indexed table they will eventually
populate. This use of a NoPI table enables you to experiment with
several different primary index possibilities before deciding on
the most optimal choice for your particular application workloads.
NoPI table can also be used as a Log file.
Limitations-Below list is for limitations and table attributes
that are not supported when creating a NoPI table:
NoPI tables cannot specify a permanent journal. NoPI tables
cannot specify an identity column. SQL UPDATE triggers cannot
update a NoPI table. SQL UPDATE and UPDATE (Upsert Form) requests
cannot update a NoPI target table. We cannot load rows into a NoPI
table using the MultiLoad utility. We cannot create Partitioned
Primary Index on NOPI table. We cannot create Hash Index on NOPI
table. We cannot create a NoPI queue table. We cannot create a NoPI
error table. We cannot create a NoPI table as a SET table. We
cannot create a NoPI table as Global temporary trace tables6.
We can define all of the following commonly used table features
for NoPI tables:
Fallback Secondary indexes Join indexes UNIQUE column
constraints CHECK constraints PRIMARY KEY and FOREIGN KEY
constraints Triggers BLOB and CLOB columns.
We can define any of the following table types as NoPI tables:
Ordinary base data tables Global temporary tables Volatile
tables
Changing NoPI table to PI table-Once NOPI table is created, we
can change this table to PI table. To change from a NoPI table to
PI table, we can run one of the following: CREATE TABLE AS - The
example shown below will create table Sales_Tmp_PI with primary
index ProductNbr and all of the data from NoPI table
Sales_Tmp1.
CREATE MULTISET TABLE Sales_Tmp_PI AS (SELECT * FROM Sales_Tmp1)
WITH DATA PRIMARY INDEX (ProductNbr);
CREATE TABLE and INSERT-SELECT - The example shown below will
create table Sales_Tmp_PI with primary index ProductNbr and then
copy over all of the data from NoPI table Sales_Tmp1.CREATE
MULTISET TABLE Sales_Tmp_PI, FALLBACK,NO BEFORE JOURNAL,NO AFTER
JOURNAL,CHECKSUM = DEFAULT(ProductNbr INTEGER NOT NULL,SaleDate
DATE FORMAT 'MM/DD/YYYY' NOT NULL,ProductCount INTEGER)PRIMARY
INDEX (ProductNbr);INSERT INTO Sales_Tmp_PI SELECT * FROM
Sales_Tmp1;We have facility to change from a PI table to a NoPI
table using one of the above approaches.
NoPI table as staging table-
The primary purpose of a NoPI table is to act as a staging
table. Users can populate data into a NoPI table via
single-statement INSERT or multi-statement INSERT. The latter can
be done with TPump Array INSERT which is more efficient and also an
alternative to FastLoad for staging a table.
The example below shows a single-statement INSERT into NoPI
table Sales_Tmp1:
INSERT INTO Sales_Tmp1 (100, '11/03/2008', 10);INSERT-SELECT
into a NoPI target table is also allowed. The source table can be a
PI table or a NoPI table.INSERT INTO Sales_Tmp1 SELECT * FROM
Sales;Considerations-When inserting data into a NoPI table we have
to consider below things-
Without a primary index, rows are not hashed based on any column
in a NoPI table. However, a rowid each row stored in a Teradata
Database table has a header that includes an identifier that is
unique to that row in the table. This identifier is called a rowid
that consists of a 32-bit hashcode and 32-bit uniqueness. For NoPI
table, the uniqueness part is extended to use 44 bits out of the
available 64 bits in a rowid. is still generated for each row in a
NoPI table. That is done by selecting a hash bucket in the hash map
that an AMP owns. The hash bucket is then used to generate a rowid.
This strategy helps make fallback and index maintenance very much
the same way as how they are handled on a PI table. For
single-statement INSERT and multi-statement INSERT, rows in a NoPI
table are sent to the AMPs through a random generator. This
generator is designed in such a way that for a new request, data
will generally be sent to a different AMP from the one that the
previous request sent data to. The idea is to try to balance out
the data among the AMPs as much as possible without the use of a
primary index.
For INSERT-SELECT into a NoPI target table, the SELECT part can
be a simple SELECT (retrieving all data from the source table) or a
complex SELECT (retrieving part of the data from the source
table).
For INSERT-SELECT into a NoPI target table, data from the source
table will not be redistributed and will be locally appended into
the target NoPI table. If it is a constrained SELECT from the
source table and data returned is skewed among the AMPs, the NoPI
table can become skewed since that same set of data is locally
inserted into the table.
