Il Entity Framework è appropriato quando tutto ciò che si fa è inserire i record in blocco?

6

Il mio reparto sviluppa software per migrare database per i nostri clienti dal loro vecchio software CRM al nostro. In questo processo potremmo inserire milioni di righe, elaborate una alla volta, poiché dobbiamo eseguire mappature e formattazioni per passare dal loro vecchio sistema (che potrebbe essere qualsiasi cosa, da un database relazionale a un set di file binari) a il nostro database MS-SQL.

Attualmente utilizziamo un modello consumer del produttore che si legge dal vecchio sistema al nostro mapper, quindi usiamo un altro modello produttore / consumatore per passare da questo in thread DataTable locali che vengono visualizzati in sequenza ogni 15.000 righe in un SQLBulkCopy operazione per mantenere basso il numero di oggetti contenuti nella ram (tabelle più grandi possono essere facilmente scaricate il limite di 2 GB per un'applicazione a 32 bit se proviamo a tenere l'intera tabella in memoria prima di inserirla.)

Il problema è che questa è una specie di installazione di kludge per essere in grado di generare le nuove righe e inserirle nel database. Recentemente abbiamo avuto l'opportunità di riscrivere il database per soddisfare le nostre esigenze e ho lavorato al mio manager all'idea di utilizzare qualche forma di ORM.

Ho iniziato a dare un'occhiata a varie soluzioni ORM, e so che vogliamo stare con un puro stack Microsoft (è stato abbastanza difficile convincere il mio manager a considerare l'utilizzo di un ORM, e non ho palle di neve possibilità di convincerlo a utilizzare una libreria di terze parti, poiché l'app CRM principale utilizza una libreria di elaborazione di immagini di terze parti che non è molto buona e da allora ha odiato le librerie di terze parti). Confrontando Linq-to-Sql e ADO.net Entity Framework penso che EF soddisfi meglio le nostre esigenze. Tuttavia sono preoccupato per le prestazioni.

La maggior parte delle app CRUD sono Read- > Aggiorna a velocità ridotta (visualizza solo un record o un set di record con una variabile comune alla volta). Tuttavia ci limiteremo a creare, creare, creare. Un ORM come EF è progettato per farlo?

Il mio manager è ossessionato dalle prestazioni. Quando questo processo è stato eseguito in VB6 (come è stato fatto fino a due anni fa) potrebbero essere necessarie diverse ore per eseguire una conversione. Con il nostro attuale kludge i più lunghi impiegano al massimo mezz'ora per elaborare diversi Gigs of records (la parte più lenta si occupa di quella libreria di immagini di terze parti che ho menzionato prima, quelli che sono testo puro impiegano al massimo 10 minuti). Potrei potenzialmente vedere un rallentamento nell'EF rispetto all'utilizzo di SqlBulkCopy e cosa posso fare per mitigare il costo corrente se lo fa?

    
posta Scott Chamberlain 06.10.2011 - 00:46
fonte

3 risposte

5

Penso di aver trovato il meglio di entrambi i mondi. Sull'archivio MSDN di Microsoft hanno un LINQ Entity Data Reader che mi permetterà di trasformare il mio oggetto EF in un DbDataReader che può essere passati a SqlBulkInsert.

    
risposta data 06.10.2011 - 01:36
fonte
2

Questo è uno scenario in cui un ORM può essere abbastanza controproducente, almeno dal punto di vista delle prestazioni. Soprattutto fuori dagli schemi, e seguendo i tipici schemi di utilizzo, si esibiranno in modo orribile in questo tipo di lavoro. Faresti meglio a usare la copia bulk in SQL o direttamente ADO.NET [no entity framework] qui.

Se decidi di fare questa immersione, dai un'occhiata a questo post del blog per alcuni suggerimenti. Riguarda nHibernate ma lo stesso tipo di cose si applicherebbe al Entity Framework che penserei.

Ora, solo perché stai utilizzando ADO.NET dritto per un percorso ad alte prestazioni nell'app non significa che non puoi utilizzare un ORM in altri luoghi in cui ha senso.

    
risposta data 06.10.2011 - 01:08
fonte
2

Il tuo caso viene in genere risolto da una classe di strumenti di sviluppo delle applicazioni, generalmente denominati ETL (Extract, Transform and Load). In SQL Server, è possibile utilizzare SSIS (vedere questo collegamento ad esempio: Esercitazione SSIS

Esistono strumenti ETL gratuiti come un'edizione speciale di Expressior Studio

La cosa bella degli strumenti come questi è che puoi creare la tua applicazione usando drap-and-drop e non scrivere una singola riga di codice a meno che tu non voglia cambiare i dati o convalidarli.

La maggior parte degli ORM che conosco, non supporta gli aggiornamenti / inserimenti batch. Un'eccezione può essere N-Hibernate (vedi: batch )

Qualsiasi approccio che funzioni su una riga per fila sarà lento. ADO EF non è il problema. Quindi, utilizza Bulk Loader o uno strumento ETL, ma codificare C # / ADO non è il modo migliore di farlo in modo specifico se disponi di un numero elevato di origini dati.

    
risposta data 06.10.2011 - 01:44
fonte

Leggi altre domande sui tag