Indeksowanie Hive zostało wprowadzone w Hive 0.7.0 (HIVE-417) i usunięte w Hive 3.0 (HIVE-18448). Przeczytaj komentarze w tym Jira. Ta funkcja była całkowicie bezużyteczna w Hive. Te indeksy były zbyt drogie dla Big Data, RIP.
Od wersji Hive 2.1.0 (HIVE-13290) Hive obejmuje obsługę niezweryfikowanych ograniczeń klucza podstawowego i obcego . Te ograniczenia nie są sprawdzane, system nadrzędny musi zapewnić integralność danych przed załadowaniem ich do Hive. Te ograniczenia są przydatne w przypadku narzędzi generujących diagramy i zapytania ER. Również takie niesprawdzone ograniczenia są przydatne jako samodokumentowanie. Możesz łatwo dowiedzieć się, co ma być PK, jeśli tabela ma takie ograniczenie.
W bazie danych Oracle Unique, ograniczenia PK i FK są poparte indeksami, dzięki czemu mogą działać szybko i są naprawdę przydatne. Ale nie tak działa Hive i do czego został zaprojektowany.
Całkiem normalnym scenariuszem jest ładowanie bardzo dużego pliku z częściowo ustrukturyzowanymi danymi w HDFS. Budowanie na nim indeksu jest zbyt kosztowne, a bez indeksu sprawdzającego naruszenie PK możliwe jest tylko przeskanowanie wszystkich danych. I normalnie nie można wymusić ograniczeń w BigData. Proces nadrzędny może zadbać o integralność i spójność danych, ale nie gwarantuje to, że w końcu nie dojdzie do naruszenia PK w Hive w jakiejś dużej tabeli załadowanej z różnych źródeł.
Niektóre formaty przechowywania plików, takie jak ORC, mają wewnętrzne, lekkie „indeksy”, które przyspieszają filtrowanie i umożliwiają predykatowe naciśnięcie (PPD), żadne ograniczenia PK i FK nie są implementowane przy użyciu takich indeksów. Nie można tego zrobić, ponieważ zwykle możesz mieć wiele takich plików należących do tej samej tabeli w Hive, a pliki mogą mieć nawet różne schematy. Hive utworzony dla petabajtów i możesz przetwarzać petabajty w jednym przebiegu, dane mogą być częściowo ustrukturyzowane, pliki mogą mieć różne schematy. Hadoop nie obsługuje losowych zapisów, co zwiększa komplikacje i koszty, jeśli chcesz odbudować indeksy.
