Italian community of Lazarus and Free Pascal
Programmazione => Databases => Topic aperto da: DragoRosso - Febbraio 02, 2022, 10:57:31 pm
-
Ciao a tutti.
Stò approcciando a una nuova tipologia di attività, una cui parte preponderante è la raccolta dati.
In pratica ho degli strumenti remoti, per adesso interfacciati per forza con dei PC Windows poi un domani si vedrà, che devono condividere dei dati. A questi dati poi potranno accedere dei terzi, in maniera però selezionata, ossia per gruppi. Un terzo in pratica potrà accedere ai dati di un gruppo di dispositivi remoti, ma non ad altri. Ovviamente questi gruppi potranno cambiare composizione, operazione gestita da un amministratore.
La connessione non è certa e costante, per cui è certo che i vari dispositivi remoti (o meglio i pc a cui i dispositivi sono collegati) dovranno trasmettere i dati presso un collettore centrale, quando possibile.
La domanda è: il collettore centrale può essere un aggregatore qualsiasi, ma in grado ovviamente di isolare i gruppi di dati e di renderli disponibili secondo la regola suddetta, qual'è la tecnologia migliore da usare secondo voi ?
Io pensavo al cloud (che và tanto di moda adesso), soluzione comunque costosa (anche se qualche servizio gratuito c'è) e sopratutto a me quasi sconosciuta nel suo funzionamento.
In alternativa un bel database remoto tramite server con protocollo REST ad esempio (anche questo però certo non economico a meno che non si faccia "in casa"), oppure ... cos'altro ?
Voi cosa ne pensate ? Sono aperto a suggerimenti.
Grazie intanto, ciao ciao
-
Ciao.
Cosa intendi per "protocollo REST"?
Stilgar
-
Ciao, io per diversi anni ho usato un server ftp al quale inviavo dei file di testo. Nel mio caso i dati provenivano da cellulari, poi c'era un pc che attingendo dal server ftp poi riversava in un dbms. Il server ftp prima era in un pc in studio poi presi un virtual server Aruba a 10 € al mese.
Il database remoto lo uso tuttora ma in applicazioni dove c'è interattività.
-
Ciao.
Cosa intendi per "protocollo REST"?
Stilgar
REST o SOAP, è il protocollo basato su HTTP ed è uno standard per la comunicazione dati su rete.
-
REST o SOAP, è il protocollo basato su HTTP che è uno standard per la comunicazione dati su rete.
https://restfulapi.net/soap-vs-rest-apis/ (https://restfulapi.net/soap-vs-rest-apis/)
Per chi non sa di cosa stiamo parlando.
Qui parlano solo dell'http come protocollo, ma in via del tutto teorica si potrebbero usare altri protocolli (STMP ad esempio).
Stilgar
-
Bhè, diciamo che l'argomento non è proprio incentrato sul protocollo. Il mio era uno dei pensieri per dare una visione del tutto. Giustamente @tito_livio ha proposto una soluzione alternativa come ftp.
Diciamo che i punti cardine sono:
1) Da cliente remoto deposito (quindi solo scrittura) dati su un hub centrale (tramite internet).
2) Sull' hub centrale ci dovrà essere una elaborazione dei dati per consentirne una archiviazione organizzata.
3) Da ulteriori clienti remoti accesso (solo lettura) ai dati "ragruppati" sull'hub centrale (tramite internet).
4) Sistema di amministrazione per la gestione dei dati (manutenzione, operazioni di configurazione o altro) (tramite internet).
Per i punti 1) e 3) in questo momento si userebbero dei PC in ambiente Windows, ma solo perchè è più semplice la gestione iniziale e perchè tendenzialmente i clienti hanno sempre e comunque un PC Windows a disposizione.
Tutto ciò che ci stà in mezzo, compresi punti 2) e 4) sono da pensare.
A me, tendenzialmente sono conservatore, una soluzione classica con trasferimento ftp da punto 1) a un server virtuale con vari servizi punto 2), programma in Lazarus di gestione dei file sul punto 2) e 4) e archiviazione dei dati su un db, altro programmino in Lazarus sul punto 3) di interrogazione del db punto 2) (client / server fatti sempre in Lazarus) ..... non dispiacerebbe.
Però la sicurezza è uno di quegli aspetti che in questo caso, facendo tutto "io" mi fà un attimo pensare. Come pro è che ho tutto sotto il mio controllo e il costo è probabilmente il più contenuto.
Usare altre tecnologie come NAS, cloud o altro distoglie "parzialmente" dal pensiero sulla sicurezza ma fà aumentare i costi e il controllo e l'uso è probabilmente più complesso.
Faccio un esempio (non conosco in generale il cloud e le api S3): i dati nel cloud devono arrivare già aggregati e corretti immagino. Quindi si prevede che gli end point 1) e 3) inviino già i dati formattati ed organizzati in un modo X .... e questo toglie diciamo flessibilità alla soluzione ... se dovessi togliere il pc dal punto 1) (che è previste in un futuro prossimo) dubito che approcciando questa soluzione il device nudo e crudo possa adottare le api s3 al suo interno per la comunicazione dei dati sul cloud. E anche se lo fosse, ho già visto che i soli aggiornamenti del core del device provocano sconvolgimenti che non dovrebbero esserci ... và bhè ma questa è un'altra storia....
Ciao
-
Ahhh, dimenticavo: per ultimo, ma non ultimo come peso, con la soluzione classica avrei una gestione completa anche sugli accessi e sugli allert come tentativi e frequenza accessi con una logica personalizzata che nessuna delle soluzioni standard come NAS e cloud possono facilmente offrire.
Ciao
-
Anche io sono del tipo "classico" come ha amato definirti.
Ma non mi azzardo a darti suggerimenti tecnologici. ;)
Altrimenti al primo inghippo inizio a sentire le imprecazioni interregionali. ;D
Stilgar
-
Anche io sono del tipo "classico" come ha amato definirti.
Ma non mi azzardo a darti suggerimenti tecnologici. ;)
Altrimenti al primo inghippo inizio a sentire le imprecazioni interregionali. ;D
Stilgar
Ma daiiiii, i suggerimenti aiutano a crescere. Fai muovere quei pochi neuroni che ti sono rimasti ( :P ;D ) e sputa il rospo.
Prometto che non me la prenderò con te.
Anche perchè la scelta finale sarà comunque mia, indipendentemente da suggerimenti, consigli o altro.
Quindi mia anche la responsabilità della adozione della soluzione o del mix di soluzioni.
Ciao
-
Dipende dagli scenari.
FTP è ottimo se non devi sapere in "tempo reale" lo stato dei dati importati.
Tutto in differita. Asincrono. Ottimo per batch con grandi quantità di dati. Poi dovrai pensare a qualche procedura di gestione degli scarti.
Se devi sapere lo stato di import dei dati, meglio struttura OLAP. Un servizio esposto direttamente in rete, protocollo di trasmissione http su TLS. Spari il dato e sai se è stato accettato. Eventualmente poi inviare nuovamente il dato in caso di errore.
Per la parte di sicurezza, esistono diversi tipi di soluzione.
Quella che prediligo:
1) Client Autenticazione| JWT di risposta se passa l'autenticazione
2) Ad ogni chiamata deve essere fornito il JWT.
In questo modo non usi sessioni (evitando gli attacchi alle sessioni) o altri ammennicoli strani. Il JWT deve essere cifrato.
Il server verifica ad ogni chiamata il contenuto del JWT. In modalità "paranoica" il JWT può cambiare ad ogni richiesta del client. Lo generi ad ogni risposta.
Rest di suo è ottimo (alla fine sono una serie di convenzioni, nulla vieta che i metodi http che usi siano customizzati - son soddisfazioni inventarsi i metodi di chiamata). Nel payload puoi mettere grosso modo quel che vuoi. In genere vedi json come formato dati (utilissimo con javascript), ma nessuno ti vieta di inviare un file cifrato a sua volta. Magari usi il JWT come chiave di cifratura.
Anche il CBOR è intrigante come formato. Ed è standardizzato. (Dovrei mettermici per fare una lib per pfc, così per divertimento)
Se vuoi altri spunti per incasinarti la vita ;D
Stilgar
-
PS
CBOR https://www.rfc-editor.org/rfc/rfc8949.html (https://www.rfc-editor.org/rfc/rfc8949.html)
JWT https://jwt.io/ (https://jwt.io/) https://jwt.io/libraries
Stilgar
-
Grazie @Stilgar, sapevo di poter contare su di te. Quando sono in cerca di un qualcosa di diverso, di tranquillo, di già sviluppato .... sò di contare su di te ;D ;D ;D (falsoooo).
Provo a darci una occhiata e vediamo, mi stuzzica fare una lib base su CBOR ...
Intanto grazie per gli spunti, poi vi tengo aggiornati.
Ciao ciao
-
Uno dei problemi che ho visto e che mi hanno raccontato sui server remoti è la principale problematica dell'interfaccia di configurazione / uso.
E' vero che i pannelli di controllo sono ormai molto sofisticati, ma è anche vero che la stragrande maggioranza di questi è "puntata" molto al web.
Girando "in giro" mi sono imbattuto in una offerta di Aruba (cloud vps : https://www.cloud.it/vps/configuratore-virtual-private-server.aspx (https://www.cloud.it/vps/configuratore-virtual-private-server.aspx)) che in effetti è forse la migliore (@nomorelogic inorridirrà a ciò che dirò) sia in termini d'uso che di prezzo.
Ovvio che la potenza elaborativa è comunque limitata, ma per quello che devo fare è anche troppa ....
Ci sono 4 tagli (cambiano ram, cpu virtuali, spazio su disco e traffico mensile): € 3,40 / mese; € 8,00 / mese; € 15,25 / mese o € 30,50 / mese.
Ma il bello è che come SO hai Ubuntu 20.04 Server con VIRTUAL DESKTOP ..... in pratica un PC remotato. C'è anche la connessione SSH, ad uso degli amanti della console a riga di comando ....
Se come me non si hanno grosse esigenze per il progetto che stò affontando, ma che necessito di massima flessibilità, direi che la proposta è più che accettabile.
Inoltre puoi scalare in basso o in alto alla bisogna .... ehmmm ... anzi no per il servizio smart :-\
L'offerta è una offerta base (cloud vps smart) e la configurazione che attiverò (già domani probabilmente) è la terza: € 12,50 /mese (l'iva ovviamente la compenso) con 2 cpu virtuali, 4 GB Ram, 80 GB SSD, 12 TERABYTE di traffico mensile con banda teorica di 1 Gbit.
Dopo di che la prima operazione che farò sara installare un serverino fatto in Lazarus .... ;D con interfaccia GRAFICA .... 8)
Poi proseguirò con il resto CBOR ... JWT ... REST ... SOAP ... e chi più ne ha più ne metta.
Ciao
-
scusate la mia assenza ma ho dei giorni complicati
innanzitutto non inorridisco affatto per un VPS, anzi! ;D
in azienda abbiamo già diversi server VPS su aruba + ne abbiamo uno fisico dove ci gestiamo i nostri VPS "fatti in casa"
ora passiamo al problema
S3 è uno storage ma di file, non è un database e quindi non credo che faccia al tuo caso: penso di aver capito che devi gestire dei dati tipo RDBMS
detto questo FreeNAS/TrueNAS, nel caso serva storage di file con interfaccia verso api S3 credo sia la soluzione migliore tecnicamente e meno costosa
lo scenario che descrivi secondo me è affrontabile almeno in un paio di modi
se i dati che devono stare sul "deposito centrale" sono omogenei (= tabelle identiche) con quelli che stanno nei vari "punti di inserimento" (client) allora ti consiglio vivamente di valutare un RDBMS che abbia replicazione interna (MsSql o firebirdSql 4)
la replicazione di database è un mondo particolare ma una volta impostata vai (quasi) senza problemi
capisco che può intimorire, ma è uno strumento straordinario
se vogliamo slegarci da tutto e tutti, non vedo altra soluzione che avere un server da qualche parte dove gira un RDBMS e un server rest per pubblicare le API a fare da interfaccia
il server rest può essere di qualsiasi tipo (vedi suggerimenti Stilgar), se vuoi rimanere con lazarus si può fare sia (1) apache + cgi fpc che (2) apache + modulo apache DLL fatto con fpc che (3) apache + instantfpc che è una figata che (4) server json dedicato scritto sempre con FPC
(se vuoi dritte su una qualsiasi di queste soluzioni... le ho già studiate tutte quante)
altro strumento da valutare ETL
un ETL è uno strumento che può servire per spostare dati dai client al server anche passando per server rest json
per chi è interessato ne sto studiando/realizzando uno fatto in fpc che possa raccogliere (trasformare ovviamente) e distribuire dati in vari formati e canali
attualmente sto studiando un primo "semplice" step: trasferimento dati da foglio di calcolo a tabella su database RDBMS diretto (cross platform ovviamente = no OLE e no Activex)
(ftp, rest json, rdbms vs rdbms sono cose che arriveranno a seconda delle necessità)
quando avrò finito il primo step avrei intenzione di rendere il sorgente open source (ne sto parlando in azienda ma credo che ce la facciamo)
quindi se va liscia... puoi anche valutare il mio ETL :)
-
Intanto primo serverino http ... tre line di codice :
(http://[/url)
EDIT: il link non è più attivo.
Ehm .... da notare il nome del dominio ;D ;D ;D domani lo cambio giusto per dare un tono .....
Ciao
P.S.: @nomorelogic, ma sai che quasi quasi Linux mi incomincia a piacere, almeno per la parte web e richiesta di risorse. Effettivamente 2 virtual core e 4 GB sono anche tanti ..... ;) .... però il piacere si ferma li :P.
-
avevo buone speranze sul progetto SQLDBRestBridge ma non mi pare stia procedendo.
Sono interessato anch'io all'evoluzione del tuo progetto, quella della raccolta e smistamento dati è una situazione molto frequente nel mio mondo.
ciao
-
Diversamente da quando stà facendo @nomorelogic che ha probabilmente dei vincoli e degli obiettivi ben precisi legati specificatamente all'attività che la sua azienda svolge, io stò sviluppando una soluzione che verso il campo sia la più semplice, sicura e praticabile possibile.
Nel "campo" ho degli oggetti che tendo a rendere o molto "stupidi" (quelli di cui ho parlato in questo topic) o superelaborativi (tipo blackbox).
Facendo capo a quelli "stupidi" stò verificando qual'è il modo migliore, tenendo conto dei fattori già indicati, per trasmettere i dati ad un collettore centrale. Di base questo lo faccio già, e con impianti sparsi in giro per il mondo ... e se ci fosse qualcosa che non và .... sarei già morto. Solo che sono sistemi che comunicano con protocolli abbatsanza complessi con database remoti ridondati localmente.
Inoltre stò cercando di capire quale collettore è il più flessibile e abbordabile, tenendo conto sopratutto che si dovrà interfacciare con sensori "stupidi". Parlare di SSL, criptatura asimmetrica, SFTP o quant'altro potrebbe risultare complesso. Idem per quanto riguarda REST.
Questo riguarda però l'invio dei dati dal campo verso il collettore, problema abbastanza relativo visto che i dati dovranno comunque essere poi validati. Anche un trasferimento TCP in formato Encode64 potrebbe andare bene .... anche tenendo conto che non sono dati sensibili (almeno così sono i miei, altrimenti passiamo al capitolo blackbox "superelaborativi").
Quello che secondo mè è più interessante è capire il collettore che tecnologia dovrà usare in toto, a partire dalla sua struttura e presentazione (ad esempio un virtual server, un file server, un object container o un web server).
Da qui poi si parte per la sezione più adattabile, ossia la presentazione dei dati verso i client ... qui la tecnologia può essere usata in abbondanza, tenendo conto che tendenzialmente parliamo di PC (per svariati motivi).
E forse questa è la parte più critica, in quanto abbiamo un accesso ai dati e ciò rappresenta un potenziale problema.
Come dicevo, per adesso mi sono portato nella situazione più generale e flessibile usando un Virtual Server in CLOUD che mi consente di fare tutto, poi in base a ciò che verrà costruito si potrà valutare la migliore soluzione con valutazione anche economica della cosa.
Se postate le vostre esigenze e idee, posso vedere di tenerne conto e di pensare a qualcosa che le ricomprenda e sia il più generico possibile. Parlare di ETL ora .... per questo progetto siamo lontanucci, sia in termini di risorse che in termini di obiettivi (almeno per quel che mi riguarda).
Ciao.
P.S.: ovviamente poi verrà pubblicamente postato il progetto.
-
@schumi
probabilmente, lavoriamo in situazioni simili, io nella fattispecie in ambito gestionale/erp
vi terrò aggiornati anche perché avrei intenzione di realizzare uno strumento abbastanza orizzontale e sono interessato a coprire, nei limiti del possibile, più problematiche possibili
quindi idee e suggerimenti sono graditissime
@DragoRosso
è chiaro che capire la natura del collettore è indispensabile ma tra file server, object container e web server, penso che per prendere la decisione devi pensare al tipo di dato e dopo il tipo di collettore la vedo una conseguenza
un suggerimento che posso dare è che con un web server, in teoria, ci copri tutte le esigenze e se in futuro ti interessa SSL non dovrai far altro che mettere il certificato
fai conto che per comunicare con il web server lo puoi fare anche con curl....
riguardo ETL, forse ho usato un parolone ma quello dovrà essere il risultato finale
quello che bolle in pentola è effettivamente raccolta e smistamento dati
non è che sia poi tanto diverso da quello che ti serve ;)
per quanto riguarda linux che non ti piace più di tanto...
il tempo è galantuomo 8)
-
probabilmente, lavoriamo in situazioni simili, io nella fattispecie in ambito gestionale/erp
gestionale e vari applicativi in ambito retail food