MariaDb: Performance views

5 Risposte

• M

  migliorabile

  Super Famoso

  Iscritto da

  apr, 2013

  Messaggi:

  6034

  Re: MariaDb: Performance views

  20 gen 2020, 15:11

  A questi livelli e' come chiedere se per spostare una formica e' meglio un TIR o un Treno!
  
  25 tabelle NON SONO tante tabelle, sono meno di una formica
  
  I problemi possono nascere quando
  
  1) fai JOIN tra MOLTE TABELLE
  2) le tabelle contengono MILIONI/MILIARDI di record
  
  Con 2500 ti devi porre il problema se stai facendo una modellazione intelligente o forse e' meglio suddividere le tabelle in database distinti
  Con 25000 tabelle, probabilmente stai facendo pasticci.
  
  MA, il numero di tabelle non sono un problema, perche' non accedi NELLO STESSO ISTANTE a tutte le tabelle.
  Il problema e' nella complessita' delle query ed in particolare nelle SELECT con JOIN, perche' le SELECT su un'unica tabella NON SONO un problema, E nel numero di record che la SELECT con JOIN deve processare.
  
  Le VIEW sono una specie di SELECT predefinita, quindi si ritorna al discorso sulla complessita' delle SELECT
  
  Un DBMS non in grado di gestire qualche migliaio di tabelle con qualche milione di record per tabella NON E' un DBMS degno di questo nome
  
  (Vabbe', ci sono i DBMS embedded, ma hanno un'altro utilizzo!)
  
  Per quanto riguarda le performance:
  OVVIAMENTE, per quanto possibile, e' meglio delegare la maggior parte del lavoro al DBMS, per diversi motivi
  
  1) il DBMS e' installato su una macchina potente
  2) il DBMS ha accesso diretto ai dati e quindi ci puo' accedere piu' velocemente
  3) il DBMS ha un motore in grado di fare delle ottimizzazioni che possono essere utili a diversi utenti
  4) MENO dati si trasferiscono dal DBMS al client, MEGLIO E', perche' trasferire i dati COSTA in termini di banda e tempo
• T

  tatino

  Utente Attivo

  Iscritto da

  gen, 2020

  Messaggi:

  91

  Re: MariaDb: Performance views

  20 gen 2020, 15:23

  Ok chiaro il messaggio.
  Io ho esposto il mio numero di tabelle ad oggi.. magari domani saranno 2.500 e fra x anni saranno 25.000, mi interessava affrontare l'argomento alla radice e capire se le view in base alle complessità assorbono o necessitano di più risorse.
  Le join sono davvero tante e per un prodotto che dovrà essere distribuito parliamo di tante query e, potenzialmente, tanti records che dovranno essere gestiti.
  
  Ti ringrazio per il tuo intervento, sei stato chiarissimo
  
  I 4 punti finali sono fondamentali.
• M

  migliorabile

  Super Famoso

  Iscritto da

  apr, 2013

  Messaggi:

  6034

  Re: MariaDb: Performance views

  20 gen 2020, 15:42

  I problemi di performace NON SONO legati all'uso di view, MA
  
  1) alla corretta modellazione del modello dati
  2) alla corretta definizione delle query
  3) alla corretta creazione degli indici per velocizzare le query
  4) alla corretta DEnormalizzazione: la normalizzazione aiuta ad assicurare la consisteza dei dati, ma aumenta la complessita' delle query. Un'opportuna ed occulata DEnormalizzazione puo' migliorare notevolmente le performace
  5) al corretto uso di Stored Procedures
  6) magari all'utilizzo di un DIVERSO modello dati (colonnare, key/value, a grafo/...)
  
  Quindi, fondamentalmente, le problematiche da affrontare per avere un sistema efficiente, vanno in tutt'altra direzione
  
  COMUNQUE, parli di tante query e tanti record MA senza quantificare quanto vale questo "tanti", non si puo' dire molto.
• S

  surfernet

  Molto attivo

  Iscritto da

  ago, 2019

  Messaggi:

  597

  Re: MariaDb: Performance views

  20 gen 2020, 15:56

  Migliorabile ha già chiarito la situazione,ti direi di osservare empiricamente di quanto crescono in ram i processi costitutivi del db quando lanci le query e di quanto e per quanto cresce il consumo della cpu , ciao
• A

  asql

  Molto attivo

  Iscritto da

  dic, 2018

  Messaggi:

  536

  Re: MariaDb: Performance views

  20 gen 2020, 18:39

  Salve a tutti,
  oltre ad unirmi a quanto gia' indicato da @Migliorabile, vorrei riprenderne un "pezzo" che comunque sempre @Migliorabile ha gia' chiarito, ma non mi pare recepito:

  tatino ha scritto:

  ---

  ...
  Mi spiego meglio: a livello di performance è preferibile eseguire query multiple da codice oppure utilizzare le views?
  ...

  le viste altro non sono altro che proiezioni gia' definite nel catalogo del database, quindi comandi di SELECT gia' definiti, ma non occupano "spazio" e non referenziano direttamente una riga relativa ad una tabella (a meno che come in SQL Server siano "indexed views" dove viene generato ed archiviato almeno un indice cluster sul risultato della proiezione della vista)...
  i BOL di SQL Server recitano: "... una vista non esiste come set archiviato di valori di dati in un database. Le righe e le colonne di dati provengono da tabelle a cui fa riferimento la query che definisce la vista e sono prodotte dinamicamente quando si fa riferimento alla vista. ..."
  in questo senso, proiettare una vista, proiettare una tabella, eseguire una stored procedure, "tecnicamente" non comporta alcuna differenza prestazionale e/o motivazionale in se'...
  sono quindi "un modo (pre)definito dal dba" di accedere ad un particolare set non ordinato di dati espresso da una o piu' tabelle composte da una o piu' colonne con un eventuale filtro prestabilito...
  
  al di la' di questo, a mio parere e' sicuramente preferibile l'utilizzo (solo) di viste e stored procedure per l'accesso ai dati, escludendo quindi l'accesso alle base tables, che permette tra l'altro permette un layer di astrazione "superiore" di accesso ai dati, e quindi permettere ad esempio di modificare la struttura delle tabelle sottostanti in maniera trasparente ai client richiedenti, ovvero concedere l'accesso a determinate righe e/o colonne in base a criteri funzionali di autorizzazione in maniera molto semplice...
  di mio, solitamente, non concedo mai l'accesso alle base tables, anche se spesso risulto molto talebano agli sviluppatori
  salutoni omnia
  --
  Andrea