Hive-indexering introducerades i Hive 0.7.0 (HIVE-417) och togs bort i Hive 3.0 (HIVE-18448). Läs kommentarerna i denna Jira. Funktionen var helt värdelös i Hive. Dessa index var för dyra för big data, RIP.
Från och med Hive 2.1.0 (HIVE-13290) Hive inkluderar stöd för icke-validerade primära och främmande nyckelbegränsningar . Dessa begränsningar är inte validerade, ett uppströmssystem måste säkerställa dataintegritet innan det läses in i Hive. Dessa begränsningar är användbara för verktyg som genererar ER-diagram och frågor. Sådana icke-validerade begränsningar är också användbara som självdokumentation. Du kan enkelt ta reda på vad som är tänkt att vara en PK om tabellen har en sådan begränsning.
I Oracle-databasen Unique backas PK- och FK-begränsningar med index, så de kan fungera snabbt och är verkligen användbara. Men det är inte så här Hive fungerar och vad den är designad för.
Helt normalt scenario är när du laddar mycket stor fil med semi-strukturerad data i HDFS. Att bygga ett index på det är för dyrt och utan index för att kontrollera PK-överträdelse är det bara möjligt att skanna all data. Och normalt kan du inte genomdriva begränsningar i BigData. Uppströmsprocesser kan ta hand om dataintegritet och konsistens men detta garanterar inte att du slutligen inte kommer att ha PK-överträdelser i Hive i någon stor tabell laddad från olika källor.
Vissa fillagringsformat som ORC har interna lättvikts-"index" för att påskynda filtrering och möjliggöra predikat-push-down (PPD), inga PK- och FK-begränsningar implementeras med sådana index. Detta kan inte göras eftersom du normalt kan ha många sådana filer som tillhör samma tabell i Hive och filer kan till och med ha olika scheman. Hive skapad för petabyte och du kan bearbeta petabyte i en enda körning, data kan vara semi-strukturerad, filer kan ha olika scheman. Hadoop stöder inte slumpmässiga skrivningar och detta lägger till fler komplikationer och kostnader om du vill bygga om index.