Quali grandi limiti dovrei aspettarmi dai server SQL collegati?


9

Il nostro prodotto si basa su Microsoft SQL Server. Attualmente stiamo utilizzando tre database e li abbiamo sempre distribuiti su un'istanza di SQL Server.

I tre database sono OLTP, OLAP e audit. Il database OLAP contiene enormi dati in entrata su EOD sia da OLTP che da audit, utilizzando query tra database.

Domande

Se dovessimo distribuire questi tre database in tre istanze Standard Edition separate all'interno di un singolo server fisico e collegarli insieme utilizzando la funzionalità Server collegato di SQL Server:

  1. Quanto sarà trasparente al codice dell'applicazione? Quanto cambiamento dovrei aspettarmi?
  2. I dati in entrata verso OLAP erano pari a 50k-100k righe, carico utile di 200-500 MB per EOD. Quanto calo di prestazioni dovrei aspettarmi?
  3. Quali altri grandi limiti dovrei aspettarmi?

sfondo

Attualmente stiamo presentando il nostro primo potenziale cliente con oltre 500 utenti simultanei.

Stiamo redigendo una specifica del server, che include 64 core e 256 GB di RAM. Affinché SQL Server utilizzi tutte queste risorse abbondanti, il client dovrebbe acquistare Enterprise Edition, che per SQL Server 2016 è disponibile solo nelle licenze basate su core.

Temiamo che il solo costo delle licenze (64 x $ 7400) li abbatterà. Quindi sto pensando di dividere il database in tre istanze di Standard Edition e di collegarle insieme, sperando che la funzionalità di collegamento sia trasparente dal codice dell'applicazione.

Risposte:


14

Quanto sarà trasparente al codice dell'applicazione? Quanto cambiamento dovrei aspettarmi?

Per niente trasparente. Aspettati grandi cambiamenti.

Dovresti essere preparato per un degrado delle prestazioni molto sostanziale.

La query distribuita (il framework per i server collegati) utilizza un modello OLEDB generale qualunque sia il server dall'altra parte. È vero che un target di SQL Server potrebbe essere in grado di offrire informazioni più complete (metadati, statistiche, ecc.), Ma il risultato non è ancora così strettamente integrato o capace come un'operazione nativa tra database.

Le query remote hanno una meritata reputazione per le prestazioni lente e le scelte di piano scarse da parte dell'ottimizzatore. Le istruzioni che modificano i dati (eliminazione, inserimento, aggiornamento, unione) sono particolarmente soggette poiché il modello di base è spesso quello di un cursore.


Se non hai mai bisogno di eseguire query ad hoc su più istanze, potresti essere in grado di ottimizzare manualmente ogni query memorizzata per prestazioni accettabili, ma questo è molto lavoro e il successo non è affatto garantito.

Per operazioni di massa trasversale esempio, si sarebbe molto meglio utilizzare le operazioni di vera e propria massa ( bcp, BULK INSERT, SSIS ... ecc.) Tra le istanze che usare server collegati.


Detto questo, l'idea di base sembra molto più problematica di quanto valga per me. Specifica l'hardware che funzionerà nei limiti della Standard Edition; oppure, se il client richiede prestazioni più elevate, ottenere un server più grande e utilizzare Enterprise Edition.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.