Pengindeksan Hive diperkenalkan di Hive 0.7.0 (HIVE-417) dan dihapus di Hive 3.0 (HIVE-18448) Silakan baca komentar di Jira ini. Fitur ini sama sekali tidak berguna di Hive. Indeks ini terlalu mahal untuk data besar, RIP.
Mulai Hive 2.1.0 (HIVE-13290) Hive menyertakan dukungan untuk batasan kunci utama dan asing yang tidak divalidasi . Batasan ini tidak divalidasi, sistem hulu perlu memastikan integritas data sebelum dimuat ke Hive. Batasan ini berguna untuk alat yang menghasilkan diagram dan kueri ER. Juga kendala yang tidak divalidasi seperti itu berguna sebagai pendokumentasian sendiri. Anda dapat dengan mudah mengetahui apa yang seharusnya menjadi PK jika tabel memiliki batasan seperti itu.
Dalam database Oracle Unique, batasan PK dan FK didukung dengan indeks, sehingga mereka dapat bekerja dengan cepat dan sangat berguna. Tapi ini bukan cara kerja Hive dan untuk apa Hive dirancang.
Skenario yang cukup normal adalah ketika Anda memuat file yang sangat besar dengan data semi-terstruktur dalam HDFS. Membangun indeks di atasnya terlalu mahal dan tanpa indeks untuk memeriksa pelanggaran PK hanya mungkin untuk memindai semua data. Dan biasanya Anda tidak dapat menerapkan batasan di BigData. Proses upstream dapat menjaga integritas dan konsistensi data tetapi ini tidak menjamin Anda akhirnya tidak akan memiliki pelanggaran PK di Hive di beberapa tabel besar yang dimuat dari sumber yang berbeda.
Beberapa format penyimpanan file seperti ORC memiliki "indeks" internal yang ringan untuk mempercepat pemfilteran dan mengaktifkan predicate push down (PPD), tidak ada batasan PK dan FK yang diimplementasikan menggunakan indeks tersebut. Ini tidak dapat dilakukan karena biasanya Anda dapat memiliki banyak file seperti itu yang termasuk dalam tabel yang sama di Hive dan file bahkan dapat memiliki skema yang berbeda. Hive dibuat untuk petabyte dan Anda dapat memproses petabyte dalam sekali jalan, data dapat semi-terstruktur, file dapat memiliki skema yang berbeda. Hadoop tidak mendukung penulisan acak dan ini menambah lebih banyak komplikasi dan biaya jika Anda ingin membangun kembali indeks.
