2009-11-24 12 views
10

Sono un fan di MySQL, tuttavia desidero sapere in quali situazioni scegliere Oracle su MySQL sembra la strada da percorrere. Ad esempio, quali sarebbero gli indicatori che potrebbero farti dire ... "Ho bisogno di Oracle per questo progetto"Quando scegliere Oracle su MySQL?

Aggiornamento: Come un altro collega SOer ha sottolineato, non limitare le risposte a Oracle ... se si conosce qualcosa di meglio, si prega di farlo notare anche.

+0

Perché Oracle è l'unica alternativa a MySql? – cjk

+0

Vero, ha aggiornato la domanda :) –

+5

Un buon suggerimento sarebbe quello di smettere di essere un fan di MySQL durante il processo di valutazione. | -) – jrbjazz

risposta

11

ci sono certe cose che mi preoccupano con Mysql

devo scegliere tra far rispettare vincoli e le transazioni vs indice full-text (InnoDB MyISAM vs). Questo è davvero il problema numero 1 per me (enforcing vincoli e delle transazioni è ciò che rende db fresco, ma è necessario la ricerca a testo troppo ...)

  • Non è facile a "simulare" operazioni in codice client.
  • Se non far rispettare i vincoli è davvero facile da ottenere lo stato incoerente del db
  • Senza full-text Ricerca si potrebbe ottenere pazzo con O X come% y%
  • È necessario creare prima dell'aggiornamento TRIGGER con RAISE ERROR per CHECK CONSTRAINT
  • Mysql ha prestazioni scadenti quando i dati diventano troppo grandi (intendo davvero grandi).
  • Mysql crea scarsi piani di esecuzione
  • Mysql ha problemi con più di 3 join (diciamo meglio più join).

Oracle è la soluzione per tutti questi problemi, è un pieno di DBMS (operazioni, VERIFICA vincoli, un sacco di opzioni per le viste, ricerca full-text e molto altro ancora ..), ma dopo tutto è una questione di soldi .

+3

quando dici "veramente grande", puoi darmi dei numeri da tenere in considerazione? –

+1

Per quanto riguarda il testo completo, ho risolto il problema con l'utilizzo di Sfinge. Personalmente ritengo che il testo completo su un set di dati di grandi dimensioni sia probabilmente meglio scaricato dall'RDBMS .. ma questa è solo la mia opinione. –

+0

@Sabeen Accetti una risposta troppo presto. Dovresti farlo solo dopo aver risposto a tutte le tue domande. – OTZ

3

Analytics ... hai bisogno di altri motivi? ;)

Le analisi sono una benedizione per tutti i report e le sale dati. Ma se hai bisogno di un piccolo database per un sito web, continua con MySQL, altrimenti, se hai bisogno di report complicati e le prestazioni sono un problema, allora credo che Oracle sia la strada da percorrere.

+0

Hmmh. Uso MySQL per datawarehousing perché semplicemente è più veloce. Vorrei usare ETL per trasformare i dati da Oracle a MySQL. –

+0

Analytics .. concordato ma è davvero una funzionalità che un server di database DEVE tenere? .. anche io non capisco il concetto dietro questa linea vedo un sacco di gente usa "MySQL è per piccoli database dietro siti web" .. ho usato MySQL personalmente su progetti relativamente grandi senza problemi .. Facebook utilizza MySQL, Twitter è su MySQL credo che un paio di porzioni di Yahoo utilizzino MySQL .. quindi ancora una volta quanto piccolo è piccolo? –

+1

Vero, piccolo è relativo. Ma quando lavori in una banca, ad esempio, la quantità di dati è enorme rispetto a quei siti Facebook o Digg. Alcuni milioni di righe sono considerati "piccoli" – guigui42

1

Oracle offre un enorme set di funzionalità, alcuni degli extra opzionali che si pagano, ma molti di questi sono inclusi gratuitamente in ogni edizione.

http://www.oracle.com/database/product_editions.html

interrogazione Flashback è un libero comprendono, e ti permette di interrogare il database "come di" un po 'di tempo nel recente passato.

I filtri di espressione sono un altro buon esempio di freebee e anche il motore delle regole è potente. http://www.oracle.com/technology/products/database/rules_manager/index.html

Così, quando fai la tua scelta, devi considerare quali caratteristiche puoi sfruttare per ottenere funzionalità che altrimenti dovresti sviluppare e supportare.

5

Sono un ragazzo Oracle, ma a volte trovo difficile argomentarne l'utilizzo su PostgeSQL o anche su MySQL.
Il racconto è che ci sono aziende/progetti là fuori che gestiscono enormi quantità di dati utilizzando alcuni RDBMS open source.

Se vuoi approfondire le funzionalità, questa è un'altra cosa, ma come puoi discutere contro il successo di quelle aziende? È vero, usano molte scatole per raggiungere questo obiettivo, ma è comunque molto più economico. Dubito che la maggior parte delle aziende che usano Oracle oggigiorno ne abbiano davvero bisogno, ma ci sono certamente aziende che hanno bisogno di Oracle.

Una bella citazione:

"Move lavoro intensivo della CPU spostato fuori del livello di database per applicazioni applicazioni strato: referenziale integrità, si unisce, ordinamento fatte nello strato applicazione Ragionamento: app I server sono economici, i database sono il collo di bottiglia ".

Vedi here per un sacco di pratica del mondo reale. E sì, usano Oracle.

E sì, continuo ad amare Oracle, è come dovrebbe essere un DBMS fatto correttamente, ma questo non significa che il suo posto sia ovunque, almeno non al prezzo per cui vende.

+1

Un po 'OT, ma questa è una prospettiva interessante sullo spostamento della funzionalità al livello dell'applicazione. Di certo mi renderebbe nervoso - ho affrontato grandi database con problemi di incoerenza dei dati, ed è un incubo quasi indescrivibile. Rimuovere le protezioni del database e fidarsi del fatto che i programmatori dell'app riescano sempre a farlo bene sembra molto rischioso. – wadesworld

+0

eBay è piuttosto un esempio estremo. Se si adotta la propria metodologia per il proprio sviluppo, nel 99% dei casi si avrà una soluzione grossolanamente sovra-ingegnerizzata. –

+2

L'esempio di eBay intendeva dimostrare che anche un'azienda che ha abbastanza soldi ha problemi nell'implementazione di Oracle "nel modo giusto", molto probabilmente a causa dei costi di licenza. "i database sono il collo di bottiglia" è un buon modo per dire: non possiamo gettare abbastanza server DB perché la licenza per ogni server ci costerebbe $ xxx, xxx, quindi preferiremmo utilizzare molti server di app.David, non si tratta di adottare la loro metodologia, si tratta di un'azienda che sembra il cliente Oracle perfetto e come lo fanno. Lo trovo stimolante. L'alternativa a "troppo costoso" è: "non abbastanza veloce", che è peggio –

1

Oracle offre uno schema altamente sofisticato e complesso per il backup e il ripristino dei dati in tempo reale, offrendo funzionalità di backup a caldo non-stop.

Offre numerose funzioni analitiche e statistiche integrate per aggregare e riepilogare i dati. Puoi farlo con mySQL, ma nella tua app.

Ha un'eccellente scalabilità, se è necessario eseguire un grande sistema transazionale con integrità transazionale (commit/rollback). Se sei disposto a spendere un sacco di soldi, si ridimensiona con i Cluster di applicazioni reali.

Offre schemi per la gestione di codice incorporato (pacchetti, stored procedure, funzioni memorizzate) che si adattano bene a grandi quantità di codice e schemi complessi.

Fa un buon lavoro con elevati tassi di transazione (decine di migliaia all'ora), soprattutto quando si utilizzano query con variabili associate (oggetti PreparedStatement in JDBC). Soprattutto, le sue prestazioni per questo tipo di cose sono prevedibili.

È molto costoso e richiede un krewe di accoliti altamente qualificati per mantenerlo funzionante correttamente. La buona notizia è che ci sono molte persone esperte là fuori. Il posto in cui lavoro spende soldi con un gruppo chiamato Pythian Group per badare al nostro Oracle, che è un buon modo per andare.

È possibile valutarlo con l'Express Edition (gratuito, limitato a un paio di gigabyte di dati).

Se il sistema può funzionare con Oracle Standard Edition, utilizzare invece mySQL. Se il sistema richiede le funzionalità di Enterprise Edition, è necessario valutare anche IBM DB2, poiché entrambi sono progettati per il ridimensionamento.

1

Ci sono una varietà di cose che Oracle fa molto bene, forse meglio di qualsiasi altro rdbms (non conosco DB2 abbastanza bene da lasciare questo non qualificato). Il clustering (RAC) è molto, molto buono.Il linguaggio di procedura memorizzato, PL/SQL, è molto solido e in realtà piacevole da codificare. Esistono buone funzionalità XML, GIS, full-text, ecc.

Ma l'interruttore assoluto per me è che l'ottimizzatore funziona bene . Gli dai una query e ti restituisce un set di risultati in maniera efficiente. Occasionalmente si conoscono alcuni dettagli che non sono e devono fornire un suggerimento di conseguenza, ma questa è la rara eccezione. Si emettono le istruzioni SELECT, INSERT, UPDATE e DELETE e il database funziona come dovrebbe.

2

Non so niente di Oracle, ma dal momento che la questione è stata ampliata per includere, per esempio, Postgres ...

alcune cose che ho usato personalmente o visto usare in Postgres che non esistono realmente in MySQL (AFAICT)!

  • transazioni e ricerca full-text insieme

So che è popolare per utilizzare un FTS esterni poiché MySQL non ne ha uno. Personalmente, non ho avuto altro che problemi nell'utilizzo di soluzioni FTS separate: se è possibile che le due origini dati non siano sincronizzate, posso garantire che a un certo punto lo faranno. Potrei usare BDB e scrivere anche i miei indici, ma non lo faccio, perché non vedo in che modo sia migliore di un indice incorporato e un sacco di modi in cui è peggio. (OK, in un caso avevo bisogno di un indice personalizzato strano, e per questo è bello.Se hai bisogno di un FTS personalizzato strano, allora forse Sphinx è più flessibile, ma non ho mai visto un reale bisogno di uno strano FTS personalizzato, e io non sono nemmeno sicuro che Sfinge è più flessibile di Postgres FTS.)

query
  • spaziali (PostGIS)

non so se MySQL ha un meccanismo di estensione che permette questo, ma io Sono abbastanza sicuro che non abbia un'estensione come PostGIS. Supponiamo che tu voglia interrogare tutte le caffetterie entro 300 metri da un parco, e non entro 100 metri da una discarica (dato che il tuo database ha i confini di parchi, discariche e caffetterie). È straordinariamente facile con PostGIS. Con MySQL, penso che probabilmente sarebbe una buona quantità di lavoro.

  • tabelle relazionali a oggetti

Rails persone (hey, ho usato per essere uno!), In particolare, piace usare STI e fingere che tutte le sottoclassi hanno più o meno gli stessi campi della superclasse. Va bene se hai solo un paio di sottoclassi o sono tutte molto simili, ma provare a mappare una gerarchia di classi in tabelle può diventare abbastanza folle abbastanza velocemente. In Postgres, è facile: creare una nuova tabella che erediti dal primo e aggiunge i suoi campi, proprio come la sottoclasse nel tuo linguaggio di programmazione. Un modello di dati che corrisponde effettivamente ai miei dati! Non bello come un vero OODB ma piuttosto dannatamente vicino.

  • transazioni migliori

So che se si bastone con InnoDB si ottiene transazioni per tutte le operazioni di manipolazione dei dati. Postgres ha anche transazioni per tutte le operazioni definizione dei dati operazioni. Prendiamo un caso comune: ho bisogno di una migrazione per aggiungere una colonna, convertire i dati dal vecchio formato nel nuovo formato e rimuovere una vecchia colonna. In Postgres, faccio tutto tutto in un'unica transazione, e non ho alcuna possibilità che finisca con questa transazione parzialmente applicata.In MySQL, può fare il passaggio di conversione dei dati in una transazione, certo, ma se deve essere ripristinato, la nuova colonna è stata ancora aggiunta, quindi è necessario pulirla manualmente o scrivere una transazione più complessa da gestire quello (e anche allora non è ancora atomico nel db). Ripeti ogni giorno e goditi il ​​dolore.

(Il tema generale che vedo qui è la capacità di dire esattamente cosa intendo, e quindi lavorare a un livello più alto di astrazione. Vuoi FTS sui miei dati? Quindi creare un indice FTS. Vuoi una query spaziale? una query spaziale: vuoi memorizzare i dati di sottoclassi ?, quindi creare una tabella di sottoclassi. Vuoi una migrazione completamente atomica? Quindi esegui uno schiaffo su una transazione e chiamiamola un giorno. Certo, posso implementare qualcuno di questi in MySQL, ma poi I ' Devo pensare e implementare e mantenere quell'altra cosa , piuttosto che scrivere solo una singola riga di SQL. Come programmatore professionista non c'è niente di più prezioso per me che essere in grado di lavorare ad un livello più alto di astrazione, punto e basta.)

Ora, non sono sicuro se dovessi dire che Postgres è generalmente "migliore" di MySQL - ci sono certamente cose che MySQL fa molto meglio e quindi sicuramente ha i suoi usi - ma queste sono alcune cose che adoro assolutamente.

Problemi correlati