Postgresql: affidabilità per uso in produzione

[Alberto]

Spero di non sollevare un flame ;)
nella ditta in cui lavoro si usano diverse applicazioni, una ￜ stata
acquistata ed ￜ basata su oracle, e ci gira sopra una specie di
gestionale di fatturazione (penso che siamo nell'ordine delle 500.000
fatture all'anno da almeno 10 anni), esistono poi altre applicazioni
"satelliti" che sono invece state sviluppate internamente all'azienda, e
che lavora su database mysql.
Parlando con il collega che gestisce i db mysql, e si occupa anche dello
sviluppo delle applicazioni aziendali interne, ￜ spuntato fuori il tema
postgresql, e gli ho chiesto come mai, sentendoli lamentare spesso di
mysql per motivi di licenze poco chiare, bugs di vario tipo, e problemi
di "features" dovute a un linguaggio sql un po' troppo "lassivo" che
ogni tanto viene modificato.... non prendono in considerazione
postgresql.
La risposta ￜ stata sostanzialmente questa: mysql ￜ ben documentato in
rete, c'ￜ un'azienda che in un modo o nell'altro ne risponde, ma
soprattutto perchￜ mysql ha una diffusione di utilizzo molto maggiore,
quindi i problemi emergono e vengono risolti piￜ velocemente, inoltre
perchￜ mysql viene utilizzato in ambito professionale su grandi quantitￜ
di dati, e quindi fornisce delle garanzie intrinseche sulla consistenza
e gestione dei dati. Postgresql invece, essendo utilizzato molto meno,
essendo meno diffuso, e non essendo stato sperimentato a sufficienza su
db di grandi dimensioni, non fornisce sufficienti garanzie di stabilitￜ
e affidabilitￜ.

A me pare che il suo discorso sotto certi aspetti ￜ logico e corretto,
tuttavia non sono convinto circa l'affidabilitￜ di postgresql, possibile
che solo per il fatto che non sia diffuso come mysql, e non ci siano
notizie riguardo utilizzi di grandi banche dati, lo ponga
qualitativamente al di sotto di mysql?

Alb

[Wodka40[Google]]

On 31 Lug, 12:17, Alberto <albaldDEBIANIZZ...@bigfoot.com> wrote:
> Spero di non sollevare un flame ;)

> nella ditta in cui lavoro si usano diverse applicazioni, una è stata
> acquistata ed è basata su oracle, e ci gira sopra una specie di

> gestionale di fatturazione (penso che siamo nell'ordine delle 500.000
> fatture all'anno da almeno 10 anni), esistono poi altre applicazioni
> "satelliti" che sono invece state sviluppate internamente all'azienda, e
> che lavora su database mysql.
> Parlando con il collega che gestisce i db mysql, e si occupa anche dello

> sviluppo delle applicazioni aziendali interne, è spuntato fuori il tema

> postgresql, e gli ho chiesto come mai, sentendoli lamentare spesso di
> mysql per motivi di licenze poco chiare, bugs di vario tipo, e problemi
> di "features" dovute a un linguaggio sql un po' troppo "lassivo" che
> ogni tanto viene modificato.... non prendono in considerazione
> postgresql.

> La risposta è stata sostanzialmente questa: mysql è ben documentato in
> rete, c'è un'azienda che in un modo o nell'altro ne risponde, ma
> soprattutto perchè mysql ha una diffusione di utilizzo molto maggiore,
> quindi i problemi emergono e vengono risolti più velocemente, inoltre
> perchè mysql viene utilizzato in ambito professionale su grandi quantità

> di dati, e quindi fornisce delle garanzie intrinseche sulla consistenza
> e gestione dei dati. Postgresql invece, essendo utilizzato molto meno,
> essendo meno diffuso, e non essendo stato sperimentato a sufficienza su

> db di grandi dimensioni, non fornisce sufficienti garanzie di stabilità
> e affidabilità.
>
> A me pare che il suo discorso sotto certi aspetti è logico e corretto,
> tuttavia non sono convinto circa l'affidabilità di postgresql, possibile

> che solo per il fatto che non sia diffuso come mysql, e non ci siano
> notizie riguardo utilizzi di grandi banche dati, lo ponga
> qualitativamente al di sotto di mysql?
>
> Alb

Un aragosta della Conad è paragonabile ad una di "ciccillo a mare"???
...la risposta è "dipende"....
Con codesta logica codesta azienda fa bene a tenersi Oracle...e non
capisco perchè usi mysql....
probabilmente come front end di appoggio per la presentazione dei dati
su internet.
Probabilmente ordini o report o situazioni di magazzino ...le mostra
su internet,,,ed appoggia i dati da oracle a mySql...
se poi hanno un server "linuz"+mysql+php...beh allora hanno ragione!

La domanda è casomai....possono sostituire Oracle con Postgresql?
dipende!
Da tante cose...non ultima la professionalità del loro ced o struttura
in outsourcing analoga!

Cmq....
alcune referenze di postgrsql se proprio le vuoi.....il mio
comune......ha dei "pazzi" che lo usano!
http://2007.pgday.org/files/rcprato.pdf
http://www.crcr.unipi.it/mediawiki/images/a/a3/080917-OSRiuso-Bartolini.pdf

non siamo un comune grandissimo...ma nemmeno piccolissimo!....dopo
Firenze ci siamo noi!

[Manlio Perillo]

Il Fri, 31 Jul 2009 10:17:41 +0000, Alberto ha scritto:

> [...]

> La risposta è stata sostanzialmente questa: mysql è ben documentato in
> rete,

Avendo letto entrambe le documentazioni, posso garantirti che la
documentazione di PostgreSQL è superiore.

PostgreSQL è superiore a MySQL anche dal punto di vista della API e della
architettura.

Per il resto, non sono un sistemista quindi non mi pronuncio.

Ciao Manlio

[Enrico 'Henryx' Bianchi]

In 31/7/2009 12:17 Alberto wrote:

> possibile
> che solo per il fatto che non sia diffuso come mysql, e non ci siano
> notizie riguardo utilizzi di grandi banche dati, lo ponga
> qualitativamente al di sotto di mysql?

Le notizie ci sono, basta solo cercare decentemente. Ad esempio,
PostgreSQL e` stato scelto per la gestione dei domini .org, cosa non
certo di poco conto. Inoltre, da quello che leggo su Wikipedia, Yahoo!
usa una versione (pesantemente) modificata di PostgreSQL per una base
dati di circa 2PiB. Infine, del discorso fatto dal tuo collega, l'unica
cosa sensata detta e` che dietro PostgreSQL non c'e` alcuna azienda,
parametro che e` molto sentito in alcuni ambiti lavorativi

Enrico

[Hermooz]

On 9 Ago, 17:39, Enrico 'Henryx' Bianchi <henryx.b_INVAL...@libero.it>
wrote:

> l'unica
> cosa sensata detta e` che dietro PostgreSQL non c'e` alcuna azienda,

Non è del tutto vero neanche questo: in realtà ce n'e' più di una... i
principali attori dello sviluppo lavorano tutti per due-tre aziende
che investono pesantemente nello sviluppo, nella promozione e nel
supporto di PostgreSQL.

bye!

[Enrico 'Henryx' Bianchi]

In 18/8/2009 11:25 Hermooz wrote:

> Non è del tutto vero neanche questo: in realtà ce n'e' più di una...

Lo so, pero` quello che importa molto alle aziende che adottano il
prodotto e` l'avere una unica azienda centralizzata. Allo stesso modo,
giusto per fare un paragone rimanendo sempre in ambito FLOSS, le aziende
scelgono quasi sempre Red Hat o Novell quando si tratta di installare
ambienti linux, snobbando praticamente Debian o altre distribuzioni che
potrebbero risultare pienamente valide per effettuare la stessa
tipologia di lavoro

Enrico

[Hermooz]

On 19 Ago, 18:12, Enrico 'Henryx' Bianchi
<henryx.b_INVAL...@libero.it> wrote:

> Lo so, pero` quello che importa molto alle aziende che adottano il
> prodotto e` l'avere una unica azienda centralizzata. Allo stesso modo,
> giusto per fare un paragone rimanendo sempre in ambito FLOSS, le aziende
> scelgono quasi sempre Red Hat o Novell quando si tratta di installare
> ambienti linux, snobbando praticamente Debian o altre distribuzioni che
> potrebbero risultare pienamente valide per effettuare la stessa
> tipologia di lavoro

Non tanto il fatto che sia unica, quanto il fatto che si esponga
offrendo certificazioni e garanzie per l'utilizzo del prodotto.
Effettivamente quello che manca a PostgreSQL sarebbe che qualcuno si
prendesse l'onere di fare una distribuzione binaria e prendesse
accordi con i vendor HW per delle configurazioni "certificate". Se
vinco al superenalotto la metto su io ;^)

bye!

[Lucazeo]

On 20 Ago, 15:27, Hermooz <herm...@gmail.com> wrote:

> Effettivamente quello che manca a PostgreSQL sarebbe che qualcuno si
> prendesse l'onere di fare una distribuzione binaria e prendesse
> accordi con i vendor HW per delle configurazioni "certificate". Se
> vinco al superenalotto la metto su io ;^)
>
> bye!

Non a questo livello, ma Unisys è una delle grandi realtà in grado di
gestire Postgresql in ambienti di tipo Enterprise. Purtroppo sul loro
sito la cosa non è affatto pubblicizzata, ma è una delle architetture
che propongono i loro consulenti.

Ciao

[FB]

Enrico 'Henryx' Bianchi ha scritto:

Se mi consenti, il paragone mi sembra piuttosto infelice..
In ambiente Enterprise si preferisce Red Hat e qualcuno Suse (Novell)
perché sono le uniche 2 distro supportate dalla totalità dei produttori
di hardware enterprise, basti pensare ad esempio agli HBA, HSM ecc..
Red Hat è certamente supportata, Suse molto probabilmente...
Debian... chi? no, oggi deve essere malato o di riposo riprovate domani.

Per non parlare del problema dei manteiner.. Immagina un azienda che
voglia allestire una PKI e si ritrova con un OpenSSL buggato, sai le
risate.. ci fanno pure le barzellette...

http://www.metasploit.com/users/hdm/tools/debian-openssl/

Quindi poi non lamentiamoci se qualcuno "snobba" Debian & Co. se a
pacchettizzare le applicazioni sono dei ragazzini di cui si conosce solo
l'email in caso di danni a chi ci si dovrebbe rivolgere?

Pensa cosa accadrebbe se uno sviluppatore creasse un applicazione e la
pacchettizzasse per Debian o Ubuntu e poi in modo "doloso" inserisse
codice malevolo nella stessa al fine di bucare tutti i sistemi che la
utilizzano dopo averla inserita nei repository ufficiali.

Ecco, ora dovresti avere il quadro.. moltiplicalo per il numero di
pacchetti disponibili per queste distro e dimmi quanto sicuro può essere
un server di cui non si sa chi ha creato i .deb

In caso di dolo che si fa? andiamo a prendere per il collo un ragazzino
cinese, belga, sudafricano? o ce lo prendiamo nel C. noi?

Stesso discorso probabilmente vale anche per alcuni DB open source e
relative aziende di supporto che si auto certificano come esperti.

[Enrico 'Henryx' Bianchi]

In 22/8/2009 02:41 FB wrote:

> Se mi consenti, il paragone mi sembra piuttosto infelice..

Non direi anzi...

> In ambiente Enterprise si preferisce Red Hat e qualcuno Suse (Novell)
> perché sono le uniche 2 distro supportate dalla totalità dei produttori
> di hardware enterprise,

Sono supportate proprio perche` hanno dietro un'azienda certa e
definita, cosa che non ha, ad esempio, Debian

> Per non parlare del problema dei manteiner.. Immagina un azienda che
> voglia allestire una PKI e si ritrova con un OpenSSL buggato, sai le
> risate.. ci fanno pure le barzellette...

Posto che il problema da te citato e` nato in Debian, ricordo che a
causa della sua complessita` si puo` dire che praticamente *tutte* le
distribuzioni linux ne erano affette (se non direttamente,
indirettamente nel momento in cui accettavano un certificato creato con
quella versione di OpenSSL). Comunque, tralascaindo il dettaglio
di questa parte del tuo discorso, continui a darmi ragione: si
preferisce di gran lunga il prodotto alle cui spalle c'e` un'azienda ben
definita nonostante vi possano essere prodotti di qualita` superiore (e,
per inciso, personalmente per me Debian e` piu` intuitiva, stabile e
razionale di una RH e/o di una SuSE qualsiasi)

> Pensa cosa accadrebbe se uno sviluppatore creasse un applicazione e la
> pacchettizzasse per Debian o Ubuntu e poi in modo "doloso" inserisse
> codice malevolo nella stessa al fine di bucare tutti i sistemi che la
> utilizzano dopo averla inserita nei repository ufficiali.

Direi che il problema sussiste anceh in una qualsiasi versione di RHEL
o SuSE: chi mi garantisce che il pacchetto xyz presente nella
distribuzione non abbia backdoor al suo interno? Per ritornare IT,
all'epoca del rilascio dei sorgenti di Interbase 6 da parte di Borland
(sorgenti da cui e` nato Firebird, ricordiamolo), vi fu un "piccolo"
scandalo in quanto vi era una backdoor praticamente in bella vista

> Ecco, ora dovresti avere il quadro.. moltiplicalo per il numero di
> pacchetti disponibili per queste distro e dimmi quanto sicuro può essere
> un server di cui non si sa chi ha creato i .deb

Seriamente, so quello che uso (ho alcune CentOS solo perche` devo
installare Oracle, altrimenti installo esclusivamente Debian) e so che
qualsiasi problema viene risolto tempestivamente. Inoltre, per entrare
nei repository ufficiali, un pacchetto segue un iter ben definito e solo
dopo aver passato un periodo di test viene rilasciato in produzione.
Infine, tutti i pacchetti sono certificati mediante chiave GnuPG, di
conseguenza, l'unico modo per cui vi puo` essere un problema e` a causa
di un errore umano (alla fin fine, se la gente ha ancora fiducia in
Debian ci dev'essere un motivo). L'episodio da te citato e` una grossa
macchia nella carriera di Debian, ma non credere che le altre
distribuzioni siano migliori. Dopo tutto, dietro ad un software o ad
un suo derivato (e.g. il pacchetto da installare) c'e` sempre un
essere umano (a tal proposito, vorrei citare questo:
http://xkcd.com/424/)

> Stesso discorso probabilmente vale anche per alcuni DB open source e
> relative aziende di supporto che si auto certificano come esperti.

In teoria il discorso lo riterrei, in teoria, un po' piu` complicato. Da
un'azienda che si certifica come azienda di supporto per una determinata
piattaforma (che sia un db o meno), oltre alla classica e dovuta
serieta`, mi aspetto che sia competente in quello che fa. Di
conseguenza, oltre a conoscere il prodotto, mi aspetto che sappia
creare e applicare patch specifiche per le esigenze del committente.
Putroppo nella realta` non sempre e` cosi`, ed e` per questo che molte
aziende non si fidano e preferiscono contattare direttamente il
produttore o chi viene certificato da esso (cosa non fattibile in molti
progetti FLOSS)

Enrico

[Wodka40[Google]]

zac

> In teoria il discorso lo riterrei, in teoria, un po' piu` complicato. Da
> un'azienda che si certifica come azienda di supporto per una determinata
> piattaforma (che sia un db o meno), oltre alla classica e dovuta
> serieta`, mi aspetto che sia competente in quello che fa. Di
> conseguenza, oltre a conoscere il prodotto, mi aspetto che sappia
> creare e applicare patch specifiche per le esigenze del committente.
> Putroppo nella realta` non sempre e` cosi`, ed e` per questo che molte
> aziende non si fidano e preferiscono contattare direttamente il
> produttore o chi viene certificato da esso (cosa non fattibile in molti
> progetti FLOSS)
>
> Enrico

Non per fare il solito...ma basta guardare le recenti vicende
internazionali...anche se non c'entrano nulla con l'informatica....per
dubitare alquanto dei controllori e dei controllati!
IMHO
Se linux non si sà cosa ha dentro....
meno ancora si sà di quello che contiene Oracle o SAP o SQLserver

Tutti sappiamo l'anedotto
"Non è un bug! E' una nuova feature!"

e per qunato piccolo io sia e limitata sia la mia esperienza rispetto
al resto del mondo....
non ho MAI visto una situazione reale che fosse ESATTAMENTE identica a
quella che il commerciale ha venduto ad una azienda...con tutte le
conseguenze del caso!(e non sempre la colpa è del commerciale...ma
anche dell'azienda che usa situazioni diverse da quelle prospettate)
in conclusione...per me....
Un CED interno deve avere le palle...perchè una fase di "assestamento"
è necessaria per tutto....persino per usare Access!Perchè la
situazione reale....non è mai quella teorica!
Sempre e soltanto IMHO!

p.s.
Io ritengo di aver fugato il dubbio su quanto affidabile sia
postgresql (ossia come gli altri db)....il comune di Prato lo usa nel
suo CED...ho proposto i link.
Scrivete al loro ced e fatevi dare ragguagli su carichi , lentezze e
quant'altro...con calma(son dip.pubblici eh! eheheheh)...vi rispondono!