Mostra notizie nelle discussioni
  • Avatar
    Scritto da
    Non Autenticato
    il 2017-05-07 15:56:08.0 alle 2017-05-07 15:56:08.0
    Programmazione: quando in memoria devi gestire dati di grosse dimensioni
    Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.

    Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.

    Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.

    Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.

    Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?
    • Avatar
      ☺
      Scritto da
      ::1
      il 2017-05-07 16:09:50.0 alle 2017-05-07 16:09:50.0
      Trollate totali: 12321
      Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
      Scritto da:
      > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
      >
      > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
      >
      > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
      >
      > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
      >
      > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?

      Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
      Young professional woman and busy mom.
      • Avatar
        Scritto da
        Non Autenticato
        il 2017-05-07 19:35:52.0 alle 2017-05-07 19:35:52.0
        Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
        Scritto da: ::1
        > Scritto da:
        > > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
        > >
        > > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
        > >
        > > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
        > >
        > > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
        > >
        > > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?
        >
        > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?

        Vuoi dire che nella response dovrei metterci i dati binari?

        Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...

        ... tieni presente che i dati della response se li prende un client javascript che poi li passa in parametro a un prototipo che genera un image slider.

        Per farti capire...

        La funzione whenOk quella che viene chiamata quando tutto è andato liscio.

        var server = new WebServerCommunication();

    var loader = getLoader();

    server.getDataFromServer("/Pictures/Pictures", atStart, atEnd, whenOk, whenFailed);

    function whenOk(response) {
        new ImageSlider(response).buildAndAppendTo(document.querySelector(".content_container"));
    }

    function whenFailed(response) {
        clearAndInjectHTMLInErrorsContainer(response);
    }

    function atStart() {
        clearAndInjectDOMContent(loader);
    }

    function atEnd() {
        getContentSection().removeChild(loader);
    }
        • Avatar
          ☺
          Scritto da
          Wakko Warner
          Wakkus Horribilis
          il 2017-05-07 19:37:29.0 alle 2017-05-07 19:37:29.0
          Trollate totali: 6779
          Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
          Scritto da:
          > Scritto da: ::1
          > > Scritto da:
          > > > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
          > > >
          > > > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
          > > >
          > > > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
          > > >
          > > > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
          > > >
          > > > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?
          > >
          > > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
          >
          > Vuoi dire che nella response dovrei metterci i dati binari?
          >
          > Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...

          <img src="blablabla\getFileByID.php?ID=48838" />

          Newbie, inesperto

          getFileByID.php è uno script semplice semplice che si limita ad inviare il file in binario. Il file può essere dove ti pare, nel FS o nel DB. È una tecnica che uso per nascondere il percorso reale del file nel mio FS.

          **Modificato dall'autore il 07.05.2017 19:39**
          Gli Svizzeri non sono tutti ricchi - Mattia
          • Avatar
            Scritto da
            Non Autenticato
            il 2017-05-07 19:53:55.0 alle 2017-05-07 19:53:55.0
            Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
            Scritto da: Wakko Warner
            > Scritto da:
            > > Scritto da: ::1
            > > > Scritto da:
            > > > > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
            > > > >
            > > > > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
            > > > >
            > > > > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
            > > > >
            > > > > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
            > > > >
            > > > > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?
            > > >
            > > > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
            > >
            > > Vuoi dire che nella response dovrei metterci i dati binari?
            > >
            > > Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...
            >
            > <img src="blablabla\getFileByID.php?ID=48838" />
            >
            > Newbie, inesperto
            >
            > getFileByID.php è uno script semplice semplice che si limita ad inviare il file in binario. Il file può essere dove ti pare, nel FS o nel DB. È una tecnica che uso per nascondere il percorso reale del file nel mio FS.
            >
            > **Modificato dall'autore il 07.05.2017 19:39**

            Quindi al src di un img puoi anche dare dati binari?

            avvelentani dice di creare un handler... possono anche creare semplicemente un controller? (uso ASP.NET MVC)

            E che MIME devo dare alla response?
            • Avatar
              Scritto da
              Non Autenticato
              il 2017-05-07 19:58:48.0 alle 2017-05-07 19:58:48.0
              Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
              Scritto da:
              > Scritto da: Wakko Warner
              > > Scritto da:
              > > > Scritto da: ::1
              > > > > Scritto da:
              > > > > > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
              > > > > >
              > > > > > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
              > > > > >
              > > > > > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
              > > > > >
              > > > > > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
              > > > > >
              > > > > > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?
              > > > >
              > > > > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
              > > >
              > > > Vuoi dire che nella response dovrei metterci i dati binari?
              > > >
              > > > Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...
              > >
              > > <img src="blablabla\getFileByID.php?ID=48838" />
              > >
              > > Newbie, inesperto
              > >
              > > getFileByID.php è uno script semplice semplice che si limita ad inviare il file in binario. Il file può essere dove ti pare, nel FS o nel DB. È una tecnica che uso per nascondere il percorso reale del file nel mio FS.
              > >
              > > **Modificato dall'autore il 07.05.2017 19:39**
              >
              > Quindi al src di un img puoi anche dare dati binari?

              Ok, domanda stupida... Imbarazzato una path ritorna dati binari.

              Rigiro la domanda: se ci inietto i dati binari con javascript funziona?
              >
              > avvelentani dice di creare un handler... possono anche creare semplicemente un controller? (uso ASP.NET MVC)
              >
              > E che MIME devo dare alla response?
              >
            • Avatar
              ☺
              Scritto da
              avvelentani
              Cubicolario
              il 2017-05-07 20:06:23.0 alle 2017-05-07 20:06:23.0
              Trollate totali: 18184
              Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
              Scritto da:
              > Scritto da: Wakko Warner
              > > Scritto da:
              > > > Scritto da: ::1
              > > > > Scritto da:
              > > > >
              > > > > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
              > > >
              > > > Vuoi dire che nella response dovrei metterci i dati binari?
              > > >
              > > > Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...
              > >
              > > <img src="blablabla\getFileByID.php?ID=48838" />
              > >
              > > Newbie, inesperto
              > >
              > > getFileByID.php è uno script semplice semplice che si limita ad inviare il file in binario. Il file può essere dove ti pare, nel FS o nel DB. È una tecnica che uso per nascondere il percorso reale del file nel mio FS.
              > >
              > > **Modificato dall'autore il 07.05.2017 19:39**
              >
              > Quindi al src di un img puoi anche dare dati binari?
              >
              > avvelentani dice di creare un handler... possono anche creare semplicemente un controller? (uso ASP.NET MVC)
              >
              > E che MIME devo dare alla response?
              >

              sei in alto mare.
              I think happiness is love
              - Vladimir Putin
              • Avatar
                Scritto da
                Non Autenticato
                il 2017-05-07 20:13:31.0 alle 2017-05-07 20:13:31.0
                Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
                Scritto da: avvelentani
                > Scritto da:
                > > Scritto da: Wakko Warner
                > > > Scritto da:
                > > > > Scritto da: ::1
                > > > > > Scritto da:
                > > > > >
                > > > > > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
                > > > >
                > > > > Vuoi dire che nella response dovrei metterci i dati binari?
                > > > >
                > > > > Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...
                > > >
                > > > <img src="blablabla\getFileByID.php?ID=48838" />
                > > >
                > > > Newbie, inesperto
                > > >
                > > > getFileByID.php è uno script semplice semplice che si limita ad inviare il file in binario. Il file può essere dove ti pare, nel FS o nel DB. È una tecnica che uso per nascondere il percorso reale del file nel mio FS.
                > > >
                > > > **Modificato dall'autore il 07.05.2017 19:39**
                > >
                > > Quindi al src di un img puoi anche dare dati binari?
                > >
                > > avvelentani dice di creare un handler... possono anche creare semplicemente un controller? (uso ASP.NET MVC)
                > >
                > > E che MIME devo dare alla response?
                > >
                >
                > sei in alto mare.

                Spiega...
        • Avatar
          Scritto da
          Non Autenticato
          il 2017-05-07 19:40:22.0 alle 2017-05-07 19:40:22.0
          Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
          Scritto da:
          > Scritto da: ::1
          > > Scritto da:
          > > > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
          > > >
          > > > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
          > > >
          > > > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
          > > >
          > > > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
          > > >
          > > > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?
          > >
          > > Perché non le outputti così come sono dal db invece di basesessantaquattrizzarle?
          >
          > Vuoi dire che nella response dovrei metterci i dati binari?
          >
          > Il problema è che non conosco un modo in HTML per renderizzare immagini partendo da dati binari...
          >
          > ... tieni presente che i dati della response se li prende un client javascript che poi li passa in parametro a un prototipo che genera un image slider.
          >
          > Per farti capire...
          >
          > La funzione whenOk quella che viene chiamata quando tutto è andato liscio.
          >
          > 
          var server = new WebServerCommunication();
> 
> var loader = getLoader();
> 
> server.getDataFromServer("/Pictures/Pictures", atStart, atEnd, whenOk, whenFailed);
> 
> function whenOk(response) {
> new ImageSlider(response).buildAndAppendTo(document.querySelector(".content_container"));
> }
> 
> function whenFailed(response) {
> clearAndInjectHTMLInErrorsContainer(response);
> }
> 
> function atStart() {
> clearAndInjectDOMContent(loader);
> }
> 
> function atEnd() {
> getContentSection().removeChild(loader);
> }


          E comunque anche con i dati binari si può presentare lo stesso problema... solo che i file devono essere più grandi per crearti il problema... quindi alla fine devi avere un modo pulito per fare quello che devi fare sapendo che non ci saranno problemi.

    • Avatar
      ☺
      Scritto da
      avvelentani
      Cubicolario
      il 2017-05-07 16:10:15.0 alle 2017-05-07 16:10:15.0
      Trollate totali: 18184
      Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
      Scritto da:
      > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.

      mi sembra inutilmente inefficiente.

      > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?

      tanto per cominciare non fare la conversione in base64, fatti un handler e servile come immagini. Pero` se ne hai tante e sono grosse il modo ottimale di servirle e` metterle sul filesystem e usare un server apposta che serve solo i contenuti statici, in questo modo puoi configurare il tuo server http per far fare tutto il lavoro al kernel usando sendfile(2).
      I think happiness is love
      - Vladimir Putin
    • Avatar
      Scritto da
      Non Autenticato
      il 2017-05-07 17:45:23.0 alle 2017-05-07 17:45:23.0
      Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
      Scritto da:
      > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
      >
      > Il problema è che nel sito che sto sviluppando voglio permettere di caricare immagini fino a 30 MB... che non sono tanti, ma sono già abbastanza per creare problemi quando caricati nella memoria volatile.
      >
      > Facendo l'operazione di creare una codifica in base 64 delle immagini si vengono a creare delle stringhe mastodontiche, che poi quando concatenate insieme dal serializzatore JSON danno origine a una stringa troppo grande, che causa un OutOfMemoryException.
      >
      > Se anziché caricare tutte le immagini insieme, né caricassi una alla volta (con request separate) eviterei l'OutOfMemoryException (quindi il problema lato server), ma poi se ne viene a creare uno lato client: a quanto pare per google chrome anche una sola di quelle stringhe è già troppo, visto che quando arriva la response dal server si freeza.
      >
      > Chiaramente il problema si potrebbe aggirare mantenendo le immagine nel filesystem anziché nel database, ma visto che mantenere file nei database è una cosa che si usa fare... ci sarà pur un modo per evitare di spaccare la memoria volatile, no?

      Questa è un'altra branca dell'UCAS.
    • Avatar
      ☺
      Scritto da
      Wakko Warner
      Wakkus Horribilis
      il 2017-05-07 18:28:23.0 alle 2017-05-07 18:28:23.0
      Trollate totali: 6779
      Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
      Scritto da:
      > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database

      $facepalm

      > (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.

      Le immagini mettile nel FS. Ti risparmi un SACCO di problemi, presenti e futuri, incluso il problema di cui ti lamenti.

      Il database non è fatto per scriverci sopra immagini, allegati, ecc. Memorizza nel FS e nel DB tieni solo un riferimento al nome del file nel FS. Tutti i tuoi problemi spariranno magicamente e quando un giorno dovrai migrare il database vedrai che è molto più facile backuppare e ripristinare un database di 1MB piuttosto che uno di 10GB.
      Gli Svizzeri non sono tutti ricchi - Mattia
      • Avatar
        ☺
        Scritto da
        altg
        utente che non utiene
        il 2017-05-07 18:33:31.0 alle 2017-05-07 18:33:31.0
        Trollate totali: 11540
        Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
        > Il database non è fatto per scriverci sopra immagini, allegati, ecc. Memorizza nel FS e nel DB tieni solo un riferimento al nome del file nel FS. Tutti i tuoi problemi spariranno magicamente e quando un giorno dovrai migrare il database vedrai che è molto più facile backuppare e ripristinare un database di 1MB piuttosto che uno di 10GB.

        Avrebbe il vantaggio che backuppando il database backupperesti anche tutti i file in un un'unica operazione, e quello che non dovresti preoccuparti di qualcuno che riesca ad eseguire i file una volta caricati sul server, tramite una qualche falla del server, ma si`: sono un po' pochino per giustificare il mostruoso bloating del DB e lo spreco di tempo macchina e memoria di lavoro.

        p.s. che nessuno guardi come Postline gestisce il DB. Emula un DB relazionale all'interno del DBMS sottostante, per essere compatibile con una soluzione alternativa flat-file in caso di assenza di un DBMS sul server. In pratica memorizza i record in file virtuali ognuno dei quali e` una tupla in una table del database. Inoltre base-64izza tutto il contenuto dei file virtuali per andare sul sicuro nell'evitare SQL injections, anche se ogni file e` limitato da un numero massimo di records, e la lunghezza di ogni record e` di magnitudine prevedibile, sicche` si creino file virtuali molto raramente piu` lunghi di 200-300 Kb. Poi mantiene tutto un sistema di caching in memoria dei file de-64izzati, e usa la cache write-behind per fare un commit coerente delle operazioni che comportano modifiche a piu` file. Ma quello e` perche` l'ha scritto un pazzo.

        **Modificato dall'autore il 07.05.2017 18:47**
        • Avatar
          ☺
          Scritto da
          Wakko Warner
          Wakkus Horribilis
          il 2017-05-07 19:17:48.0 alle 2017-05-07 19:17:48.0
          Trollate totali: 6779
          Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
          Scritto da: altg
          > Avrebbe il vantaggio che backuppando il database backupperesti anche tutti i file in un un'unica operazione, e quello che non dovresti preoccuparti di qualcuno che riesca ad eseguire i file una volta caricati sul server, tramite una qualche falla del server, ma si`: sono un po' pochino per giustificare il mostruoso bloating del DB e lo spreco di tempo macchina e memoria di lavoro.

          È un non-vantaggio, perché il database cresce a dismisura, e soprattutto i database che "backuppano" in formato testuale (tipo MySQL) creano file enormi che poi ti stanno ORE (ripeto: ORE) ad essere ripristinati. Ammesso che il backup abbia successo, cosa tutt'altro che garantita, soprattutto se devi farlo con PHPMyAdmin che ha timeout di vario tipo che possono scattare nel frattempo.

          Stai molto meno a fare un backup regolare dei file e lasciare che il database si occupi di quello che è inteso occuparsi: dati testuali (ordinabili, ricercabili, ecc), non dati binari.

          Fidati, ci sono passato. Da bravo niubbo ebbi la stessa brillante idea, me ne sono pentito dopo e non ho più fatto quell'errore. Ogni volta che ho usato il database come fosse un filesystem ci ho rimesso in tempo e salute.
          Gli Svizzeri non sono tutti ricchi - Mattia
      • Avatar
        Scritto da
        Non Autenticato
        il 2017-05-07 19:25:16.0 alle 2017-05-07 19:25:16.0
        Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
        Scritto da: Wakko Warner
        > Le immagini mettile nel FS. Ti risparmi un SACCO di problemi, presenti e futuri, incluso il problema di cui ti lamenti.
        >
        > Il database non è fatto per scriverci sopra immagini, allegati, ecc. Memorizza nel FS e nel DB tieni solo un riferimento al nome del file nel FS. Tutti i tuoi problemi spariranno magicamente e quando un giorno dovrai migrare il database vedrai che è molto più facile backuppare e ripristinare un database di 1MB piuttosto che uno di 10GB.

        Quando il software è tuo puoi fare come meglio credi, ma se hai il cliente sistemista di turno che vuole che tutti i dati finiscano nel database, cosicché lui possa backuppare tutti i dati semplicemente backuppando il database, devi fare come lui vuole... e come implementare il software in base alla direttive sono fatti tuoi.

        Il tuo suggerimento è buono e magari alla fine farò come dici tu, però intanto voglio studiare la soluzione al problema così quando si presenterà il sistemista cocciuto saprò come fare.


        • Avatar
          ☺
          Scritto da
          Wakko Warner
          Wakkus Horribilis
          il 2017-05-07 19:36:01.0 alle 2017-05-07 19:36:01.0
          Trollate totali: 6779
          Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
          Scritto da:
          > Scritto da: Wakko Warner
          > > Le immagini mettile nel FS. Ti risparmi un SACCO di problemi, presenti e futuri, incluso il problema di cui ti lamenti.
          > >
          > > Il database non è fatto per scriverci sopra immagini, allegati, ecc. Memorizza nel FS e nel DB tieni solo un riferimento al nome del file nel FS. Tutti i tuoi problemi spariranno magicamente e quando un giorno dovrai migrare il database vedrai che è molto più facile backuppare e ripristinare un database di 1MB piuttosto che uno di 10GB.
          >
          > Quando il software è tuo puoi fare come meglio credi, ma se hai il cliente sistemista di turno che vuole che tutti i dati finiscano nel database, cosicché lui possa backuppare tutti i dati semplicemente backuppando il database, devi fare come lui vuole... e come implementare il software in base alla direttive sono fatti tuoi.
          >
          > Il tuo suggerimento è buono e magari alla fine farò come dici tu, però intanto voglio studiare la soluzione al problema così quando si presenterà il sistemista cocciuto saprò come fare.

          Nessun sistemista con un po' di buon senso ti dirà che devi registrare i dati nel database, se lo fa insisti che non si può fare per tutta una serie di ragioni molto pratiche e molto concrete:
          1) impossibilità a fare in modo semplice il backup dei soli file. Se i file sono sul FS te la cavi con un file batch
          2) impossibilità ad accedere direttamente ai file, devi per forza farti un programmino che va ad estrarli dal database
          3) esplosione delle dimensioni del database che finiscono per influenzare negativamente sulle performance dello stesso
          4) rende i backup del database molto grossi e molto lunghi da ripristinare
          5) influisce negativamente sulle performance del sito in quanto tutte gli accessi ai file devono passare tramite database che se sta facendo quello non sta facendo altro, in altre parole occupi risorse al database inutilmente
          6) impossibilità di separare i file (magari mettendoli su un altro server) dal database
          7) di solito il database si paga a parte, e si paga in base alla sua dimensione, cosa solitamente non vera per il FS. Esempio: Aruba ti da spazio illimitato, ma lo spazio del DB lo paghi in scaglioni di 100MB. In altre parole finisci per pagare inutilmente soldi che potresti tranquillamente risparmiarti

          Insomma, è una cattiva idea in qualunque modo tu la guardi.

          Gli Svizzeri non sono tutti ricchi - Mattia
          • Avatar
            Scritto da
            Non Autenticato
            il 2017-05-07 19:48:19.0 alle 2017-05-07 19:48:19.0
            Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
            Scritto da: Wakko Warner
            > Scritto da:
            > > Scritto da: Wakko Warner
            > > > Le immagini mettile nel FS. Ti risparmi un SACCO di problemi, presenti e futuri, incluso il problema di cui ti lamenti.
            > > >
            > > > Il database non è fatto per scriverci sopra immagini, allegati, ecc. Memorizza nel FS e nel DB tieni solo un riferimento al nome del file nel FS. Tutti i tuoi problemi spariranno magicamente e quando un giorno dovrai migrare il database vedrai che è molto più facile backuppare e ripristinare un database di 1MB piuttosto che uno di 10GB.
            > >
            > > Quando il software è tuo puoi fare come meglio credi, ma se hai il cliente sistemista di turno che vuole che tutti i dati finiscano nel database, cosicché lui possa backuppare tutti i dati semplicemente backuppando il database, devi fare come lui vuole... e come implementare il software in base alla direttive sono fatti tuoi.
            > >
            > > Il tuo suggerimento è buono e magari alla fine farò come dici tu, però intanto voglio studiare la soluzione al problema così quando si presenterà il sistemista cocciuto saprò come fare.
            >
            > Nessun sistemista con un po' di buon senso ti dirà che devi registrare i dati nel database

            Si vede che quello con cui ho avuto a che fare io era un incompetente (sicuramente è un coglione come essere umano).
      • Avatar
        Scritto da
        Non Autenticato
        il 2017-05-07 21:57:07.0 alle 2017-05-07 21:57:07.0
        Re: Programmazione: quando in memoria devi gestire dati di grosse dimensioni
        Scritto da: Wakko Warner
        > Scritto da:
        > > Io di solito le immagini che vengono caricate dagli utenti di un sito le conservo nel database
        >
        > $facepalm
        >
        > > (nel filesystem solo le immagini del sito in sé), poi quando devono essere renderizzate in una pagina le estraggo dal database e converto i dati binari in dati base 64 poi possono essere usate in HTML per renderizzare le immagini.
        >
        > Le immagini mettile nel FS. Ti risparmi un SACCO di problemi, presenti e futuri, incluso il problema di cui ti lamenti.
        >
        > Il database non è fatto per scriverci sopra immagini, allegati, ecc. Memorizza nel FS e nel DB tieni solo un riferimento al nome del file nel FS. Tutti i tuoi problemi spariranno magicamente e quando un giorno dovrai migrare il database vedrai che è molto più facile backuppare e ripristinare un database di 1MB piuttosto che uno di 10GB.

        E mettere le immagini su imgur?
<softv>

Pagina generata in 116 millisecondi

Utenti attivi: 10 nell'ultimo minuto, 21 negli ultimi cinque minuti, 65 negli ultimi 15 minuti