Dove mettere il database?

di il
8 risposte

Dove mettere il database?

Buonasera a tutti,
apro questo 3d per aver qualche parere riguardo una questione.

Ipotesi: ho un database con migliaia di record. Altri record possono essere inseriti in qualsiasi istante da più utenti simultaneamente quindi non è possibile definire a priori la dimensione del database (aumenta continuamente, potreste immaginarlo tendere ad infinito ). Inoltre, il database viene interrogato continuamente e simultaneamente da migliaia di utenti.
Scusate se non entro nei dettagli ma, come scritto, al momento è una questione puramente teorica. Se vi servono dei dettagli specifici ditemi pure e vi risponderò.

Domanda: dove metto il database?

Tra le opzioni che posso valutare ho:
- Mettere il database su un web server. In questo caso però ho letto che le prestazioni decadono velocemente, con rischio "crash" quando le richieste diventano troppe. Immagino tuttavia che ci possano essere dei web server (a pagamento chiaramente) che offrono soluzioni affidabili ed in tal caso vi chiedo qualche consiglio.
- Mettere il database su un PC ed accederne quindi in remoto. Per questo caso, ho letto un esempio in cui veniva citato un vecchio computer i3 in grado di rispondere e gestire senza problemi migliaia di richieste simultanee.

Vi chiedo dunque pareri a riguardo e soprattutto vorrei capire che budget servirebbe per portar a termine questo compito.

Grazie in anticipo a chi vorrà partecipare alla discussione!

8 Risposte

  • Re: Dove mettere il database?

    0) NON E' IL db che metti da qualche parte, ma il dbms (database management system)
    1) il dbms NON DEVE MAI ESSERE ACCESSIBILE DIRETTAMENTE, ma SOLO attraverso un'applicazione
    2) il dbms si dovrebbe trovare nella stessa rete dell'applicazione.

    La soluzione 1) va bene perche' c'e' un web server che ne maschera l'accesso: la tua applicazione puo' accedere al dbms SOLO attaverso un'applicazione web: ad esempio un servizio SOAP o REST. La tua applicazione potrebbe essere un'applicazione SPA (single page application) o un'app per dispositivi mobili

    La soluzione 2) va bene in tutti gli altri casi.

    Quindi, il problema NON E' dove mettere il dbms MA che tipo di applicazione vuoi realizzare.

    3) la gestione contemporanea di migliaia di accessi al dbms NON E' uno scherzo: servono risorse hardware adeguate, adeguate tecniche di programmazione e adeguate strategie di accesso.

    4) migliaia di record sono briciole per un dbms ragionevolmente decente. I problemi nascono quando si trattano CENTINAIA DI MILIONI/MILIARDI di record.
  • Re: Dove mettere il database?

    Concordo con migliorabile.
    Se posso chiedere, a quale tipo di database ti stai riferendo?
  • Re: Dove mettere il database?

    migliorabile ha scritto:


    3) la gestione contemporanea di migliaia di accessi al dbms NON E' uno scherzo: servono risorse hardware adeguate, adeguate tecniche di programmazione e adeguate strategie di accesso.
    Nel caso specifico in cui utilizzassi un web server (interrogando il db con le classiche pagine php) che limiti (in linea generale, chiaramente) avrei?
    E' chiaro che non potrò agire sulle risorse hardware, quindi la scelta del web server è cruciale: sapresti indirizzarmi ad una piattaforma affidabile?
    Per tecniche di programmazione e strategie di accesso, utilizzando questo caso, cosa intendi che dovrei fare?

    Grazie ancora!
  • Re: Dove mettere il database?

    Non esiste la risposta alle tue domande:

    1) certo che puoi agire sull'hardware: e' quello che si fa normalmente quando un sito deve assicurare tempi di accesso ben definiti a fronte di una certa quantita' di utenti che vi accedono contemporaneamente. Si fanno opportune statistiche al riguardo. E' solo una questione di soldi

    2) il web server NON E' un'entita' strana: e' la tua applicazione lato SERVER che fa il paio con la tua applicazione lato CLIENT

    3) per quanto riguardano le tecniche di programmazione e le strategie implementative, non sono argomenti che si possono spiegare a suon di post. Ci sono interi libri che le trattano. Ma tanto per fare degli esempi: uso di pool di connessioni per l'accesso al database, uso di cache per tenere il risultato delle query piu' frequenti, uso di pagine statiche generate mediante schedulazione al posto di pagine generate dinamicamente, uso di framework per semplificare la realizzazione di applicazioni Web (Spring, WCF), ecc...

    In altre parole: implementare un'applicazione che deve soddisfare migliaia di utenti contemporaneamente NON E' cosa per persone NON ESPERTE: servono PROFESSIONISTI.
  • Re: Dove mettere il database?

    Questa è la frase
    Altri record possono essere inseriti in qualsiasi istante da più utenti simultaneamente
    che ha la ripercussione più pesante, dal punto di vista tecnico.
    E' anche fondamentale capire se questi inserimenti sono tra loro collegati, oppure no. In sostanza se determinano delle race, oppure no.
    "Migliaia di richieste simultanee" implicano pochi millisecondi per essere servite, ciascuna.
    Il che significa sia una esecuzione sul database particolarmente rapida, sia un "qualcosa" in grado di riportare la risposta in pochi millisecondi.
    Di nuovo la situazione può diventare banalmente ingestibile anche solo per la quantità di dati da trasferire.
    Se essa è molto grande allora hai problemi difficili da affrontare, con qualsiasi hardware.
    Supponiamo, per fare i conti della serva, di avere 1.000 richieste al secondo (che, in media, ti assicuro non sono poche, parliamo ad esempio di un sito con 1 milione di utenti contemporanei).
    Supponiamo però che ogni richiesta implichi una risposta da 1MB ciascuna (che è parecchio).
    Con questo banale esempio vedrai che ti serve "qualcosa" in grado di maneggiare 1MBx1000=1GB al secondo, attraverso poi lo stack TCP.
    Qualcosa di molto, ma molto, ma molto raro (ne ho uno qui proprio ora sulla scrivania da consegnare in settimana, circa 50K euro, non è mio, lo sto solo preparando).

    Penso che macchine del genere si affittino sui 6.000 euro al mese.

    Ovviamente il carico medio per secondo sarà molto più basso, ma dovrai limitare di gran lunga anche l'IO, non più di qualche KB, e comunque avrai latenze di ogni genere.

    Insomma è come chiedere "come si progetta un aereo di linea" ?
    Non è proprio facilissimo.

    Su questo
    In altre parole: implementare un'applicazione che deve soddisfare migliaia di utenti contemporaneamente NON E' cosa per persone NON ESPERTE: servono PROFESSIONISTI.
    ... aggiungo ... che abbiano esperienza proprio in questo ambito
  • Re: Dove mettere il database?

    Riguardo a "dove" metterlo ci sono varie possibilità:
    - macchina singola (cioè interfaccia web con db sulla stessa macchina)
    - macchina singola, ma virtualizzata (cioè due macchine virtuali diverse)
    - due macchine fisiche (o anche più di due). possibilmente con link a 10GB (non ho mai visto niente in grado di saturare sullo stack 10GB, quindi i 40 mi parrebbero superflui in ogni caso). e una connessione internet rapida (1Gb)

    però, lo ribadisco, così a "occhio" le migliaia di accessi contemporanei si ridurranno a poche centinaia: distingui gli utenti (che non fanno nulla, tipo un forum, dove essenzialmente leggono alla velocità umana, cioè bassissima) da applicazioni che invece lavorano autonomamente (es. rilevazione dati produzione) con stream continui
  • Re: Dove mettere il database?

    Inoltre, il database viene interrogato continuamente e simultaneamente da migliaia di utenti
    Nella stessa unità di tempo significativa (1 sec) migliaia di utenti interrogano il DB? sei sicuro? se è cosi significa che il sistema è utilizzato giornalmente da decine di milioni di utenti......

    Se ci spieghi:
    1. di che sistema si tratta
    2. quanti utenti mediamente interagiscono potenzialmente nell'arco dello stesso secondo

    allora possiamo aiutarti a valutare l'architettura distribuita che più si adatta alle tue esigenze.
  • Re: Dove mettere il database?

    Scusa ma non capisco il problema:
    1) Se al DB accedono migliaia di utenti, allora può essere solo su di un web server. Che poi il server sia malauguratamente installato nella tua cantina o su di un'infrastruttura Clod, questo è un altro discorso.

    2) Se gestisci un database di tale portata, allora dovresti sapere che esistono tecniche software in grado di alleviare notevolmente il lavoro di un server.

    3) I web server non rallentano proprio niente. È solo una questione di costi: non credo che il tuo database, per quanto grande, sia in grado di mettere in difficoltà una grande infrastruttura Cloud, che in genere significa alcuni ettari di computer.
Devi accedere o registrarti per scrivere nel forum
8 risposte