Indexování Hive bylo zavedeno v Hive 0.7.0 (HIVE-417) a odstraněno v Hive 3.0 (HIVE-18448) Přečtěte si prosím komentáře v tomto Jira. Funkce byla v Hive zcela zbytečná. Tyto indexy byly příliš drahé pro velká data, RIP.
Od Hive 2.1.0 (HIVE-13290) Hive zahrnuje podporu pro neověřené omezení primárního a cizího klíče . Tato omezení nejsou ověřena, nadřazený systém musí zajistit integritu dat před jejich načtením do Hive. Tato omezení jsou užitečná pro nástroje generující ER diagramy a dotazy. Také taková nevalidovaná omezení jsou užitečná jako sebedokumentování. Pokud má tabulka takové omezení, můžete snadno zjistit, co má být PK.
V databázi Oracle Unique jsou omezení PK a FK podpořena indexy, takže mohou pracovat rychle a jsou opravdu užitečné. Ale takhle Hive nefunguje a k čemu byl navržen.
Zcela normální scénář je, když načtete velmi velký soubor s polostrukturovanými daty v HDFS. Vybudování indexu na něm je příliš nákladné a bez indexu pro kontrolu porušení PK je možné pouze skenovat všechna data. A normálně nemůžete v BigData vynutit omezení. Upstream proces se může postarat o integritu a konzistenci dat, ale to nezaručuje, že nakonec nebudete mít porušení PK v Hive v nějaké velké tabulce načtené z různých zdrojů.
Některé formáty ukládání souborů, jako je ORC, mají vnitřní lehké „indexy“, které urychlují filtrování a umožňují predikátové posunutí dolů (PPD), pomocí těchto indexů nejsou implementována žádná omezení PK a FK. To nelze provést, protože normálně můžete mít mnoho takových souborů patřících do stejné tabulky v Hive a soubory mohou mít dokonce různá schémata. Úl vytvořený pro petabajty a můžete zpracovat petabajty v jediném běhu, data mohou být semistrukturovaná, soubory mohou mít různá schémata. Hadoop nepodporuje náhodné zápisy a to přidává další komplikace a náklady, pokud chcete indexy znovu sestavit.