2010-02-18 13 views
5

Ho un'applicazione WCF che attualmente utilizza l'archiviazione di file basata su XML per archiviare i dati che vengono utilizzati per generare report. Oltre a questo processo, le decisioni vengono prese in base alle informazioni memorizzate in questi file XML.Qualche considerazione prima di saltare in SQLite?

Attualmente sto colpendo volumi di circa 30 000 file di testo. Questo è incredibilmente faticoso e l'applicazione a volte si ferma.

Ho sempre desiderato estrapolare il DAL XML in favore di un RDBMS, ma i project manager semplicemente non lo permetteranno. Ma sarebbero disposti a guardare una soluzione serverless ad esempio SQLLite. Sono davvero tentato di immergermi subito e iniziare a usarlo come DAL (Data Access Layer) sostitutivo.

Non avrei bisogno di più di circa 20 tabelle nell'intera soluzione, e mi aspetterei di ottenere non più di circa 20.000 - 100.000 transazioni al giorno, tuttavia questo è estremo, i volumi reali sarebbero inferiori a questo nella maggior parte dei casi.

Aggiornamento

Non mi aspetto una grande quantità di connessioni simultanee, quando dico le transazioni, che in sostanza significa che 1 o 2 clienti che effettuano chiamate e eseguono nel database in ordine. A volte potrebbe esserci la possibilità che i client esterni effettuino chiamate rapide al DB. Ma la maggior parte delle connessioni DB verrà eseguita dal mio servizio WCF, che è un'attività pianificata back-end, che non serve centinaia di persone all'interno di un'organizzazione.

Un altro buon punto è che ho solo bisogno di conservare i dati per 90 giorni, quindi il DB non dovrebbe diventare troppo grande.

mie preoccupazioni principali sono:

Quanto è affidabile SqlLite? Cosa succede se il file DB viene danneggiato, perderò tutti i dati di elaborazione. Quanto è facile eseguire il backup del DB? Gestirà i miei volumi? E infine quanto bene funziona il provider .net (che si trova qui: http://sourceforge.net/projects/sqlite-dotnet2/).

Se hai esperienza con SQLLite, pubblica le tue esperienze in modo che io possa prendere una decisione informata di cambiare o meno.

Grazie in anticipo ...

risposta

1

Dato il volume delle transazioni direi il fatto che il DB stesso è un singolo file monolitico con il file system solo blocco a disposizione potrebbe essere un problema.

Non esiste un blocco basato su righe per quanto ne so.

+0

Lasciatemi riformulare la mia domanda. –

+0

Giusto, sqlite non gestisce più utenti che tentano di accedervi contemporaneamente, ma fintanto che è semplicemente un archivio di dati monolitico utilizzato da un'applicazione alla volta, funziona alla grande. – Karl

+0

@Karl, gestisce l'accesso simultaneo da diversi processi, anche da sistemi diversi, e supporta le transazioni, che è il modo migliore per gestire il blocco. È conforme ACID. Tuttavia, poiché l'intero database è contenuto in un unico file e si blocca a livello di file, i lettori bloccano le scritture in sospeso e il blocco di scrittura fino al termine della lettura. –

3

Si potrebbe considerare Sql Compact Edition di Microsoft.
È come sqlite, in termini di un singolo database incorporato di file, ma ha una migliore integrazione con il framework .net :)
SQLite sembra affidabile, e anche con quello di Microsoft, non aspettatevi di ricevere molto supporto in caso di un database corrotto.

+0

Sqlite funziona alla grande, ma ho sicuramente avuto difficoltà a farlo funzionare bene con l'interfaccia per gli oggetti dati attivi di Visual Studio, quindi finché sei in Windows Land, forse MS Sql Compact è la scelta migliore. – Karl

5

SQLite è affidabile quanto il sistema operativo e l'hardware.

La sua velocità di transazione è simile al server SQL e spesso più veloce perché è tutto in corso.

Il provider .NET ADO funziona alla grande.

Per eseguire il backup del DB, interrompere il servizio e copiare il file. Se il file journal è presente, copialo anche tu.

MODIFICA: SQLite utilizza UTF-8 per impostazione predefinita, quindi con il provider ADO-NET si dovrebbe essere in grado di evitare di perdere accenti (basta che si segua il tipico XML nelle regole delle stringhe).

+0

È anche possibile eseguire il backup del database quando si dispone di una transazione esclusiva senza interrompere il servizio: la transazione esclusiva garantisce che nessun altro tocchi il db. Anche la versione 3.6.11 ha aggiunto un'API live-backup direttamente all'interno del core engine (non so se i wrapper .NET lo espongano ancora, ma se non fosse facile da aggiungere). –

1

Ho usato SQLite con il provider .Net senza problemi in un ambiente monoutente, tranne che per una preoccupazione: gli accenti, che non sono stati mostrati correttamente. Il backup è abbastanza semplice: il database SQLite è un file di testo semplice. Basta copiarlo.

+0

Cosa sono gli accenti? Mai sentito parlare di loro. –

+0

"acentos" in spagnolo, immagino: qualcosa come questo – Apocatastasis

+0

Ok, allora avrò un problema perché la soluzione che sto usando è per i clienti cechi che non usano un set di caratteri in inglese. –

1

Uso Sqlite per la memorizzazione dei dati di configurazione XML e non ho avuto problemi con esso. Utilizzo il provider System.Data.Sqlite: http://sqlite.phxsoftware.com/. È solido e ha un buon forum di supporto. Include anche un provider LINQ. Si integra inoltre con VS 2008 in modo da poter utilizzare Server Explorer per interrogare le tabelle. Gli esempi e la documentazione mostrano anche come utilizzare comandi e transazioni parametrizzati per aumentare le prestazioni.

La versione candidata per LinqPad ora supporta Sqlite: http://www.linqpad.net/Beta.aspx.

Sqlite memorizza tutto in un singolo file, che può essere sottoposto a backup come qualsiasi altro file binario.

Sqlite supporta solo il blocco a livello di file, ma non dovrebbe presentare un problema di prestazioni poiché non sembra che si abbia un numero elevato di transazioni simultanee.

Unicode non dovrebbe essere un problema. Questo collegamento nel forum indirizza un'area in cui qualcuno stava cercando di leggere caratteri unicode con un'utilità incompatibile http://sqlite.phxsoftware.com/forums/t/954.aspx.

Questo sito mostra come eseguire confronti UTF8 case-insenitive utilizzando System.Data.Sqlite tramite un fascicolatore personalizzato, con caratteri russi come esempio: http://www.codeproject.com/KB/database/SQLiteUTF8CIComparison.aspx.

Problemi correlati