Cosa ti piace di più di IBM Netezza Performance Server?
La velocità pura del sistema consente un processo di sviluppo non tipicamente intrapreso. Ad esempio, è possibile eseguire test di prestazioni completi mentre si eseguono i test unitari. È anche possibile creare tabelle molto più grandi di quelle che si farebbero in un database tipico (ad esempio, memorizzando righe correnti e archiviate nelle stesse tabelle).
La semplicità del sistema consente una manutenzione minima. Il coinvolgimento del DBA può essere quasi nullo. Recensione raccolta e ospitata su G2.com.
Cosa non ti piace di IBM Netezza Performance Server?
La semplicità del sistema può anche causare problemi in casi d'uso misti.
In altri database, hai anche la possibilità di migliorare le prestazioni con vari mezzi, come il partizionamento, l'indicizzazione, l'allocazione dell'hardware del server, ecc. Netezza ha essenzialmente solo due modi - per quanto riguarda l'architettura fisica - per gestire le prestazioni: ordinare i dati e distribuire i dati.
L'ordinamento dei dati viene effettuato direttamente nella tabella, evitando la necessità di indici cluster. Ma ciò è utile solo se la query che esegui utilizza quell'ordinamento. Ad esempio, se ordini per data rendendo il campo Data la chiave ORGANIZE BY, qualsiasi query che non utilizza Data nella clausola WHERE dovrà eseguire una scansione della tabella. Puoi creare viste materializzate che agiscono essenzialmente come indici, ma non puoi usare sia le MVs che le chiavi ORGANIZE BY. In altre parole, se usi anche solo una MV per ordinare, non puoi forzare l'ordinamento dei dati nella tabella a meno che non ricarichi effettivamente i dati con una clausola ORDER BY nell'istruzione INSERT. Il problema con le MVs è che, anche se agiscono come un indice, devi aggiornarle come una tipica MV per ordinare qualsiasi nuovo dato. In un sistema che viene caricato o aggiornato durante il giorno, ciò può causare problemi.
La distribuzione ha due componenti che a volte possono essere in contrasto tra loro: l'hashing uniforme dei dati per condividere il carico di lavoro e la collocazione dei dati per i join. Ma se la colonna che ha senso distribuire per scopi di collocazione non distribuisce uniformemente i dati, sarai costretto a fare un compromesso su uno a favore dell'altro.
Inoltre, in uno schema a stella, puoi collocare la chiave esterna della tabella dei fatti con la chiave primaria di una dimensione, ma ciò è meglio utilizzato se esegui una query con un parametro su quella dimensione nella clausola WHERE. Se esegui una query che non può filtrare su quella dimensione, la chiave di distribuzione potrebbe non aiutarti. Inoltre, puoi scegliere solo una dimensione con cui collocare il fatto. Scegliere una distribuzione multi-colonna del fatto basata su più chiavi di dimensione non colloca il fatto con _ogni_ dimensione. Distribuisce invece il fatto con una chiave hash basata sulla combinazione concatenata dei valori della chiave di distribuzione multi-colonna (cioè il fatto non sarà collocato con _nessuna_ dimensione).
Inoltre, il fatto che Netezza non abbia introdotto opzioni in-memory o colonnari mi fa chiedere se l'architettura dell'apparecchio consenta anche tali possibilità. In altre parole, la mancanza di flessibilità potrebbe riemergere se la natura dell'apparecchio non consente una funzionalità così varia. Recensione raccolta e ospitata su G2.com.
