Teradata

参考：Teradata RDBMS SQL Reference - Volume 2 Statement and Transaction Processing

ACID属性に関しては、上記のように全てサポートすると記載されている。

堅牢性やデータ容量別のラインアップとなっている。このブログでもDWHでの有用性を主張し続けてきたSSD版も有ります。

Teradataプラットフォーム・ファミリーより(http://www.teradata-j.com/product/hw/platform.html)

あらゆる分析ニーズに対応できるハードウェアをラインアップ
エンタープライズ・データウェアハウス分野で圧倒的な実績をもつ Teradataデータベースの機能を、最大限に引き出すプラットフォーム・ファミリーです。エンタープライズレベルからデータマートまで、お客様のデータ規模、分析、活用レベルに応じたデータウェアハウス構築が可能です。

OSはNovel SUSE Linux
（ExadataはOracle Enterprise Linux(Red Hatベース））

TeradataのJoinは基本的にはHash Joinだけ。OracleでサポートされているNested Loop Join(NLJ)やBit Map Joinなどはない。しかし、DWHとしてExadataを使う場合にNLJなどが動いてしまったら返ってマイナスに働く。そういった意味でDWHシステムではHash Joinのみを使う。

Join Index（参考資料：Teradata Database : Database Desigin(B035-1094-115A)）
TeradataのJoinはHash Joinのみだが、Joinした状況でCompressされたTableを持つ機能がJoin Index機能です。実態を持っているという点でOracleのMaterialized Viewと同じだが、TeradataではView名などを意識しないで自然にアクセスができる。

以下のようなJoin Indexを作っておくと：

CREATE JOIN INDEX cust_ord2
AS SELECT cust.customerid,cust.loc,ord.ordid,item,qty,odate
FROM cust, ord, orditm
WHERE cust.customerid = ord.customerid
AND ord.ordid = orditm.ordid;

以下のようなパターンはJoin Indexを使って処理される：

SELECT cust.customerid, ord.ordid, item, qty
FROM cust, ord, orditm
WHERE cust.customerid = ord.customerid
AND ord.ordid = orditm.ordid
AND cust.loc = 'WI';

Full Scan量を減らしてパフォーマンスを向上させるというのはTeradataもExadata同じです。

Multi-level Partitioningの例　Teradata Magazine-September 2008より

CREATE TABLE Sales
    (storeid INTEGER NOT NULL,
     productid INTEGER NOT NULL,
     salesdate DATE FORMAT 'yyyy-mm-dd' NOT NULL,
     totalrevenue DECIMAL(13,2),
     totalsold INTEGER,
     note VARCHAR(256))
UNIQUE PRIMARY INDEX (storeid, productid, salesdate)
   PARTITION BY (
      RANGE_N(salesdate BETWEEN
          DATE '2002-01-01' AND DATE '2008-12-31'
          EACH INTERVAL '1' YEAR),
      RANGE_N(storeid BETWEEN 1 AND 300 EACH 100),
      RANGE_N(productid BETWEEN 1 AND 400 EACH 100));

ExadatのHybrid Columnar Compression(HCC)とと呼ばれるカラム単位のCompress機能をTeradataではMulTi-Value Compressionと呼ぶ。また機能もExadataより多い：

１．Dictionary-based Compression
頻繁に登場するパターンをDictionaryで管理し実データを持たない。

CREATE TABLE Customer
(Customer_Account_Number INTEGER
,Customer_Name VARCHAR(50) COMPRESS 
(‘Joe’,‘Mary’)
,Customer_Address CHAR(200));

上記の例では一般的な人名のリストを同時に定義し人名の実データをレコードに持たせない。
これを応用すれば商品マスターなども持つ必要もなくなる。

２．Algorithmic Compression　　コンプレスアルゴリズムを設定する機能
繰り返し文字やブランクの数などが圧縮効率を左右してしまう。そこで、実データに適したコンプレス・アルゴリズムを明示的に指定し、圧縮率を上げることが可能となる。

CREATE TABLE Customer
(Customer_Account_Number INTEGER,
Customer_Name VARCHAR(50),
Customer_Address CHAR(200) CHARACTER SET UNICODE
COMPRESS USING TransUnicodeToUTF8 
DECOMPRESS USING TransUTF8ToUnicode);

上記の例ではUnicodeに適したアルゴリズムを明示的に指定することにより、Unicodeで成り立つカラムの圧縮率を上げている。

Exadata – the Sequel　Exadata V2 is Still Oracle(http://www.teradata.com/t/assets/0/206/276/5bfc4694-ce82-4a07-867d-3f104...)より

Shared Everything vs. Shared Nothing
Nothingというとネガティブな印象になりがちだが、けしてそういうわけではない。
TeradataはShared Nothing方式をとることによりI/Oボトルネックを防いでいる。

ExadataはASMにより均等にCellにデータを配置する。これをSAMEアーキテクチャ（Stripe And Mirror Everywhere(あるいはEverything))と呼ぶ。Parallel Queryは均等にストライプされたCellからReadするわけだから、Parallel Query Slave（下記の図ではWorkerと記述されている）同士でもI/O待ちは発生する。そして同時セッション数とI/O待ちが比例する。
数秒で終わるQueryでも数十分かかるQueryでも「全てのParallel Query Slave」が「全てのCell」を検索する。

There seems to be little debate that Oracle’s launch of the Oracle Exadata Storage Server and the Sun Oracle Database Machine has created buzz in the database marketplace. Apparently there is so much buzz and excitement around these products that two competing vendors, Teradata and Netezza, have both authored publications that contain a significant amount of discussion about the Oracle Database with Real Application Clusters (RAC) and Oracle Exadata. Both of these vendor papers are well structured but make no mistake, these are marketing publications written with the intent to be critical of Exadata and discuss how their product is potentially better. Hence, both of these papers are obviously biased to support their purpose. My intent with this blog post is simply to discuss some of the claims, analyze them for factual accuracy, and briefly comment on them. After all, Netezza clearly states in their publication: The information shared in this paper is made available in the spirit of openness. Any inaccuracies result from our mistakes, not an intent to mislead. In the interest of full disclosure, my employer is Oracle Corporation, however, this is a personal blog and what I write here are my own ideas and words (see [...]