JSONB z indeksowaniem vs. hstore

Na tym etapie próbuję zdecydować o projekcie bazy danych, przy możliwie jak najmniejszej liczbie założeń (dotyczących tego, jak faktycznie rozwija się aplikacja internetowa).

Pierwszym krokiem jest zrozumienie, że DOŁĄCZENIA są drogie, rozważam niewielką liczbę monolitycznych tabel w przeciwieństwie do dużej liczby znormalizowanych mniejszych tabel. Po drugie, jestem zdezorientowany między używaniem hstore a zwykłymi tabelami vs. JSONB (z indeksowaniem GiST).

AFAIK (prosimy o poprawienie):

1. Ogólnie w Postgres wiadomo, że hstore działa lepiej niż inne typy danych. Ta prezentacja FOSDEM PGDAY ma kilka interesujących statystyk (w drugiej połowie slajdów). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

2. Zaletą hstore jest szybkie indeksowanie (GiN lub GiST). Jednak w przypadku JSONB, indeksowanie GiN i GiST może być również stosowane do danych JSON.

3. Ten blog profesjonalisty z 2nd Quadrant mówi: „W tym momencie prawdopodobnie warto zastąpić używanie hstore jsonb we wszystkich nowych aplikacjach” (przewiń do końca): http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns /

Chciałbym więc zdecydować o następujących kwestiach:

1. W przypadku głównej (ustrukturyzowanej) części danych: czy powinna ona znajdować się w kilku relacyjnych tabelach (względnie duża z wieloma kolumnami), czy powinna to być pewna liczba sklepów z kluczową wartością przy użyciu hstore?
2. W przypadku danych ad hoc (przekazanych przez użytkownika / nieustrukturyzowanych) powinny one znajdować się w JSON lub w magazynach wartości kluczy ad hoc w hstore (z kluczami przechowywanymi w jednej z głównych tabel relacyjnych)?

Relacyjne bazy danych są zaprojektowane wokół sprzężeń i zoptymalizowane pod kątem ich dobrego wykonania.

Jeśli nie masz uzasadnionego powodu, aby nie używać znormalizowanego projektu, użyj znormalizowanego projektu.

jsonbi takie rzeczy hstoresą dobre, gdy nie można użyć znormalizowanego modelu danych, na przykład gdy model danych zmienia się szybko i jest zdefiniowany przez użytkownika.

Jeśli możesz to modelować relacyjnie, modeluj go relatywnie. Jeśli nie możesz, rozważ json itp. Jeśli wybierasz między json / jsonb / hstore, zazwyczaj wybieraj jsonb, chyba że masz powód, aby tego nie robić.

Tak powiedziałem w moim blogu , który dotyczy tylko tego tematu. Przeczytaj cały post . Cytowany akapit wskazuje, że jeśli wybierasz strukturę dynamiczną , powinieneś wybrać jsonb zamiast hstore, ale reszta posta na blogu mówi o tym, dlaczego zazwyczaj powinieneś modelować relatywnie, jeśli możesz.

Więc. Modeluj główną część strukturalną relacyjnie. Jeśli tabele są naprawdę szerokie z dużą ilością kolumn, może to oznaczać, że wymagana jest dalsza normalizacja. Nie bój się dołączeń. Naucz się kochać dołączenia. Dołączanie do wielu małych tabel często będzie szybsze niż wyszukiwanie i utrzymywanie dużych zdenormalizowanych tabel. Denormalizuj tylko wtedy, gdy jest to konieczne w określonych przypadkach, najlepiej za pośrednictwem zmaterializowanych widoków ... ale nie rób tego, dopóki nie dowiesz się, że potrzebujesz konkretnego problemu do rozwiązania.

W przypadku danych udostępnianych przez użytkownika, które są dowolne i nieustrukturyzowane, użyj jsonb. Powinien działać równie dobrze jak hstore, ale jest bardziej elastyczny i łatwiejszy w obsłudze.

Jedną istotną rzecz do zrozumienia: indeksy GiST i GIN, takie jak te stosowane w jsonb, są ogólnie znacznie mniej wydajne niż zwykły indeks b-drzewa. Są bardziej elastyczne, ale indeks b-drzewa w normalnej kolumnie prawie zawsze będzie znacznie, znacznie szybszy.