[Python] Progetto SW

[enrico franchi]

2015-11-06 17:16 GMT+00:00 Enrico Bianchi <enrico.bianchi a ymail.com>:

>
> Grosse feature mancanti a PostgreSQL sono ad esempio il mancato supporto
> al clustering (cosa che con PostgreSQL-XL stanno risolvendo che, se non ho
> capito male, finira` dentro a 9.5),

parallel query (che risolvi pero` con pgpool-II), partizionamento e
> sharding nativi.

In teoria sono tutte cose che hai anche con componenti esterni (come ho
> riportato), ma significa comunque che devi aggiungere pezzi di
> infrastruttura non indifferenti. Oracle invece da questo punto di vista fa
> tutto internamente (se paghi).


Il problema e' sempre capire cosa serve, cosa non serve e se una cosa che
serve e' implementata in modo che funziona.
Tutte queste features auto-magiche, per intenderci, sono molto fiche ... ma
poi bisogna capire se funzionano decentemente.

Che so... verrebbe da dire un po' delle "nuove" feature che hanno aggiunte
a Cassandra (per questioni di marketing) che pero' nella pratica hanno una
lista di gotcha non indifferenti e sono anche un ottimo modo per inchiodare
un cluster cassandra come performance.

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).

Poi, su una nota completamente differente, mi viene sempre da dire... ma
*veramente* vogliamo queste cose in un db relazionale? Spiego meglio...
molte delle feature che menzioni (sharding e partizionamento) non sono per
nulla banali da risolvere in modo efficiente in modo generale. Non a caso,
in generale, i sistemi che sono migliori da questo punto di vista offrono
un modello piu' debole e piatto di quello relazionale. E saltano dentro i
sistemi distribuiti con tutti i loro problemi, CAP e tanti saluti.

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... e quindi magari mi metto a progettare lo schema in modo da
supportare meglio il tutto, etc etc etc. E poi alla fine mi trovo con
qualcosa che e' piu' vicino a Cassandra che a uno schema relazionale fatto
come si deve...

Perche' il brutto di sta roba e' che veramente non ci sono pasti gratis. Se
hai un sistema con update, il CAP e' veramente doloroso. E non puoi
uscirne. Se hai un sistema incrementale, molti aspetti sono piu' leggeri.
Ma un RDBMS *deve* offrirmi il modello relazionale, che contiene update.
Quindi certo, avro' un layer inferiore che probabilmente cerca di lavorare
append only e poi lo cerco di esporre in modo relazionale. Etc etc etc.

Quindi: sta roba... l'hai provata *davvero*? 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.

Io capisco che tutti i provider di sistemi implementano cose nel tentativo
di vendere il sistema "per ogni utilizzo". Ma noi come utenti dei sistemi
sappiamo benissimo che in generale sono palle: sistemi diversi ffunzionano
bene per use case diversi.



> Poi ovviamente ci sono cose che PostgreSQL fa meglio (e.g. PostGIS vs
> Oracle Spatial), ma Oracle rimane comunque un punto di riferimento
>
> Si, con Oracle hai il supporto del vendor (piuttosto caro) e hai molti dba
>> certificati.
>>
> Il supporto a PostgreSQL lo hai per mezzo di 2ndQuadrant (i piu` famosi)


Come dicevo nel mio messaggio, ci sono una serie di compagnie (fra cui 2nd
Quadrant, che io pero' non avevo menzionato) che lo fanno.


> Non sono a conoscenza di come Oracle se la cavi a risolvere i problemi che
>> su PG risolverei le cose che farei con jsonb.
>>
> Oracle 12c implementa il supporto a JSON sia come data type, sia come
> funzioni per la gestione e manipolazione (non so dirti di piu` pero`)
>
>
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. 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.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20151106/dd6dbc21/attachment.html>