Approccio disconnesso

di
surapazzo
il
29 risposte

29 Risposte - Pagina 2

  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Tra l'altro mi sono un attimo documentato sul problema dei generali bizantini e però faccio fatica a capire l'applicazione sul sistema a timestamp.
    Puoi mica spiegarmela al volo?
    Grazie
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    Al volo proprio proprio no, c'è sempre il corso di programmazione concorrente e distribuita da fare.
    Il problema riguarda al tentativo di sincronizzare più client tra di loro separati su "qualcosa".
    Il "qualcosa" (esempio il clock) non può essere in realtà sincronizzato in modo esatto (e qui cuttone su una raffica di teoremi, esempi e roba varia che dò per scontata per gli informatici).

    Non puoi, semplicemente, avere DUE cliente col MEDESIMO clock (e quindi il medesimo timestamp).
    Non si può fare, punto e basta.
    Questo è un fatto (perchè? te lo lascio per esercizio)

    C'è poi la versione più rilassata, ovvero ottenere ordinamenti parziali, o addirittura totali con token monotoni crescenti.
    Di nuovo tutta roba di base per informatici.

    Un po' come il teorema di pitagora: si sa benissimo che nella geometria piana funziona, non ci sono "se", "ma", "trucchetti" o quello che vuoi.

    Poi bisognerebbe sapere bene cosa si vuol fare, come, cosa sia il locking, distribuito, e in particolare avere idee ben precise sui risultati.

    Insomma, bisogna essere informatici nell'accezione effettiva del termine.


    POI se invece metti dei caveat, dei LIMITI, allora TUTTO cambia.
    Se supponi, per esempio, che tutti i client, tranne uno, possono unicamente LEGGERE i dati (sto esemplificando, ma così capisci facilmente) ALLORA funziona perfettamente tutto l'ambaradam.

    Quindi è l'OBIETTIVO che devi aver chiaro, in considerazione di quello che si sa GIA' poter essere, o non essere, fatto.

    Se l'obiettivo è un metodo generale di database distribuito => non si può fare (e giù il pippone, anche sul teorema CAP e così via)
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    Ecco qua la "base di tutto", il teorema di Lamport (che ha quasi 40 anni, quindi non è che proprio proprio sto introducendo delle novità)
    http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Intanto grazie, si avevo fatto parte di questo argomento nel corso di algoritmi distribuiti ma non avevo mai visto l'esempio dei generali bizantini.
    Sicuramente tutta questa parte è veramente interessante però a questo punto mi sorge una domanda...
    Ma allora che condizioni vengono messe sui database che sfruttano la concorrenza ottimistica?
    Perchè anche cercando in questi giorni ho effettivamente trovato implementazioni in c# di concorrenza di questo genere però mi chiedo quali siano le clausole che fanno funzionare tutto il sistema.
    Perchè parlando di teoria pura un sistema del genere non dovrebbe essere considerato sicuro, mentre se si parla di mondo con database disconnesso l'unica via è l'ottimismo.

    Sarebbe interessante capire come possono convivere queste due cose, tu hai nozioni a riguardo?
    Grazie mille, sta diventando una discussione sempre più interessante.
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    Diciamo che "qualche" nozione ce l'ho.
    Non so a quali architetture ti riferisci, quindi è difficile dare valutazioni.
    In supersintesi
    - non è possibile sincronizzare esattamente due clock fisici lontani, addirittura per motivi di limitazioni della relatività ristretta. Puoi avere solo una sincronizzazione con un certo errore, che può o può non essere adatto
    - si abbandona il clock fisico per i clock logici, per i quali esistono vari approcci, con ordinamenti parziali (alla Lamport) o totali (col token). Per inciso trovi il sito di Lamport ospitato da microsoft, con un sacco di paper molto interessanti in merito
    - la questione poi si complica nel caso internet, dove i messaggi possono andar persi o essere corrotti (=>generali bizantini) ed avere una latenza tale per cui il messaggio m1 spedito prima di m2 può giungere a destinazione dopo m2, o non giungere affatto, o giungere corrotto
    - c'è poi il problema della coerenza logica, cioè cosa succede nel caso di modifiche allo stesso dato da parte di due client disconnessi. Non basta dire "l'ultimo che opera vince" [supponendo di avere un clock "buono"], perchè le decisioni dei client possono essere propagate altrove.
    Cioè il client1 può ritenere che lo sconto del cliente X sia il 10%, ed emettere una fattura con quello sconto. Poi il client2 cambia lo sconto al 20%, ma la fattura riporta il 10% (questa è la versione banale)

    In certi casi può essere accettabile, in altri no (immagina di prenotare un biglietto aereo e ti applicano uno sconto diverso da quello che ti aspettavi)

    Come vedi quindi distribuito & disconnesso non è per nulla banale, in generale si rilassano i vincoli [come già accennato], o si inseriscono caveat che forzano la coerenza (nell'esempio sopra: solo il client2 può fare le fatture, tutti gli altri no e così via).

    A questo punto ci sono una quarantina d'anni di studi su come affrontare questo problema, con teoremi e controteoremi, approcci con o senza relazioni etc.etc.

    Compendiando: non puoi avere la botte piena e la moglie ubriaca. Dopo aver stabilito cosa è importante, e cosa no, si parte con caterve di studi su quale sia il modo migliore per risolvere un problema non banale, per nulla.

    Troverai il 99% della "roba" internet scritta da bimbiminkia o simili, che non hanno la minima idea dell'argomento.

    O ti rifai direttamente ai paper originali, oppure cerchi su qualche sito universitario dove troverai tante belle slide e PDF fatte più o meno bene (spesso fatte male) così da farti un'idea.
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Grazie, il mio problema è questo io ho un sistema Erp che deve passare da una architettura SqlServer connessa ad una architettura di tipo disconnessa.
    In questo momento vi è una webapp che gestisce le entrate e i lock da usare, in pratica fa da filtro in un imbuto di richieste controllando da se la concorrenza.
    Il mio problema è il passaggio al disconnesso, e quindi non so come gestire i vincoli al meglio per evitare per citare il tuo esempio di applicare due sconti diversi a clienti arrivati in orario uguale.
    Quindi l'unione delle discussioni è sicuramente in un sistema complesso come ERP che condizioni metto per evitare di fare casini con i timestamp.
    Soprattutto come si può gestire il problema dei generali se su una stessa risorsa( timestamp) deve essere cambiata di frequente?
    Questa è una domanda secondo me molto interessante perchè bisogna cambiare la webapp in modo da implementare una concorrenza di tipo ottimistico, ma con quali vincoli?
    La situazione e questa secondo te esiste un modo per ridurre al meno possibile il problema posto da Lamport?
    Grazie
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    surapazzo ha scritto:

    Grazie, il mio problema è questo io ho un sistema Erp che deve passare da una architettura SqlServer connessa ad una architettura di tipo disconnessa.
    In questo momento vi è una webapp che gestisce le entrate e i lock da usare, in pratica fa da filtro in un imbuto di richieste controllando da se la concorrenza.
    ...
    Semplicemente non funziona.

    Per quanto riguarda la webapp, ti segnalo che è la scoperta dell'acqua fredda, nel senso che l'utilizzo di un generatore di token (chiami timestamp, non cambia nulla) univoci rende disponibile un ordinamento totale (neppure parziale) degli eventi.

    MA questo presume che il servizio sia raggiungibile, cioè che la connessione internet CI SIA. Ma se c'è...

    Riguardo ai vincoli puoi fare come vuoi. Ad esempio che i client quando sono disconnessi possono solo leggere i dati.
    E che quando invece vogliono scrivere, cioè creare dei documenti, essi NON vanno a finire nel database, ma in una qualche sorta di archivio locale (testo, XML, json, bson o sticazzi) i quali, quando la connessione è disponibile, vengono caricati nel server, dove esiste un programma vero e proprio che piglia in carico i documenti e LUI (il programma) decide se e come inserire i dati.
    Essendo un singolo agente non c'è problema di concorrenza (fa da solo); inoltre può gestire collisioni logiche (es. denormalizzazioni non volute etc).
    Si tratta del concetto di "spazzino" normalmente usato in questi casi.
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Si mi sembra lo'unica visto i discorsi fatti in precedenza, in pratica astraiamo il problema per far si che ci sia un ente filtro che non gestisce gli accessi concorrenti ma semplicemente gestisce da se l'ordine di tutte le richieste prese in carico.
    Se volessi usare un clock, vado a memoria dei corsi di distrbuito, mi converrebe usare un versioning clock tu che dici?
    Come algoritmo di base anche qui a memoria, l' ideale potrebbe essere usure un Ricart-Agrawala con token che in questo caso il mio token è prorpio il clock?
    Ci sto pensando mentre mi rispondi quindi magari una tua opinione aiuta sicuramente, e nel mentre cerco il vecchio materiale di algoritmi distribuiti =)
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    Se il programma non nasce già di suo pensato (e molto ben realizzato) mi sembra francamente un delirio ipotizzare una cosa del genere, a fortissimo rischio di disastri e perdita di dati di ogni genere.
    Francamente ti sconsiglio approcci "naive" del genere.
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Eh si mi sembra un macchinosa la cosa, la mia domanda seguente è che altre aziende come quella che sto analizzando avranno dovuto gestirsi questo problema cioè di passare da architettura connessa a disconnessa ma non trovo soluzioni online di esempi che dicono a grandi linee che best practices ci sono per traghettare una struttura aziendale verso questa soluzione.
    Tu hai mica materiale link da consigliarmi che mi sembri molto e sottolineo molto preparato su tutto il nostro ambiente?
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Tra l'altro ho visto che una soluzione esiste per chi sta affrontando questo passaggio in ambiente Microsoft, si chiama SmartClient qualcuno mi sa dire di più?
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    Semplice: non sono passate.
    O al massimo sono passate a versioni "casarecce" (sincronizzazioni parziali), oppure su situazioni sempre connesse (Citrix ad esempio), o sempre connesse (portali PHP)..
    Per il resto se ti riferisci a Smart-Che ti segnalo che è "roba" di un 15 anni fa.
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Mi riferivo a questo prodotto Microsoft "Smart Client Architecture and Design Guide" che mi sembrava dal PP che ho scaricato di aver capito che servisse proprio per la parte disconnessa.
    Quindi in pratica se fossi obbligato a passare al disconnesso devo arrangiarmi con un di questi metodi che mi hai suggerito.
    Una cosa che non capisco e che vantaggi effettivi porti la versione disconnessa, penso che a livello prestazionale su un numero molto grande di tuple aiuterà molto ma altri vantaggi?
    E Ado.Net non ha una parte di gestione sul disconnesso?
    Grazie
  • +m+
    +m+
    Molto attivo
    Iscritto da
    gen, 2016
    Messaggi:
    712

    Re: Approccio disconnesso

    Nessun vantaggio di prestazioni, anzi al contrario.

    Serve solo nel caso in cui non hai una connessione internet attiva, ad esempio perchè sei in mezzo al mare e le trasmissioni satellitari costano troppo.
    Andava di moda fino a pochi anni fa, quando le chiavette internet erano poco diffuse e comunque costose.

    Per Smart-che, se leggi bene, vedrai che è una caterva di ...sciocchezze... con tanto di riconciliazioni ed elenchi che il client dovrebbe in teoria approvare.
  • S
    surapazzo
    Pochi posts
    Iscritto da
    nov, 2012
    Messaggi:
    42

    Re: Approccio disconnesso

    Ottimo, perfetto almeno ho una panoramica completa dell' argomento... volevo chiederti ma con Ado.NET non si riesce in parte ad implementare questo problema?
    Perchè ho letto che riesci a programmare una webapp che ti faccia il lavoro di cui parliamo, la consideri sempre una via " casereccia" per cercare qualcosa che non conviene fare?
Devi accedere o registrarti per scrivere nel forum
29 risposte