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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
