Query lato server mysql

di il
9 risposte

Query lato server mysql

Salve a tutti. Un consiglio. Ho un gestionale che ha sempre funzionato front-end e back-end su un pc e funziona con le sue query discretamente bene. Decido di mettere il back-end su un cloud aruba con mysql.. una tragedia... lentissimo e alcune volte si blocca. Perché? È possibile eseguire le query lato server? Se fosse possibile avete degli articoli o tutorial da consigliarmi? Grazie sempre

9 Risposte

  • Re: Query lato server mysql

    Le query sono sempre eseguite lato server
  • Re: Query lato server mysql

    Hmm la lentezza potrebbe dipendere da diversi fattori.
    Vedo che scrivi nella sezione Access.
    Stai parlando di un gestionale Access in locale con database remoto in hosting?
  • Re: Query lato server mysql

    Provo a riformulare, essendo una domanda già posta.
    Hai essenzialmente tre problemi: uno di sicurezza (necessaria una VPN, un tunnel SSH, un TLS). Facciamo finta che non ci interessi.
    Il secondo è che stai usando "qualcosa" (Access) che è COMPLETAMENTE inadatto per l'uso con mysql. Grosso modo come mettere un motore BMW dentrl una Mercedes. Per quanto buoni, singolarmente, non sono pensati per funzionare insieme.
    Il terzo è un corollario del secondo.

    Devi considerare che una connessione WAN ha una banda in ricezione e trasmissione minuscola (oggi un pochino meglio con la c.d. fibra). Con una latenza elevata.

    Ciò significa che quello che può "funzionare" in locale, cioè con una connessione LAN, che ha latenza minuscola, e banda molto elevata, NON funziona su WAN.
    Anche un banale "select * from clienti", supponendo di avere una tabella con qualche migliaio di righe un centinaio di colonne, viene eseguita, in LAN, in pochi millisecondi.
    Su WAN può richiederne una ventina, solo per trasferire i dati dal server al tuo PC.
    ---
    Nel "mondo normale", cioè quando si sa come fare questo genere di programmi, si adottano accorgimenti che sono del tipo "trasferisci la quantità MINIMA di dati", e quindi non avrai MAI select senza WHERE, select solo col numero minimo di campi eccetera.
    NON collegherai, per dire, due tabelle attraverso un qualche campo JOIN (da programma), bensì lo gestirai proprio A MANO: quando il record nella tabella master cambia, fai UNA select sulla tabella slave con una selezione su un campo chiave.
    Insomma... ci vuole una decina di anni di esperienza, per far funzionare BENE qualcosa del genere
    ---
    Nel mondo Access, inoltre, NON HAI il controllo su cosa fa quest'ultimo. I wizard, i collegamenti eccetera, sono tutti BELLI quando operi in LAN (con banda poniamo gigabit e latenza <<millisecondo), ma NON quando operi in WAN.
    Non puoi dire "caro Access, non fare NIENTE con le tabelle, lo faccio io da codice, al minimo indispensabile, per avere le prestazioni migliori possibili"
    ---
    Poi c'è il discorso del database stesso, deve essere ben progettato, e magari profilato.
    Anche qui, generalmente, quando affitti una macchina economica ti danno una istanza virtuale condivisa con altri 100 utenti sullo stesso server.
    Normalmente avrai poca RAM, e uno storage condiviso con tantissimi altri.
    Non è che quindi ti possa attendere chissà quali prestazioni entusiasmanti.
    Quindi ottimizzare al massimo il db (altra decina di anni) è indispensabile.
    OPPURE affitti una macchina dedicata, e lì anche lasciando i parametri di default avrai alte prestazioni (perchè l'hardware è oggi così potente che per usi hobbystici tipo questo va sempre bene).
    ---
    Qualora invece il db sia grande (*grande si intende quando gli indici sono più grandi della RAM fisica) si entra in un mondo diverso, in cui lascio stare il pippone (altri 10 anni)
    ---
    Riassumendo:
    - usi una connessione ODBC che aggiunge un overhead notevole a quella che è la caratteristica migliore di mysql (connessioni-thread utenti leggerissimi)
    - usi una connessione WAN ontologicamente lentissima rispetto alla LAN
    - usi uno strumento (Access) che è tutto TRANNE che pensato per funzionare con mysql, e ancor meno in WAN
    - utilizzi un server remoto ritengo di fascia bassa
    - non hai idea di come si sviluppi un'applicazione di questo genere
    - (per i blocchi) può dipendere sia dal timeout (ti serve un timer che "pinghi" il server mysql per tenere la connessione attiva), sia da un timeout nel trasferimento dei dati (cioè impiega così tanto tempo che "si stufa" mentre reperisci i dati)
    Il risultato penso che tu lo possa vedere in concreto.

    EDIT: non è che voglia in qualche misura scoraggiarti, ma è come supporre di poter trapiantare i polmoni (... al mitico Niki) dopo un paio di mesi di "pistolamento".
    Certo è possibile, ma il livello di conoscenze ed esperienza richiesti è paragonabile a quelle di un chirurgo.
  • Re: Query lato server mysql

    vincoll ha scritto:


    Salve a tutti. Un consiglio. Ho un gestionale che ha sempre funzionato front-end e back-end su un pc e funziona con le sue query discretamente bene. Decido di mettere il back-end su un cloud aruba con mysql.. una tragedia... lentissimo e alcune volte si blocca. Perché? È possibile eseguire le query lato server? Se fosse possibile avete degli articoli o tutorial da consigliarmi? Grazie sempre
    La risposta che le Query vengono eseguite lato SERVER è sicuramente corretta, ma parzialmente tendenziosa per chi lavora con Client(Access) e Server(RDBMS).

    Il senso è che è ovvio siano eseguite ServerSide... ma il problema è COME...?
    Purtroppo di mezzo c'è un pezzo aggiuntivo... il motore di JET che se non si fa attenzione si intromette pesantemente.

    Spesso capita di vedere che chi lavora con Access ha poca competenza del problema della Risoluzione delle chiamate SQL dal Client, ed Access che è uno strumento pericoloso per chi non ha competenze specifice, consente di costruire ClientSide(in quanto ha anche un motore proprio) delle Query che, nonostante si stia lavorando con Linked Table ad un RDBMS, ovviamente non possono essere risolte dal Server, ma il Driver le corregge in quel caso e le rende risolvibili con un difetto... GRAVE.
    Ovviamente ciò non accade usando delle Query PassTrought, ma come sappiamo sono ReadOnly per la questione dei Cursori.

    Ne consegue che quando con un Client Access costruiami delle Query Locali si può verificare questo:
    Esempio di una Query TIPICA
    
    SELECT * FROM NomeTabella WHERE Id=Forms!NomeForm!ControlloID
    Questa Query è risolvibile in Access dal motore JET in quanto la risoluzione del riferimento del criterio avviene regolarmente, JET sa cosa sia e come tradurre [Forms!NomeForm!ControllOID].

    Un RDBMS di quella roba li nemmeno sa cosa sia... quindi al SERVER viene risparmiata la fatica, e quì si intromette il Driver di JET, che condiziona la chiamata SQL in quanto al Server arriva in elaborazione quello che può capire, in sostanza viene rimosso il CRITERIO:
    
    SELECT * FROM NomeTabella
    Ne consegue che viene sparata al Client tutta la Tabella, ma poi viene un ulteriore problema che è conseguenza del precedente, questo Recordset viene rielaborato CLIENTSIDE dal JET, che prima ha rimosso il CRITERIO, ma ora lo rimette, quindi applica la risoluzione Implicita del CRITERIO e filtra i dati con la WHERE CONDITION.
    WHERE Id=Forms!NomeForm!ControlloID
    RISULTATO....?
    Una Ferrari che viene fatta andare in PRIMA meno di una 500...

    Quindi se si costruiscono predicati risolvibili il driver li passa e lavorano pienamente SererSide, altrimenti... CICCIA.
    La stessa query di cui sopra se gestita in modo Parametrico, sarebbe stata passata al SERVER ed anche risolta dallo stesso restituendo solo 1 Record.

    Fatta un po di confusione... ma il concetto è questo.
  • Re: Query lato server mysql

    @Alex ha scritto:


    ...La stessa query di cui sopra se gestita in modo Parametrico, sarebbe stata passata al SERVER ed anche risolta dallo stesso restituendo solo 1 Record.

    Fatta un po di confusione... ma il concetto è questo.
    Per la verità mi sembra chiaro.
    Aggiungo: "nel mondo reale, in questi casi, si attiva un log di tutte le query ricevute dal server. cosa che non è banale (per mysql), più facile per mariadb".
    In quel caso, magari con l'opportuno strumentello di elaborazione statistica ex-percona, si vedono subito le query che impiegano troppo tempo, e su cui si va ad operare.
    Tra l'altro si vede anche il tempo di elaborazione dei dati, e di TRASFERIMENTO dei risultati.

    Però le ritengo tutte cose ben al di là dell'utilizzatore Access
  • Re: Query lato server mysql

    Ragazzi grazie a tutti. Siete stati tutti assolutamente preziosi. Ho capito che per la mia preparazione oltre non posso andare La verità è che tutto è cominciato con il semplice scopo di costruire uno strumento semplice con pochi dati che inizialmente ha funzionato per poi pretendere sempre di più... Ad oggi mi rendo conto che certe cose non le posso fare (grazie a voi) e che le mie conoscenze non potrebbero risolvere. Mi fermo qui e lascio tutto in locale...
    Se possibile una curiosità che non capisco. Quando ho trasferitole tabelle in mysql, ho una maschera con un semplice elenco fatto di 10 record. Quello che succede è che in locale riesco a mettere la maschera in modalità modifica dati e mi appare la riga vuota di inserimento, mentre quando leggo i dati nella tabella trasferita in hosting non mi appare? Che potrebbe essere successo?
  • Re: Query lato server mysql

    +m2+ ha scritto:


    @Alex ha scritto:


    ...La stessa query di cui sopra se gestita in modo Parametrico, sarebbe stata passata al SERVER ed anche risolta dallo stesso restituendo solo 1 Record.

    Fatta un po di confusione... ma il concetto è questo.
    Per la verità mi sembra chiaro.
    Aggiungo: "nel mondo reale, in questi casi, si attiva un log di tutte le query ricevute dal server. cosa che non è banale (per mysql), più facile per mariadb".
    In quel caso, magari con l'opportuno strumentello di elaborazione statistica ex-percona, si vedono subito le query che impiegano troppo tempo, e su cui si va ad operare.
    Tra l'altro si vede anche il tempo di elaborazione dei dati, e di TRASFERIMENTO dei risultati.

    Però le ritengo tutte cose ben al di là dell'utilizzatore Access
    Dipende, Access ha un bacino di utenze non proprio così basso come si crede(non voglio aprire a questioni di carattere personale)... ma nella media concordo perchè purtroppo è uno strumento usato da molti "incompetenti".
  • Re: Query lato server mysql

    Intendevo : nessuno con le competenze per fare un buon profiling di mysql (buono è la parola chiave) sarebbe così sconsiderato fa usare access in questo modo.
    Perché ontologicamente non sarebbe un principiante
  • Re: Query lato server mysql

    vincoll ha scritto:


    Ragazzi grazie a tutti. Siete stati tutti assolutamente preziosi. Ho capito che per la mia preparazione oltre non posso andare La verità è che tutto è cominciato con il semplice scopo di costruire uno strumento semplice con pochi dati che inizialmente ha funzionato per poi pretendere sempre di più... Ad oggi mi rendo conto che certe cose non le posso fare (grazie a voi) e che le mie conoscenze non potrebbero risolvere. Mi fermo qui e lascio tutto in locale...
    Se possibile una curiosità che non capisco. Quando ho trasferitole tabelle in mysql, ho una maschera con un semplice elenco fatto di 10 record. Quello che succede è che in locale riesco a mettere la maschera in modalità modifica dati e mi appare la riga vuota di inserimento, mentre quando leggo i dati nella tabella trasferita in hosting non mi appare? Che potrebbe essere successo?
    Le chiavi primarie sono sparite, ed hai perso l'editabilità.
    Se fosse un Counter come è stato re-interpretato da MySQL...?
    Se è un TimeStamp peggio ancora... la gestione degli Orari è abbastanza rognosa.
Devi accedere o registrarti per scrivere nel forum
9 risposte