PDA

Visualizza la versione completa : Creazione "driver" di comunicazione con database sql server


Alethesnake
05-01-2009, 10:32
Ciao,
Mi trovo a dover affrontare un problema di comunicazione tra un'applicazione su server unix (aix) e un database sql server 2005.
Il mio problema è che devo eseguire dei caricamenti massivi, per i quali l'ideale sarebbe poter usare la bulk load. Ovviamente l'utility non può essere sfruttata da server unix, e anzi l'unica possibilità di collegamento è via odbc.

Le performance per me sono cruciali, e l'odbc è lungi dal soddisfare le mie esigenze. Da qui l'idea di studiare un modo di comunicazione alternativo.
L'idea è quella di connettermi al server sql sulla porta dedicata (1433) via tcp/ip, trasferire i dati nel modo più veloce possibile (la rete di cui disponiamo è molto veloce) e poi organizzare su sql server una procedura che mi permetta di effettuare il caricamento.
Detta così sembra semplice.
I consigli che vi chiedo, innanzitutto, sono:

1) Secondo voi posso connettermi direttamente sulla porta di default o devo creare un nuovo servizio (magari con clr) che resti in ascolto su una porta differente? (ovviamente non mi connetterei con una connectionstring classica, ma direttamente via tcp/ip)
2) premesso che i dati da trasferire saranno anche milioni di record, e la sorgente potrebbe essere un flat file o similare, per effettuare effettivamente il trasferimento pensavo di creare dinamicamente una struttura/classe (con c++ probabilmente, variabile a seconda della tabella da caricare) che ricalchi il singolo record, caricare, compattare e spedire via tcp/ip record per record.
Ha senso secondo voi?

Avete suggerimenti in merito (anche strade differenti)?

Cio' che mi preme è evitare trasferimento fisico del file sul server sql per poi eseguire un bulk load la. L'idea è di non scrivere nulla sul server se non sulle tabelle target (o su tabelle di appoggio), e tutti gli inserimenti dovranno essere pilotati direttamente dal server unix (salvo come premesso l'installazione di un "gestore" sul server sql.

Ogni idea/parere è bene accetto.

Ciao e grazie,

Ale.

oregon
05-01-2009, 12:24
La strada che potresti seguire e' quella del servizio che ascolta su una porta e che scrive su db.

Magari, per sfruttare le risorse del server, puoi utilizzare piu' porte e/o il multithreading.

Non mi sembra il caso di collegarti alla porta di sql server in quanto dovresti gestire il protocollo specifico e non e' una cosa banale.

Alethesnake
05-01-2009, 16:46
Interessante il suggerimento relativo al multithreading, sul momento non ci avevo pensato, grazie.
Mi resta un cruccio prima di poter cominciare a fare qualche prova. Come effettuare il trasferimento dei dati? Io disporrò di uno stream che legge da file ipoteticamente. Per trasferirlo devo salvarlo in una struttura e compattarlo (o viceversa)? E hai suggerimenti sul come compattare i dati? (in questo caso il linguaggio sarà molto probabilmente C++).

Grazie ancora, ciao.

oregon
05-01-2009, 17:06
Puoi serializzare/deserializzare il tutto in uno streaming XML ... sicuramente puoi trovare maggiori informazioni (pratiche) su google ...

Alethesnake
05-01-2009, 18:28
Intanto ancora grazie.
Avevo pensato anch'io allo streaming xml, ma poi visto che il bulk load di sql server ha tra le sue alternative il caricamento di un dat (che se non erro è una sequenza di strutture/classi serializzate su file) mi è venuto il sospetto che potesse esserci qualcosa di più veloce rispetto ad uno stream xml.
(sto parlando solo in linea teorica perché non ho ancora pensato bene a come caricare velocemente lo stream in ingresso nel db dall'altra parte). Hai suggerimenti (tu o chiunque voglia partecipare, oc) su quale possa essere un metodo valido per l'import dello stream in arrivo in sql server?

Loading