Hiveインデックスは、Hive 0.7.0（HIVE-417）で導入され、Hive 3.0（HIVE-18448）で削除されました。このJiraのコメントをお読みください。この機能はHiveではまったく役に立ちませんでした。これらのインデックスはビッグデータ、RIPには高すぎます。
Hive 2.1.0（HIVE-13290）以降 Hiveには、検証されていない主キーと外部キーの制約のサポートが含まれています 。これらの制約は検証されていません。アップストリームシステムは、データがHiveにロードされる前にデータの整合性を確保する必要があります。これらの制約は、ER図とクエリを生成するツールに役立ちます。また、このような検証されていない制約は、自己文書化として役立ちます。テーブルにそのような制約がある場合、PKと思われるものを簡単に見つけることができます。
OracleデータベースUniqueでは、PKおよびFK制約はインデックスで裏付けられているため、高速に動作し、非常に便利です。しかし、これはHiveの仕組みや設計の目的ではありません。
非常に通常のシナリオは、半構造化データを含む非常に大きなファイルをHDFSにロードした場合です。その上にインデックスを作成するのはコストがかかりすぎ、PK違反をチェックするためのインデックスがないと、すべてのデータをスキャンすることしかできません。また、通常、BigDataで制約を適用することはできません。アップストリームプロセスはデータの整合性と一貫性を処理できますが、これは、さまざまなソースからロードされたいくつかの大きなテーブルで、最終的にHiveでPK違反が発生しないことを保証するものではありません。
ORCなどの一部のファイルストレージ形式には、フィルタリングを高速化し、述語プッシュダウン（PPD）を有効にするための内部軽量「インデックス」があり、このようなインデックスを使用してPKおよびFK制約は実装されません。通常、Hiveの同じテーブルに属するそのようなファイルを多数持つことができ、ファイルは異なるスキーマを持つこともできるため、これを行うことはできません。 Hiveはペタバイト用に作成されており、ペタバイトを1回の実行で処理できます。データは半構造化でき、ファイルはさまざまなスキーマを持つことができます。 Hadoopはランダム書き込みをサポートしていないため、インデックスを再構築する場合は、さらに複雑でコストがかかります。