<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-11-06 17:16 GMT+00:00 Enrico Bianchi <span dir="ltr"><<a href="mailto:enrico.bianchi@ymail.com" target="_blank">enrico.bianchi@ymail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></span>
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), </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">parallel query (che risolvi pero` con pgpool-II), partizionamento e sharding nativi.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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).</blockquote><div><br></div><div>Il problema e' sempre capire cosa serve, cosa non serve e se una cosa che serve e' implementata in modo che funziona.</div><div>Tutte queste features auto-magiche, per intenderci, sono molto fiche ... ma poi bisogna capire se funzionano decentemente.</div><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Poi ovviamente ci sono cose che PostgreSQL fa meglio (e.g. PostGIS vs Oracle Spatial), ma Oracle rimane comunque un punto di riferimento<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Si, con Oracle hai il supporto del vendor (piuttosto caro) e hai molti dba certificati.<br>
</blockquote></span>
Il supporto a PostgreSQL lo hai per mezzo di 2ndQuadrant (i piu` famosi)</blockquote><div><br></div><div>Come dicevo nel mio messaggio, ci sono una serie di compagnie (fra cui 2nd Quadrant, che io pero' non avevo menzionato) che lo fanno.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Non sono a conoscenza di come Oracle se la cavi a risolvere i problemi che su PG risolverei le cose che farei con jsonb.<br>
</blockquote></span>
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`)<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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. </div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>