Ik heb een aantal vragen nodig in de vorm "lijst alle objecten waarbij een van de altnamen 'foobar' is." De verwachte tabelgrootte ligt in de orde van enkele miljoenen records. Postgres JSON-query's kunnen daarvoor worden gebruikt en het kan ook worden geïndexeerd (bijvoorbeeld Index For Finding Element in JSON-array). MOET het echter op die manier worden gedaan of is het een perverse oplossing die niet wordt aanbevolen?
Het kan op die manier worden gedaan, maar dat betekent niet dat u dat moet doen. In zekere zin is de best practice al goed gedocumenteerd (zie bijvoorbeeld hstore gebruiken versus XML gebruiken versus EAV gebruiken versus een aparte tabel gebruiken) met een nieuw datatype dat, in alle opzichten en praktische doeleinden (naast validatie en syntaxis), niet anders is van eerdere ongestructureerde of semi-gestructureerde opties.
Anders gezegd, het is hetzelfde oude varken met nieuwe make-up.
JSON biedt de mogelijkheid om omgekeerde zoekboomindexen te gebruiken , op dezelfde manier als hstore, arraytypes en tsvectors. Ze werken prima, maar onthoud dat ze in de eerste plaats zijn ontworpen voor het extraheren van punten in een buurt (denk aan typen geometrie) geordend op afstand, in plaats van voor het extraheren van een lijst met waarden in lexicografische volgorde.
Neem ter illustratie de twee plannen die het antwoord van Roman schetst:
- Degene die een indexscan doet ploegt rechtstreeks door schijfpagina's en haalt de rijen op in de volgorde die wordt aangegeven door de index.
- Degene die een bitmapindexscan doet begint met het identificeren van elke schijfpagina die een rij zou kunnen bevatten, en leest ze zoals ze op de schijf verschijnen, alsof het (en in feite precies hetzelfde is als) het uitvoeren van een reeksscan waarbij nutteloze gebieden worden overgeslagen.
Terugkomend op je vraag:rommelige en te grote omgekeerde boomindexen zal inderdaad de prestaties van uw app verbeteren als u Postgres-tabellen gebruikt als gigantische JSON-winkels. Maar ze zijn ook geen wondermiddel, en ze zullen je niet zo ver brengen als een goed relationeel ontwerp bij het omgaan met knelpunten.
De bottom line is uiteindelijk niet anders dan wat u zou krijgen als u besluit hstore of een EAV te gebruiken:
- Als het een index nodig heeft (d.w.z. het verschijnt vaak in een where-clausule of, nog belangrijker, in een join-clausule), wil je waarschijnlijk de gegevens in een apart veld.
- Als het voornamelijk cosmetisch is, werkt JSON/hstore/EAV/XML/whatever-makes-you-sleep-at-night prima.