[Python] Progetto SW

[Enrico Bianchi]

On 11/06/2015 06:39 PM, enrico franchi wrote:
> Altri aggeggi (che so, il clustering) richiedono comunque parecchia 
> infrastruttura. Che sia o meno multi-vendor (ovvero, che sia piu' 
> integrato in Oracle, ok... ma se vuoi un cluster hai comunque bisogno 
> di tirare su nodi, lb, possibilmente qualche sorta di controller).
Vero, ma comunque in ottica di HA e` qualcosa che serve e fa comodo. 
Gia` l'avere BDR (che si spera che sia integrata completamente in 9.5) 
sara` un ottimo passo avanti, almeno nella gestione del bilanciamento 
delle connessioni tramite pgBouncer

> Poi, su una nota completamente differente, mi viene sempre da dire... 
> ma *veramente* vogliamo queste cose in un db relazionale?
Enrico, per essere franchi (scusa il gioco di parole), si, sono cose che 
in un db relazionale come PostgreSQL servono. Perche` in un contesto di 
datawarehouse o di business intelligence hai a che fare con tabelle con 
milioni di record (dove milioni e` piu` di 5, giusto per tenersi bassi). 
Introdurre un sistema di di partizionamento dei dati ed una gestione 
parallela delle query significa quindi non solo avere una gestione 
migliore dei dati, ma anche delle performance non indifferenti. E il 
mettere un middleware in mezzo (e.g. per la gestione delle query 
parallele) significa solo aggiungere una pezza, perche` non solo 
aggiungi uno strato da manutenere, ma rischia anche di peggiorare le 
prestazioni piuttosto che migliorarle (siamo ad un livello superiore 
rispetto all'implementazione nativa. Ed e` da vedere anche in 
quest'ottica l'aggiunta delle viste materializzate in PostgreSQL 9.3

> Spiego meglio... molte delle feature che menzioni (sharding e 
> partizionamento) non sono per nulla banali da risolvere in modo 
> efficiente in modo generale.
In teoria partizionamento (tramite rule, trigger e viste) e sharding 
(tramite fdw) lo hai gia`, ma avere una gestione semplificata ("alla 
Oracle" per intenderci) e` qualcosa a cui dovrebbero puntare (e comunque 
ci vogliono puntare, basta vedere che uno dei punti fermi nella TODO 
List di PostgreSQL e` ad esempio la semplificazione della gestione del 
partizionamento) anche nell'ottica di ottenere performance migliori

> Quindi se il mio db offre queste feature, ottimo, eh. Ma se poi devo 
> comunque mettermi a pensare le query in modo diverso che tengono conto 
> di come sono messe le cose, altrimenti mi parte completamente la 
> performance...
Il pensare le query diferentemente e` un concetto alquanto labile. 
Poniamo ad esempio Oracle: il parallelismo delle query si ottiene 
tramite un costrutto ad hoc del CREATE TABLE (che di suo e` fortemente 
dipendente dal RDBMS) e successivamente mediante un SELECT /*+ 
PARALLEL(n) */ , ovvero a conti fatti non cambia nulla e, soprattutto, 
rimane compatibile con praticamente tutto. Ed il discorso di pensare 
differentemente e` un discorso che devi fare sempre, ovvero ad esempio 
se in MongoDB non ragioni in logica di sharding dei dati le prestazioni 
se ne vanno a donnine (testato sulla mia pelle)

> e quindi magari mi metto a progettare lo schema in modo da supportare 
> meglio il tutto, etc etc etc.
Sinceramente non capisco questo tuo ragionamento, quando progetto uno 
schema dati uso le funzionalita` che mi servono, non tutte le 
funzionalita` del database. Per intenderci, se ho un database in cui la 
tabella piu` grande ha 50.000 record non partiziono le tabelle. 
Diversamente, gia` se mi aspetto 1.000.000 e piu` record posso 
cominciare a valutare la questione

> Quindi: sta roba... l'hai provata *davvero*?
Personalmente non mi e` mai servita, ovvero non sono mai arrivato a 
gestire moli di dati cosi` grosse. Ma sono funzionalita` pesantemente 
utilizzate in ambito finanziario o in ambito bancario (per dire, SAP 
usava - ora non so se hanno cambiato qualcosa - una tabella di 
"journaling" in cui venivano loggate tutte le operazioni effettuate, 
ovvero avevi un mostro che dopo pochi giorni diventava grosso circa 
30mln di record, non usare il partizionamento in quel caso significava 
avere una tabella ingestibile)

> Perche' se c'e', ma di fatto va usata con molta cura, non sono 
> convinto che non mi convenga usare Dynamo o mettere su un cluster 
> cassandra o hadoop.
Anche un indice e` da usare con molta cura, eh ;)

> Ok. Perche' PG fa un bel po' di roba "unica" su tutto questo. Roba 
> anche *preziosa* per cui mi viene voglia di non considerare soluzioni 
> NoSQL per tanto e' fatta bene.
Lo so, infatti stavamo valutando il passaggio da Oracle 11g a PostgreSQL 
proprio per il supporto a JSON (passaggio che poi non si fara` per una 
serie di molteplici motivi)

> Se si tratta solo di avere json sintatticamente corretto con qualche 
> forma di ricerca limitata e lenta (come per esempio era nelle versioni 
> piu' vecchie di postgresql) la cosa mi interessa di meno.
Da quello che ho visto, in Oracle 12c fai query del tipo SELECT 
tabella.campojson.chiave FROM tabella e da qui lo tratti come se fosse 
un dato normale, ma non so dirti di piu` (e.g. non capisco come faccia a 
gestire gli array). Ovviamente ci sono anche delle funzioni e dei 
constraint per gestire il tipo di dato, ma il mio assunto rimane lo 
stesso :)

Enrico