La saggezza di fondere 100s di istanze di Oracle in un caso

Question

La nostra applicazione gira sul web, è per lo più uno strumento di indagine, fa alcune transazioni. Ospitiamo il database Oracle. L'applicazione ha sempre avuto una diversa istanza di Oracle per ogni cliente. A cliente è una società che ci paga per fornire il nostro servizio per i dipendenti della società, in genere 10,000-25,000 dipendenti per cliente. Abbiamo intenzione di avere diverse centinaia di clienti. Facciamo una major release ogni pochi anni, e la migrazione a quella nuova release è impegnativo: potremmo avere un team presso il cliente per un paio di settimane, che spiega la nuova funzionalità e l'impostazione dei dati di guida per soddisfare quel cliente.

Stiamo pensando di andare multi-client, mettendo tutti i nostri clienti in una singola istanza di Oracle 11g condivisa su un grande honkin' server Windows Server 2008 - al fine di ridurre i costi. Mi chiedo se questo è consigliabile.

Ci sono alcuni vantaggi ad avere istanze separate per ogni cliente. Dimmi se questi sono falsi, per favore. Nel mio occhio e croce circa importanza decrescente:

• I nostri clienti MyCorp e YourCo può essere migrato separatamente quando vengono apportate modifiche rottura allo schema. (Con il multi-client, saremmo migrando oltre 300 clienti durante la notte!?!)

• I dati di MyCorp possono essere facilmente sottoposti a backup e (!!!) restaurata, senza influenzare gli altri clienti.

• I dati di MyCorp è separato in modo sicuro dal loro concorrente dei dati di YourCo, senza dipendere da sviluppatori per ottenere il codice a destra e / o amministratori di database di ottenere il diritto di configurazione.

• Più istanze sono più basso rischio, a causa di un disastro con un cliente (qualcuno raddoppia accidentalmente lo stipendio di tutti e l'errore viene scoperto dopo giorno di paga) non influenza gli altri clienti. Un disastro che ha colpito tutti i nostri clienti (whoops, nuova DBA, e improvvisamente ogni partecipante ha lo stesso SSN!?!) Potrebbe mettere la nostra società sotto.

• Avere un'istanza su un server presenta un singolo punto di errore, con tutta la nostra base di clienti fuori dal mercato se un uragano bussa l'edificio sopra. Più istanze su più server permette dispersione geografica:. Nessuna catastrofe interesserà una percentuale troppo elevata dei nostri clienti, ei server non colpiti in altre regioni può assumere il carico dei server falliti

• La prestazione è migliore perché il database è di piccole dimensioni (10.000 vs 2.000.000 righe in ~ 50 tabelle).

• Se gli uffici di MyCorp sono (per lo più) in una sola regione, quindi esempio del MyCorp può essere geograficamente co-si trova lì, in modo da cadute di linea non fa male le prestazioni. Siamo in grado di fornire un servizio migliore ai clienti globali, per la stessa ragione.

• In MyCorp vuole prendere il loro database in-house, allora si può facilmente esportare il loro esempio, per ottenere MyCorp i loro dati.

• bilanciamento del carico è più facile, perché le istanze possono essere posizionati su diversi server (si tratta di una web farm).

• Quando è necessario un DEV o un'istanza QA, è più facile clonare il vero istanza e anonimi i dati, perché c'è molto meno dati.

• Perché sono abbastanza piccoli, gli sviluppatori possono avere la propria istanza in esecuzione a livello locale, in modo che possano lavorare sul codice durante l'attesa in aeroporto e, mentre in volo, senza combattere problemi VPN.

  

Q1: Quali sono gli altri vantaggi di istanze separate

?

Stiamo contemplando cambiare lo schema del database e la fusione tutti i nostri clienti in un caso di Oracle, in esecuzione su un server pesante.

Qui ci sono vantaggi della multi-client esempio approccio, più importante prima (il mio WAG) snipe se questi sono falsi:.

• Meno lavoro per gli amministratori di database, dal momento che hanno solo bisogno di mantenere un'istanza invece di centinaia. Meno lavoro DBA si traduce in più economico, il nostro motivo principale per questo cambiamento.

• Con un solo esempio, il DBA può fare un lavoro migliore di optimiziprestazioni ng. Avranno il tempo di aggiungere gli indici appropriati e rivedere la nostra SQL.

• Sarà più facile per gli sviluppatori di eseguire il debug e migliorare l'applicazione, perché non v'è un solo schema e un app (ci potrebbero essere decine di versioni di schema se ci sono centinaia di casi, con una diversa versione del app per ogni versione dello schema). Questo riduce i costi troppo. L'alternativa è dover iniziare ogni sessione di debug con (1) Quale versione è questo cliente corsa e (2) Diamo lotta per ricreare l'ambiente di sviluppo corrispondente, il codice e il database. (Abbiamo bisogno di una macchina virtuale che include l'istanza del codice e del database per ogni patch e release!)

• licenze Oracle è più conveniente perché è un prezzo per server a prescindere dal peso (o qualcosa - non so nulla su questo argomento).

• La banca dati diventa un archivio permanente valida per i dati di sessione web, perché non v'è solo un esempio.

• Alcune operazioni di database sono più facili con un caso multi-client, come trovare un partecipante quando sono confusa su cui clienti hanno (o il proprio coniuge, forse) lavora per: tutti i nomi sono in una tabella. Reporting attraverso i clienti è molto semplice.

  

Q2: Quali sono gli altri vantaggi di avere più clienti in un caso

?      

Q3: Quale approccio pensi che è meglio (perché)? Istanza per cliente, o tutti i clienti in un caso?

Sono preoccupato che avere un caso multi-client effettua la migrazione quasi impossibile, e questo è un affare assassino ...

... a meno che non ci sia una soluzione di compromesso come avere due casi multi-client, il vecchio e il nuovo. In questo caso caso, avremmo progettare soluzioni cross-esempio per la ricerca di partecipanti, reporting, ecc modo che i clienti potevano andare da un caso multi-client al prossimo senza nulla di rottura.

Answer 1

A meno che non si sta utilizzando Oracle XE (limitata, edizione gratuita) con un database per server diventare molto costoso molto rapidamente, anche se si sta acquistando single core, scatole CPU singoli. Avere diversi database per server è inefficiente, perché ogni database comporta un sovraccarico di CPU e RAM. Messa a punto è più difficile, perché contesa è più difficile da diagnosticare.

Quindi, oltre ad essere più facile da amministrare, un unico grande server dovrebbe funzionare più conveniente che un sacco di piccoli server discreti (non ci sono garanzie, senza soldi indietro!). Assicurati di acquistare i più grandi, i chip più veloci si può e quanta più RAM si dispone di slot liberi. Queste sono cose che ti danno prestazioni migliori senza alterare i costi di licenza.

Si consideri l'opzione di partizionamento, se lo può permettere. In questo modo le vostre preoccupazioni per quanto riguarda backup e ripristino, poiché ogni partizione può avere il proprio spazio tabelle. Così (data partizionamento dal client_id) diventa possibile eseguire il backup o il ripristino dei dati di un singolo cliente senza influenzare gli altri clienti. Possiamo anche partizioni di esportazione e l'importazione individuali. Sono sorpreso dall'osservazione di David che partizione potatura non ha funzionato con VPD. Ma non ho provato questo combo, quindi mi prendere la sua parola.

L'unica cosa che si potrebbe perdere dal consolidamento è la capacità di supportare i clienti differenti su diverse versioni della vostra applicazione. Tuttavia, questo non è necessariamente una cosa negativa. Come si osserva, mantenendo diverse centinaia di clienti sarà molto più facile se si rinunciate versioni personalizzate dell'applicazione. Se si ha bisogno di offrire alcune caratteristiche su misura - anche se volete solo beta test alcune funzionalità con un singolo cliente - poi dare un'occhiata a Ridefinizione Edition-based in 11gR2 : si tratta di una caratteristica davvero ingegnoso. Inoltre è disponibile per tutte le licenze Oracle, non solo Enterprise.

Answer 2

Quando si dice 'istanze separate', stai parlando di un caso con più schemi su di esso? O si fa sul serio più istanze in esecuzione su una singola macchina? Non v'è motivo di eseguire più istanze su una singola macchina, al contrario di esecuzione più schemi su una singola istanza - ogni schema sarebbe ancora hanno il loro proprio insieme di tabelle, indici, ecc

.

In ogni modo, non ho una risposta completa, ma una cosa da tenere a mente è il costi di licenza di Oracle, e come questo può influenzare ciò che la soluzione ottimale è.

Secondo il negozio di Oracle,

• Oracle Standard Edition One è $ 5,800.00 / Processor (dove su 86, un processore è un socket, e si può andare a un massimo di 2 prese)
• edizione standard Oracle è di $ 17,500.00 / Processor (dove su 86, un processore è un socket, e si può andare a fino a 4 socket)
• edizione Oracle Enterprise è di $ 47,500.00 / Processor (dove su 86, un processore è 2 core - quindi bisogna effettivamente raddoppiare quel prezzo per le CPU quad core)

Quindi, se, per esempio, è necessario 8 CPU quad core per gestire 100 clienti, licenza che su un singolo database è molto più costoso che avere 4 database separati, ciascuno con le CPU Core 2 Quad, ognuno dei quali esegue 25 clienti.

8 quad core CPU richiede enterprise edition, e avrebbe un prezzo di listino di 16 x $ 47.500 = $ 760.000. 4 macchine, ognuno dei quali esegue un'edizione standard, e ciascuno con 2 quad-core CPU, avrebbe un prezzo di listino di 8 x $ 5,800.00 = $ 46,400 - un fattore di 16 differenza. Ora, tenete a mente che nessuno paga prezzo di listino per l'edizione di impresa, ma c'è ancora una grande differenza di prendere in considerazione.

Se non si dispone di un enorme bisogno di operazioni di database attraverso i clienti, e non hai bisogno di funzionalità enterprise edition, e avete bisogno di questo livello di potenza della CPU (o prevede di crescere ad avere bisogno di questo livello di potenza della CPU), i costi di licenza stanno per essere un enorme svantaggio dell'approccio un esempio.

Answer 3

Può valere la pena ricercare forza vendita, e la parola buzz che stai cercando è "multi tenant"

Questo lo rende una buona lettura:

http: // blog. dayspring-tech.com/2009/02/forcecom-multitenant-architecture-under-the-covers/

E 'un buon esempio perché Salesforce fare utilizzare un db Oracle sotto le coperte.

Answer 4

Buona domanda, felice di vederti stanno prendendo in considerazione tutte le alternative. Un sacco di buoni punti, ma mi limiterò a solo affrontare uno.

Sono stato il DBA per un'applicazione ospitato e gli sviluppatori hanno deciso di utilizzare Oracle Database funzione Virtual Private per questo.

Il ricorso è stato costruito con l'intenzione di clienti che condividono un pool di server di applicazioni per il bilanciamento del carico e un singolo schema di database sul back-end.

Prima di VPD abbiamo avuto una classe Java che ha virato "dove customer_id =?" o "e customer_id =?" su ogni query a destra prima è andato al database in modo che il cliente avrebbe solo vedere i loro dati. Per implementare questo in VPD al login ot la DB avremmo l'applicazione impostare una variabile nel contesto app che sarebbe stato utilizzato dalle politiche VPD per consentire la sessione di vedere solo i loro record. Quindi sì, è necessario codificare fino a destra e assegnare criteri VPD alle tabelle, e anche fiducia che Oracle detiene la loro fine del patto.

Così è stato un bene per noi? In teoria è stato bello a scaricare lo SQL manipolazioni devono essere qualcosa al di fuori la nostra applicazione, ma in pratica i vantaggi non siano superiori agli svantaggi predicato.

• Quando abbiamo avuto decine di clienti in un database e quando abbiamo aggiornato tutti avevano per essere aggiornato allo stesso tempo. Abbiamo avuto un sacco di braccio di guerre con i clienti che non vogliono aggiornare per qualsiasi motivo o volevamo fare il proprio QA sulle nuove versioni.

• intrattenuti l'istanza precedente / Nuovo cosa esempio per gli aggiornamenti, ma i dati migrazione era rischioso e tempi di inattività associati non abbiamo fatto felici i clienti. Abbiamo fatto rotolare la nostra procedura che passo attraverso le tabelle ei dati di esportazione ... Ma di certo non è facile come un Export sveltina o di lavoro Data Pump.

• Abbiamo anche avuto problemi con l'analisi VPD predicato quando si trattava di partizionamento. Come con un sacco di caratteristiche di Oracle possono funzionare bene per conto loro, ma una volta che si combinano con altre funzioni di cose ottenere imprevedibile. Per noi non le partizioni legati al customer_id attuale non sono stati sempre eliminati perché l'analisi predicato era venuta troppo tardi nella lavorazione di SQL. Abbiamo lavorato intorno ad esso, cambiando da statico a dinamico politiche VPD ma il nostro tempo trascorso parsing vertiginosamente.

Così, dopo tutto che quello che è il mio prendere su di esso? Avrei speso il tempo assicurandosi la nostra applicazione ha fatto buon uso di variabili di bind e proseguita con il vecchio meccanismo che ha aggiunto customer_id per l'istruzione SQL.

Answer 5

Oracle è fatto per gestire questo tipo di carico.

La mia domanda -? Cosa fare quando si hanno migliaia di clienti e dire diecimila
Avete ancora mantenere istanze separate / schema?
Dubito che qualcuno lo farà. Ho lavorato in precedenza in un luogo in cui ogni cliente aveva database separato, così come una copia in un luogo centrale.
La gestione del cambiamento diventa un mal di testa, che avrebbe dovuto mantenere un ottimo informazioni su quali client / azienda è sulla base di dati che la revisione, lo schema, la versione app e tutte quelle cose. This'd diventare un software in sé.
Io suggerirei di creare software / design basato intorno modello SaaS, che ti consentono una facile manutenzione e allo stesso database / schema per tutti gli utenti.

Per affidabilità è comunque possibile utilizzare il clustering - Oracle RAC .

Answer 6

ho dovuto prendere in considerazione la stessa decisione un paio di volte. Nel nostro caso usiamo MySQL, quindi non ci sono costi associati alla gestione tutti i clienti in un database separato.

I benefici per l'esecuzione di tutti i nostri clienti su una banca dati separata sono stati grandi. Abbiamo uno script che ci permette di muoverci intera istanza di un cliente per qualsiasi server per bilanciare il carico. Lo script si limita copie oltre il database, le copie oltre qualsiasi file personalizzati, gira l'applicazione, e imposta il nostro sistema di routing per indirizzare gli utenti alla nuova istanza. L'intero processo richiede solo pochi minuti.

Le modifiche al database può richiedere molto tempo su grandi database MySQL. Dal momento che tutti i nostri clienti hanno la propria banca dati siamo in grado di mantenere tutti i nostri set di dati di piccole dimensioni. I backup sono anche molto veloce.

I nostri casi di sviluppo si comportano allo stesso modo, quindi questo metodo ci permette di eseguire una varietà di schemi di database contemporaneamente come abbiamo sviluppare e testare nuove funzionalità. Spesso lavorare con i clienti per farli provare una nuova funzione, prima di distribuire al resto delle nostre istanze. L'unica regola che ci atteniamo a (al fine di evitare alcuni degli svantaggi di cui parli), è che tutti i clienti devono essere all'interno di una versione di ogni altro. Il mantenimento di più di un paio di versioni in tutto i clienti avrebbe una testa enorme.

Facebook ha preso lo stesso approccio quando hanno iniziato la loro azienda. Ogni scuola che hanno lanciato a aveva un database separato e sono stati in grado di creare nuove istanze molto rapidamente. Il motivo principale che finalmente consolidato la loro base di dati era che volevano per consentire agli utenti di comunicare tra le scuole.

Se non fosse per i potenziali problemi di costo avrei sicuramente vi incoraggio a rimanere con il metodo database separato.