Teradataとは

Teradataはペタバイト規模の、カスタマイズ性に優れたMPPデータベースソリューションです。30年以上にわたって続くTeradataは、極めて完成度の高い機能セットを備え、世界最大級の組織の最も厳しい要件にも対応します。シェアード・ナッシング・アーキテクチャが、Teradataをリニアな拡張性を持つパワフルなデータベースにしています。

Teradataは、これまで専用のハードウェアを用いてオンプレミスでインストールされてきましたが、最近になって新たに、AWSまたはTeradata独自のプライベートクラウドでのマネージドサービスとなるデータベース技術の提供を開始しました。

Teradataをデータベースとして選ぶ理由

プラットフォームの完成度

世界有数の歴史の長い最大のデータベースプロバイダーであるTeradataは、真に包括的な機能セットを築き上げており、ほぼあらゆるユースケースにも適合します。なかでも注目すべき特徴は、TeradataとHadoopに保存されたデータセットへのアクセスを可能にするフェデレーションレイヤーのTeradata QueryGridと、Teradataの強力なワークロード管理ソフトウェアの2つでしょう。

プラットフォームのカスタマイズ

Teradataはデータベースのソフトウェアとハードウェアを併せて提供しているため、ワークロードに応じて異なる幅広いセレクションからプラットフォームを選ぶことができます。つまり、各ユースケース向けに最適化されたハードウェアを簡単に選ぶことができるのです。

パフォーマンス

Teradataのいくつかの機能は、上手く導入すればTeradataを超高性能なデータベースにすることができます。たとえば、Teradataは行ストアと列ストアのハイブリッドな組み合わせを実装するため、ユーザーはデータを行と列のどちらのフォーマットでも保存できます。性能を高めるもうひとつの特徴に、最も頻繁にアクセスのあるデータをインメモリストレージにインテリジェントに読み込む機能があります。

Teradataが実際に役立つ事例

大規模なエンタープライズデータスタックに適合

Teradataのデータベースソリューションの真価は、大きなスケールでこそ発揮されます。Teradataの壮大な機能と統合性、並列処理性は、エンタープライズデータスタックにシームレスに適合し、多数のユーザーの利用に耐えるよう設計されています。

カスタムのデータスタックをゼロから構築

Teradataの完成度の高い機能セット、豊富なプラットフォームのオプション、オンプレミスでもクラウドでもホストできる特質を考えると、TeradataのRDBMSは、自分たちのデータスタックを完全にカスタマイズしたいと考え、そのスキルのあるデータベース管理者には最適でしょう。

料金に関する考慮事項​​​​​​​

Teradataの料金は、データベースのホスティングをオンプレミスにするかクラウドにするかによって異なります。クラウドにデプロイした場合、料金はホスティングのプロバイダ（AWS / Azure / Teradata IntelliCloud）次第になります。

Teradataオンプレミス

Teradataのオンプレミス料金データは、Teradataから購入した機器の種類、台数、容量にって異なります。具体的な料金の情報はTeradataのサイトには掲載されていません。

Teradata on AWS

Teradata on AWSはAWS Marketplaceで販売されており、Teradataのインスタンスの月額料金が見積もれる計算ツールが用意されています。料金は、機能セット、ストレージの種類、インスタンスの容量、ノードの数などに左右されます。AWSでは最大32ノードまで拡張が可能です。

Teradata on Azure

Teradata on AzureはAzure Marketplaceで販売されています。Azure marketplaceで提供されているプランは、1時間単位のプランのみです。TeradataはAzure Blob Storageと統合して、バックアップの管理や追加のデータを保管することもできます。Azureでは最大32ノードまで拡張が可能です。

Teradata IntelliCloud

TeradataはまたTeradata IntelliCloudという、プライベートクラウドでのフルマネージド型のソフトウェアとハードウェアのホスティングオプションを提供しています。料金オプションはTeradataの種類によって異なり、こちらで案内しています。Teradataがホスティングする同社のデータベースは充実した拡張性を備えています。

Teradataのアーキテクチャ

ほとんどのセルフマネージドMPPデータベースと同じく、Teradataもシステム内の複数のノードにストレージとコンピューティングを分散します。「シェアード・ナッシング・アーキテクチャ」として知られるこのアーキテクチャは、ノードにコンピューティング（CPUとメモリ）とストレージ（ディスク容量）の両方が含まれます。

Teradataのアーキテクチャはいくつかのコンポーネントで構成されています：

• パーシングエンジン（PE） -「リーダーノード」に似たパーシングエンジンは、ユーザーからリクエストを受け取り、ユーザーが供給するSQLを使ってクエリプランを構築した後、BYNETに分散します。
• BYNET - パーシングエンジンとノード（AMPと呼ばれる）間の通信エンジン。BYNETはPEからクエリプランを受け取り、どのAMPを使うべきか決定します。
• アクセスモジュールプロセッサ（AMPS） - AMPは分散テーブルの一部を含む「ワーカーノード」として機能し、各ディスクにあるデータのその部分に対してクエリを処理します。その後、中間結果をBYNET経由でPEに送り、そのデータを順次ユーザーへ送ります。

データの種類

Teradataはデータを、データ定義言語（DDL*）のテーブルに基づいて行または列のフォーマットで保存します。テキスト（区切り）ファイル、JSON、大きなキャラクターオブジェクト（BLOBおよびCLOB）、そして地理空間データから発生した表形式データ構造とネストされたデータ構造の両方を取り込むことが可能です。

*Teradataはテーブルストレージをどちらの方向（行または列）にでも向けられる一方で、コンピューティングの際には行方向のデータに対して動作します。そのため、列ベースのストレージからのパフォーマンス向上は通常、ネイティブの列指向データベースエンジン（Amazon RedshiftまたはVertica）に比べれば低くなりがちです。

推奨される最大データサイズ

Teradataは、オンプレミスの容量なら50ペタバイト以上に対応できます。同社のプライベートクラウドでも、オンプレミスのインストールを支えるものと同じハードウェアで動作するため、同等に近い拡張性が得られます。Teradataはパブリッククラウドの複雑さを解消する方法をまだ模索中なため、Teradata on AWSはシングルノードのクラスタとして最大48 TBのHDDストレージまでしかサポートできません（SSDストレージの制限はさらに低くなります）。

Teradataのデータベース管理

Teradataの導入

Teradataは、AWSやAzureにTeradataを導入する手順をステップバイステップで解説しています。Teradataのオンプレミスまたは同社のプライベートクラウドでの導入に関する詳細は、同社に直接問い合わせることをお勧めします。

Teradataはまた、同社のプラットフォームのセットアップをサポートする導入サービスも提供しています。

新規データの処理

データをTeradataに取り込む時は、標準SQLのCOPYを利用できます。量が多い場合は同社の専用ETLツール、Teradata Parallel Transporter (TPT) が必要になります。

メンテナンス

Teradataのハードウェアコンポーネントはフルマネージド対応ですが、テーブルのアーキテクチャとクエリの最適化についてはそうではありません。Teradataで想定するパフォーマンスを引き出すには、列のエンコーディング、パーティション分割、インデックス作成、統計を行う必要があります。なお、Teradataデータベースのチューニングには、一般的なMPPのチューニング戦略を応用することができます。

Teradataに関するファクト

Teradataは比類ない優れたEXPLAINプランを備えています。

データベースでEXPLAINプランを実行したことがあれば、それが技術的に複雑で、効果的に読み込むにはかなりのトレーニングが必要だと分かるでしょう。TeradataのExplainプランは人間が読み取り可能で、クエリの行き先を簡単に把握することができます。

以下は、TeradataのフルテーブルスキャンのEXPLAINプランの例です（Teradata Wikiより）：

EXPLAIN SELECT * FROM Emp_Table;

1. First, we lock a distinct SQL_CLASS."pseudo table" for read on a RowHash to prevent global deadlock for SQL_CLASS.Emp_Table.

2. Next, we lock SQL_CLASS.Emp_Table for read.

3. We do an all-AMPs RETRIEVE step from SQL_CLASS.Emp_Table by way of an all-rows scan with no residual conditions into Spool 1 (group_amps), which is built locally on the AMPs. The size of Spool 1 is estimated with low confidence to be 6 rows (342 bytes). The estimated time for this step is 0.03 seconds.

4. Finally, we send out an END TRANSACTION step to all AMPs involved in processing the request.
-> The contents of Spool 1 are sent back to the user as the result of statement 1. The total estimated time is 0.03 seconds.

If you see all-AMPs RETRIEVE by way of an all-rows scan in your plan, that means teradata is doing a Full Table Scan. So it is reading every row in the table.

一方、以下が<Postgresのドキュメンテーションの同じようなクエリのEXPLAINプランです。

EXPLAIN SELECT * FROM tenk1;

                         QUERY PLAN
-------------------------------------------------------------
 Seq Scan on tenk1  (cost=0.00..458.00 rows=10000 width=244)