Ridimensionamento delle tabelle con partizioni o con database separati?

Naviga le tue risposte
3

Diciamo che ho una tabella (chiamiamola BigTable ) che potrebbe contenere 5.000.000 di INSERTI al giorno (con possibilmente altrettanti SELECT). Ogni riga inserita è di circa 50kb.

Questi INSERT giornalieri sono suddivisi equamente tra 5 client (la tabella ha un FK chiamato ClientID ). Non è mai necessario selezionare o UNIRE dati su più client.

Sono preoccupato per le prestazioni del database man mano che questa tabella cresce, quindi ho trovato tre soluzioni.

SOLUZIONE 1:

  • Partizione BigTable di ClientID
  • Memorizza ogni partizione su un disco rigido separato sul server (utilizzando la memoria blog di Azure).
  • Partizione di tutti i dati che hanno 1 mese di vita (i dati dell'archivio devono ancora essere interrogabili) in un'altra serie di partizioni READONLY.

In sostanza ciò significa le seguenti partizioni sui propri dispositivi di archiviazione:

  • Principale (tutti i dati escludendo BigTable )
  • BigTable del clienteA (5.000.000 di file al giorno / 5 client x 30 giorni = 30.000.000 di righe)
  • BigTable del cliente B (30.000.000 di righe)
  • BigTable di ClientC (30.000.000 di righe)
  • BigTable di clientD (30.000.000 di righe)
  • BigTable di ClientE (30.000.000 di righe)
  • BigTable archivio
    • del cliente
  • BigTable archivio <% li> del cliente
  • BigTable archivio di ClientC
  • BigTable archivio di ClientD
  • BigTable archivio di ClientE

Il numero di righe nelle tabelle di archivio sarà (5.000.000) x (l'età del DB in giorni) - (30.000.000). Questo è ancora un tavolo enorme, ma sarà usato solo per redigere il rapporto dispari.

SQL Server sarà ospitato su un VM Azure 8 core da 14 GB.

SOLUZIONE 2:

L'altra opzione è di ospitare database separati per ogni cliente. Ciò significa che ognuno avrà la propria macchina SQL Server dedicata. Il partizionamento si verificherà ancora per i dati di archivio.

Questa opzione non è ottimale a causa della separazione fisica dei dati. Dover gestire gli aggiornamenti su più database potrebbe essere molto problematico. Anche avere connessioni di database separate per ogni cliente sarà una considerazione per gli sviluppatori.

Qualcuno potrebbe consigliare su queste opzioni?

SOLUZIONE 3:

Archiviare i dati in una piattaforma di database più veloce. Non ne so molto, ma forse un database NoSQL potrebbe gestire miliardi di record molto meglio di SQL Server?

    
posta davenewza 18.02.2013 - 15:30
fonte

1 risposta

5

Vorrei andare con l'opzione 2. .

Certamente non hai bisogno di una macchina SQL Server dedicata per ogni client, non hai nemmeno bisogno di istanza dedicata. Non so che tu pensi che sia così.

La mia ragione principale è che quando arriva il momento in cui vuoi ridimensionare orizzontalmente (più server) questo ti consentirà di farlo meglio.

Non capisco perché pensi che "gestire gli aggiornamenti su più database possa essere molto problematico" . Trattare con diverse connessioni Db è banale, non capisco neanche questa preoccupazione. Tutto ciò è particolarmente vero perché "Non è mai necessario selezionare o UNIRE dati su più client."

Nota aggiuntiva: è ancora possibile partizionare i singoli DB client (per data o qualcosa) se si sceglie \ necessario farlo.

    
risposta data 19.02.2013 - 01:35
fonte

Leggi altre domande sui tag

Identificazione dei servizi di dominio e dei servizi di applicazione durante il DDD JAVA IDE - Breakpoint condizionali