PostgreSQL ali MongoDB: indeks obrne zmago med branjem in pisanjem

V lokalni primerjalni meritvi je PostgreSQL dosegel nižjo povprečno zakasnitev pri indeksiranem iskanju posameznega zapisa v vseh preizkušenih sklopih, MongoDB pa krajši povprečni čas množičnega vstavljanja v treh manjših sklopih. Za dokumentne podatke zato ni splošnega zmagovalca: odločitev je odvisna od tega, kaj aplikacija bere, kako piše in katere spremembe morajo uspeti skupaj.

Če aplikacija pogosto išče po lastnostih dokumenta in pri tem povezuje več evidenc, je PostgreSQL z relacijskimi stolpci in jsonb smiselno izhodišče. Če večinoma bere ali zapiše celoten samostojen dokument, je MongoDB lahko preprostejši model. Prednost pri eni vrsti operacije še ne napove hitrosti druge.

Meje objavljene meritve

Preizkus je uporabljal sintetične strukturirane zapise na enem računalniku. PostgreSQL jih je hranil v relacijski tabeli, MongoDB v zbirki dokumentov; merjena sta bila množično vstavljanje in indeksirano iskanje po identifikatorju. Pri največjem sklopu je imel PostgreSQL nižji povprečni čas pisanja, vendar je povprečje MongoDB močno zvišala ena posebej počasna ponovitev. Zato ta rezultat pove manj o običajnem času vnosa kot rezultati manjših sklopov.

Meritev ni preizkusila iste poizvedbe z indeksom in brez njega, zato iz nje ni mogoče izračunati učinka samega indeksa. Prav tako ni merila iskanja po jsonb, združevanja tabel, sočasnih uporabnikov ali transakcij med dokumenti. Opazovana sprememba vrstnega reda velja za primerjavo dveh preizkušenih operacij in podatkovnih modelov, ne za vsako aplikacijo, ki uporablja ti zbirki.

Oblika dokumenta določa možnosti poizvedovanja

Dokumentacija PostgreSQL za json in jsonb pojasnjuje, da json ohrani vhodno besedilo, jsonb pa ga ob vnosu razčleni v binarno obliko. Ta pretvorba vnos nekoliko upočasni, poznejša obdelava je praviloma hitrejša, jsonb pa podpira indeksiranje. Jsonb ne ohrani vrstnega reda ključev, odvečnih presledkov in podvojenih ključev, zato ni ustrezen nadomestek za izvirni zapis, kadar mora ta ostati nespremenjen.

Pri pogojnem katalogu izdelkov bi lahko PostgreSQL skupne podatke, denimo identifikator in kategorijo, hranil v stolpcih, lastnosti, ki se razlikujejo med kategorijami, pa v jsonb. Tak model omogoča, da dokumentne lastnosti sodelujejo z relacijskimi podatki o zalogi ali naročilu. MongoDB dopušča drugačno mejo zapisa: podatke, ki jih aplikacija navadno potrebuje skupaj, lahko vključi v dokument izdelka. To je uredniška presoja modela, ne rezultat navedene meritve, ki kataloga ni preizkusila.

Razlika postane pomembna, ko se spremeni vprašanje, ki ga aplikacija postavlja podatkom. Prikaz enega izdelka z njegovimi lastnostmi ni enaka naloga kot iskanje vseh izdelkov z določeno lastnostjo in hkratno preverjanje zaloge. Pri prvi nalogi je lahko priročen dokument kot celota; pri drugi je pomembno, kako so polja indeksirana in kako se povezujejo z drugimi evidencami.

Indeks skrajša iskanje, a podraži vnos

PostgreSQL lahko za jsonb uporabi indeks GIN, vendar je korist odvisna od pogoja v poizvedbi in izbrane vrste indeksa. Indeks za iskanje ključev in vrednosti ni samodejno najboljša rešitev za vsako filtriranje ali razvrščanje. Če aplikacija stalno išče po določeni lastnosti, mora indeks ustrezati prav tej poizvedbi; široko indeksiranje celotnega dokumenta lahko vzdržuje podatke, ki jih poizvedbe sploh ne uporabljajo.

Na strani pisanja ima indeks merljivo delo: MongoDB-jeva razlaga zmogljivosti zapisovanja navaja, da vstavljanje ali brisanje dokumenta posodobi ustrezne ključe v vsakem indeksu zbirke. Posodobitev dokumenta lahko poseže v del indeksov, odvisno od spremenjenih polj. Hitrejši množični vnos v objavljenem preizkusu zato še ne zagotavlja enake prednosti pri zbirki, ki za dejanske filtre vzdržuje več indeksov. Poštena primerjava mora vključiti indeksni nabor, ki ga aplikacija potrebuje med rednim delovanjem.

Pri transakciji šteje meja skupne spremembe

Pri prenosu med računoma morata zmanjšanje enega stanja in povečanje drugega tvoriti celoto. Razlaga transakcij v PostgreSQL opisuje, kako ukazi med BEGIN in COMMIT postanejo vidni skupaj, ROLLBACK pa njihove spremembe razveljavi. Relacijski model je zato naravno izhodišče, kadar poslovno pravilo pogosto poseže v več povezanih vrstic in mora ohraniti njihovo skladnost.

Dokumentacija MongoDB o transakcijah navaja, da je sprememba posameznega dokumenta atomarna in da so podprte tudi transakcije med več dokumenti, zbirkami in delci. Hkrati opozarja, da je porazdeljena transakcija običajno zmogljivostno dražja od zapisa enega dokumenta in ne nadomesti primernega podatkovnega modela. Pri izbiri MongoDB je zato pomembno, ali lahko podatki, ki se praviloma spreminjajo skupaj, smiselno ostanejo znotraj istega dokumenta. Kadar tega ni mogoče doseči, je treba v primerjavo vključiti dejansko transakcijsko obremenitev, ne zgolj čas samostojnega vnosa.

Odločitvena matrika za tri vrste podatkov

• Katalog izdelkov: MongoDB je kandidat, če aplikacija pretežno bere in posodablja celoten izdelek z različno oblikovanimi lastnostmi. PostgreSQL z jsonb je kandidat, če iste lastnosti pogosto sodelujejo v poizvedbah in spremembah drugih relacijskih evidenc. Dokumentacija potrjuje obe možnosti modeliranja, ne pa zmagovalca pri iskanju po dejanskem katalogu; tega določijo filtri, indeksi in razmerje med branjem ter pisanjem.
• Tok dogodkov: če so vnosi večinoma neodvisni, je MongoDB vreden preizkusa, saj je imel v manjših sklopih objavljene meritve krajše povprečne čase množičnega pisanja. To je sklep za opisano lokalno okolje, ne obljuba za vsak dogodkovni tok. Ko mora aplikacija dogodke pozneje hitro najti po različnih lastnostih, strošek potrebnih indeksov postane del iste odločitve.
• Finančna transakcija: PostgreSQL je razumno izhodišče, če ena operacija spreminja več povezanih zapisov in so relacije jedro modela. MongoDB ostaja možnost, kadar meja spremembe ustreza enemu dokumentu ali aplikacija uporabi transakcijo med dokumenti. Odločilno merilo je pravilna skupna potrditev pod pričakovano obremenitvijo; rezultat množičnega vstavljanja samostojnih zapisov na to vprašanje ne odgovori.

Preberite tudi:

• PostgreSQL ali MySQL: isti JSON zahteva drugačno indeksiranje
• Claude Sonnet ali Gemini Flash: hitrost in cena obrneta izbiro API-ja
• Ahrefs ali Semrush: 750 proti 500 ključnim besedam ne odloči vsega