Będę potrzebować kilku zapytań w formie „wymień wszystkie obiekty, w których jedną z nazw alternatywnych jest 'foobar'”. Oczekiwany rozmiar tabeli jest rzędu kilku milionów rekordów. Można do tego wykorzystać zapytania Postgres JSON, a także można je indeksować (np. Index For Finding Element w tablicy JSON). Jednak CZY NALEŻY to zrobić w ten sposób, czy jest to przewrotne obejście, które nie jest zalecane?
może być zrobione w ten sposób, ale to nie znaczy, że powinieneś. W pewnym sensie najlepsze praktyki są już dobrze udokumentowane (patrz np. używanie hstore vs używanie XML vs używanie EAV vs używanie oddzielnej tabeli) z nowym typem danych, który pod każdym względem i dla celów praktycznych (oprócz walidacji i składni) nie różni się z wcześniejszych niestrukturalnych lub częściowo ustrukturyzowanych opcji.
Innymi słowy, to ta sama stara świnia z nowym makijażem.
JSON oferuje możliwość korzystania z odwróconych indeksów drzewa wyszukiwania , w taki sam sposób jak hstore, typy tablic i tsvectors. Działają dobrze, ale pamiętaj, że są przeznaczone głównie do wyodrębniania punktów w sąsiedztwie (pomyśl o typach geometrii) uporządkowanych według odległości, a nie do wyodrębniania listy wartości w porządku leksykograficznym.
Aby to zilustrować, weź dwa plany opisane w odpowiedzi Romana:
- Ten, który wykonuje skanowanie indeksu przeszukuje strony dysku bezpośrednio, pobierając wiersze w kolejności wskazanej przez indeks.
- Ten, który wykonuje skanowanie indeksu mapy bitowej zaczyna się od zidentyfikowania każdej strony dysku, która może zawierać wiersz, i odczytuje je tak, jak pojawiają się na dysku, tak jakby wykonywał (a właściwie dokładnie tak) skanowanie sekwencyjne, które pomija niepotrzebne obszary.
Wracając do Twojego pytania:zaśmiecone i przewymiarowane odwrócone indeksy drzew rzeczywiście poprawi wydajność Twojej aplikacji, jeśli używasz tabel Postgres jako gigantycznych sklepów JSON. Ale nie są też srebrną kulą i nie zaprowadzą cię tak daleko, jak właściwy projekt relacyjny, gdy mamy do czynienia z wąskimi gardłami.
Podsumowując, w ostatecznym rozrachunku nie różni się to od tego, co otrzymasz decydując się na korzystanie z hstore lub EAV:
- Jeśli potrzebuje indeksu (tj. często pojawia się w klauzuli where lub, co ważniejsze, w klauzuli join), prawdopodobnie potrzebujesz danych w oddzielnym polu.
- Jeśli jest to przede wszystkim kosmetyka, JSON/hstore/EAV/XML/cokolwiek-co-sprawia-śnie-w-noc działa dobrze.
