index ili tablica za situaciju

[bozoou]

Pozdrav,

imamo recimo tablicu "oglas" koja ima veliki broj unosa. Recimo 1 000 000+
I sada želimo recimo cca 10 oglasa iz te tablice posebno označiti. Recimo da ih želimo definirati kao "crveni_oglasi"

Znači broj crvenih oglasa je jako mali spram ukupnog broja oglasa. A među svim oglasima nema zelenih, plavih ..itd. nego samo "crveni" ili ništa.

Dali je logično dodati polje "crveni" u tablicu, koje može poprimiti vrijednost 1 ili 0. I to polje bi trebalo onda indeksirati..

Ili je logičnije napraviti tablicu crveni_oglasi, pa u nju trpati ID-ove oglasa koje želimo deklaritati kao crvene.


S jedne strane razmišljam da index nema smisla jer čemu indeksirati 1 000 000+ oglasa , radi samo 10 oglasa koje želimo označiti crvenima.

S druge strane možda zbog male kardinalnosti indeksa (1 | 0) ... taj index zapravo nije skup?? ..a pri čitanju pomaže ekvivalentno kao posebna tablica? U tom slučaju bi ipak index bio praktičniji...

[mr-crime]

Ovisno o frekventnosti korištenja, tako se barem meni čini. Ako bi se često čitalo crvene onda svakako tablica, u slučaju da se to događa jako rijetko onda je bit polje dovoljno.

[paprat984]

Ah, dileme database modeliranja, dobra tema

One-to-one relationship je obično indikacija da nešto ne štima. Ili je dizajner nešto krivo shvatio ili nešto ne štima sa domenom. Opcija B su razni performance razlozi (više o tome ovdje). Kad bi izdvojio te crvene u zasebnu tablicu imao bi optional one-to-one relationship sa glavnom tablicom.

Ja bi osobno izabrao indeks. Ali pazi kako ćeš popunjavati tu kolonu o kojoj pričaš. S obzirom da imaš +1.000.000 redova. Ako ćeš stavljati u svako polje 0 ili 1, onda će se sve non-NULL vrijednosti indeksirati. To je dosta redova. Rađe onda ostavi sve redove prazne osim onih u kojima će biti 1. Tako ćeš samo njih nekoliko indeksirati.

Disclaimer: pričam o Oracle bazi. Možda tvoja baza ima drugi pristup indeksiranju NULL vrijednosti. Ako ima, napiši malo o tome, baš me interesira kako je izvedeno.

[logit]

Particioniraj tablicu.

Oracle dokumentacija veli

Partitioning enhances the performance, manageability, and availability of a wide variety of applications and helps reduce the total cost of ownership for storing large amounts of data. Partitioning allows tables, indexes, and index-organized tables to be subdivided into smaller pieces, enabling these database objects to be managed and accessed at a finer level of granularity.

[Florest Glimp]

U ovakvim slučajevima se koriste parcijalni indeksi:

Npr. za PostgreSQL

CREATE INDEX idx_crveni_oglasi ON oglasi(crveni)
    WHERE crveni is true;

https://www.postgresql.org/docs/9.5/...s-partial.html

Svaki indeks je skup ako se ne koristi...

[Florest Glimp]

logit kaže:

Particioniraj tablicu.

Pariticioniranje je nepotrebni overhead za ovu situaciju.

[Florest Glimp]

S obzirom da imaš +1.000.000 redova. Ako ćeš stavljati u svako polje 0 ili 1, onda će se sve non-NULL vrijednosti indeksirati. To je dosta redova. Rađe onda ostavi sve redove prazne osim onih u kojima će biti 1.

To možda Oracle tako radi, ali što ako se npr. radi o MySQL bazi?

[paprat984]

Florest Glimp kaže:

To možda Oracle tako radi, ali što ako se npr. radi o MySQL bazi?

A onda mu nema pomoći od mojeg posta. Imaš disclaimer dolje.

[paprat984]

logit kaže:

Particioniraj tablicu.

Slažem se za Florestom ovdje.

Particija 1: 999.990 redova
Particija 2: 10 redova.

Neka ideja sa particijama je da se velika tablica rastavi na više manjih, ne da se velika tablica rastavi na veliku i minijaturnu tablicu.

[Florest Glimp]

paprat984 kaže:

A onda mu nema pomoći od mojeg posta. Imaš disclaimer dolje.

Nema mu pomoći ni od mojega ako se radi o MySQL bazi, jer MySQL nema parcijalnih indeksa.

[bozoou]

Da, radi se o mySql bazi.

Ako nema ničeg sličnog ko parcijalni indexi, onda po ovome što vidim, nebi bio čudan pristup da se za takve neke sekcije odabere posebna tablica i u nju potrpaju željeni ID-ovi.

[mr-crime]

Čudnost ovisi o situaciji, nije po knjizi ali tvoj posao je da učiniš sve što možeš kako bi ta baza bila sigurna i brza. Kako ćeš to napraviti, tvoj je problem.

[Florest Glimp]

Kad god kreneš u izradu malo ozbilnije aplikacije sa nekom kompleksnijom logikom od običnog CMS-a, tipom podatka (spatial) u bazi ili na izlazu (JSON), mogućnošću autenticiranja korisnika na nekom backendu kao što je LDAP, AD ili pak mogućnosti kreiranja stora bez frustracija, MySQL je pain in the ass. PostgreSQL je super alternativa i za Oracle i za MSSQL, i nije mi jasno zašto se ne koristi češće. Minimalni peformance gain, koji je neusporediv u odnosu na situaciju pred 10 godina, nije vrijedan u usporedbi sa svim tim mogućnostima koje ima PostgreSQL. Ja kad gledam neki poslovni proces koji bi pokrio sa open source softverom, a koristi relacijsku bazu, ako u backendu nema PostgreSQL kao opciju zaobilazim u širokom luku.

[igorl]

Uz sve mudre odgovore gore, zapravo nitko nije pitao kako se sustav koristi i koji mu je hardverski kapacitet, koliko ima insertova na toj tablici, itd... Npr.

* Use case #1: Ne fali ti RAM-a
Indeksiras element i zaboravis

* Use case #2: Fali ti rama, imas stotinjak tisuca upita prema bazi dnevno ili manje
Jednostavno ne indeksiras taj element ak je presporo kupis jos rama.

* Use case #3: Imas preko 500M upita per machine dnevno koji bi mogli zavrsiti na bazi
Koristis neki pametni key-value cache servis poput npr. redisa koji cuci prije upita na bazu i cuva je da ne izgori

I nemoj zaboraviti da read queriji nisu nikad skupi, indeksi "kostaju" samo rama. Pitanje je koliko imas insert statementa nad tom bazom koji bi ti mogli klat insertanje indeksa.

Uzivaj

I.

P.S.
Milijun rekorda je takva sica po pitanju bilo koje baze da uopce ne kuzim cemo overinzinjirati stvari Kad dodjes neke finije brojke od recimo 20-30M rekorda gledaj kako splitat tablicu prema nekom drugom parametru koji ti nece razbijati tablice u omjeru 99.9% - 0.1%

[Florest Glimp]

igorl kaže:

I nemoj zaboraviti da read queriji nisu nikad skupi, indeksi "kostaju" samo rama. Pitanje je koliko imas insert statementa nad tom bazom koji bi ti mogli klat insertanje indeksa.

Ovo je netočno. Nasuprot tome i da je samo reporting baza, ako se indeks metne na polje koje nije dovoljno selektivno kod SELECT-a query optimizer može odabrati index scan koji ima random access pattern pristupu disku, pa onda čitati ponovno tabelu - također random access. I da su svi podaci u cache-u to će biti dvostruko sporije od sekvencijalnog scan-a na cijelu tabelu. Loš index je uvijek skup. I ako fali RAM-a na selektivnom polju je indeks uvijek ispravan odabir, a pogotovo ako je puno upita i ako je tabela velika.

Ovo je jedan od gorih savjeta u povijesti foruma.hr - da ukoliko se ima malo RAM-a da se ne treba indeksirati. Bože oslobodi. Polje koje je dovoljno selektivno a koristi se u upitu uvijek treba indeksirati, a pogotovo ako ima malo RAM-a i ako su tabele izrazito velike, jer u tom slučaju možemo očekivati da nije čitava baza u RAM-u i da će doći od intenzivnog čitanja sa diska. Indeksi koštaju i diska jer ne što im treba prostora, nego se trebaju čitati sa diska.

Da - baza radi bolje ako se stavi više RAM-a i brži diskovi ali ispravna (engineering) rješenja se moraju raditi uvijek, a ne samo kada smo u stisci sa resursima.

P.S. Indeksi se ažuriraju i kod UPDATE-a i DELETE-a...

[IllegalArgument]

Nova tablica i nemaš se šta mislit. Veza 1:1 je loša ako imaš dvije jednakobrojne tablice, npr jednu s osnovnim podacima, drugu za detalje.
A ovdje ćeš još imat i uštedu memorije šta nećeš uvoditi dodatnu kolonu koja će u 99.99% redaka imat identičnu vrijednost