Soluzioni database di SQL Server ad alta transazione sovraccaricate

5

Il database SQL Server corrente è sovraccarico e molte transazioni non funzionano. I poteri che hanno una soluzione proposta per costruire un database separato per gestire / archiviare le transazioni e quindi inserirli in modo asincrono nel sistema corrente. In particolare, persistono nuove transazioni in un nuovo database, quindi creano routine per inserire i dati dal nuovo database nel database corrente / vecchio.

Sto cercando il metodo migliore per implementare questa soluzione ... dovrei usare una tabella non indicizzata nel nuovo db proposto per l'inserimento rapido, quindi utilizzare l'inserimento collettivo da newdb - > olddb per spostare nuovamente i dati nel database principale? È meglio farlo @ intervalli programmati o in tempo reale?

Mi stavo chiedendo anche se il ridimensionamento / out avrebbe aiutato qui (budget permettendo)? Il mio primo pensiero è stato quello di raccomandare l'acquisto di un secondo server e la configurazione di un cluster per ridurre il carico.

Per essere onesti pensavo che le transazioni web sarebbero andate in timeout e non fallire (ma immagino che alla fine sia lo stesso)?

    
posta bbqchickenrobot 20.04.2012 - 00:45
fonte

3 risposte

2

Il CQRS è un buon punto di partenza per molte cose. Ma non sono sicuro se sia giusto qui.

Ciò che stanno realmente proponendo è la creazione di un bus di servizio di qualche tipo. Il concetto generale è che la transazione live viene scritta in una coda di messaggi persistente che viene poi elaborata e inviata ai servizi appropriati. Potresti voler vedere [presumendo il tag SQL Server b / c]:

Per iniziare. Ci sono molte opzioni là fuori ma il modello proposto è solido. Un sacco di mine terrestri in questo spazio, rotolare il tuo è decisamente sconsigliato.

L'altro angolo qui è misurabile e strumentazione. Puoi sprecare un sacco di tempo a indovinare perché le cose si sono bloccate. Sapere perché le cose si sono schiantate è inestimabile.

    
risposta data 20.04.2012 - 03:36
fonte
1

Sì, questo genere di cose funziona, ma generalmente viene ottenuto utilizzando un database in memoria come TimesTen , abbiamo fatto qualcosa di simile per consegnare una quantità enorme di input CDR una volta. Dai un'occhiata ai white paper su quel sito per un buon consiglio nella configurazione di una tale configurazione, gli stessi principi si applicano se stai usando un DB "on-disk" invece di TimesTen.

Avrai ancora bisogno di un secondo server per eseguirlo, basta eseguire 2 istanze su un singolo server è inutile, ti conviene configurare la configurazione esistente piuttosto che eseguire 2 DB sullo stesso hardware. Dubito che un cluster sarà d'aiuto in quanto ha un po 'di overhead nel riconciliare le transazioni scritte sulle tabelle, ma ciò dipende dal carico di lavoro, indipendentemente dal fatto che ogni transazione sia completamente idemplificata o meno.

Il timeout può essere considerato un errore, ma tecnicamente sono cose diverse che puoi gestire in modi diversi.

    
risposta data 20.04.2012 - 01:05
fonte
1

Una soluzione molto simile alla tua proposta è "CQRS" e / o "sourcing di eventi", dovresti leggere su entrambi e scegliere gli aspetti particolari che possono essere applicati alla parte giusta della tua applicazione - assumendo che questa sia la risposta giusta.

Una semplice panoramica, che separa il tuo OLTP e il database di reporting, e applica la "segnalazione" come termine molto più ampio di prima. Sebbene non si possa pensare di "elencare tutti i prodotti acquistati da un cliente" come report poiché si tratta di una piccola transazione normalmente eseguita su OLTP, in CQRS si consiglia di considerare questo come dati di reporting.

Event sourcing ti incoraggia a registrare i dati delle transazioni e a utilizzarli per comporre i tuoi dati per rapporti / altri scopi.

Ri: clustering - dipende dai tuoi punti dolenti. Se la tua architettura dell'app non supporta il ridimensionamento, la configurazione di un cluster apporterà vantaggi minimi, forse la capacità del server 2x aumenterà le prestazioni del 10% a causa di colli di bottiglia chiave nell'elaborazione o nella struttura dei dati. (Legge di Amdahl).

    
risposta data 20.04.2012 - 01:56
fonte

Leggi altre domande sui tag