tags:

views:

192

answers:

5

I have a WCF application that at present is using XML based file storage to store data that gets used to generate reports. Besides this processing decisions are made based on information stored in these XML files.

I'm now hitting volumes of around 30 000 text files. This is incredibly taxing, and the application at times comes to a grinding halt.

I've always wanted to swop out the XML DAL in favor of an RDBMS, but project managers simply won't allow it. But they would be willing to look at a serverless solution for example SQLLite. I am really tempted to just dive right in and start using it as a replacement DAL (Data Access Layer).

I would need no more than around 20 tables in the whole solution, and I would expect to get no more than around 20 000 - 100 000 transactions a day, however this is extreme, the real volumes would be less than this in most cases.

Update

I am not expecting a great deal of simultaneous connections, when I say transactions, I essentially mean 1 or 2 clients that make calls and execute against the database in order. At times there might be a possibility of external clients making quick calls to the DB. But the bulk of DB connections will be done by my WCF service, which is a back end scheduled task, not serving 100's of people across an organization.

Another good point is that I only need to retain data for 90 days, so the DB shouldn't grow too big.

My main concerns are:

How reliable is SQLLite? What if the DB File gets corrupted, will I loose all processing Data. How easy is the DB to back up? Will it handle my volumes? And lastly how well does the .net provider work (located here: http://sourceforge.net/projects/sqlite-dotnet2/).

If you have any experience with SQLLite, please post your experiences so I can make aan informed decision to switch or not.

Thanks in advance...

+1  A: 

Given your transaction volume I'd say the fact that the DB itself is a single monolithic file with only file system locking available could be a problem.

There is no row based locking as far as I know.

Rob Wells
Let me rephrase my question.
JL
Right, sqlite doesn't handle multiple users trying to access it simultaneously, but so long as it is simply a monolithic data store used by one application at a time, it works great.
Karl
@Karl, it handles simultaneous access by different processes, even from different systems, and it supports transactions, which is the best way to manage locking. It is ACID compliant. However, since the entire database is contained in one file and it locks at the file level, readers block on pending writes and writes block until reads finish.
ebpower
Accepted answer, because this is ideally a WCF service application in iis, meaning sooner or later other systems are going to want to call these services, and its best to be as prepared as possible for any way the app might scale in the future.
JL
+3  A: 

You could consider Microsoft's Sql Compact Edition.
It's like sqlite, in terms of being a single file embedded database, but has better integration with the .net framework :)
SQLite seems reliable, and even with Microsoft's one, don't expect to receive much support in case of a corrupted database.

wintermute
Sqlite works great, but I've definitely had trouble getting it to play nice with the visual studio active data object interface, so as long as youre going to be in windows land, maybe MS Sql Compact is a better choice.
Karl
+5  A: 

SQLite is as reliable as your OS and hardware.

Its transactional rate is similar to SQL server, and often faster because it's all in process.

The .NET ADO provider works great.

To back up the DB, stop the service and copy the file. If the journal file is present copy it too.

EDIT: SQLite uses UTF-8 by default so with the ADO-NET provider you should be able to avoid losing accents (just so long as you follow the typical XML in string rules).

Joshua
It's also safe to backup the database when you have an exclusive transaction without stopping the service--your exclusive transaction ensures nothing else is touching the db. Also version 3.6.11 added a live-backup API directly within the core engine (I don't know if the .NET wrappers exposes this yet but if not it'd be easy to add).
Sam
+1  A: 

Hi. I used SQLite with the .Net provider without problems in a monouser enviroment, except for one concern: accents, wich don't showed correcly. The backup is quite simply: the SQLite database is an plain text file. Simply copy it.

Apocatastasis
What are accents? Never heard of them.
JL
"acentos" in spanish, I guess: something like this á
Apocatastasis
Ok, then I will have a problem because the solution I am using is for Czech clients which don't use an english character set.
JL
Yes, I also have had a little headache here, because my aplication is for spanish speakears. I try to investigate about it. That seems a problem of encoding. I don't find much information about this issue.
Apocatastasis
According to google "sqlite unicode", it handles it fine if you tell it in advance that you want a fancy encoding:PRAGMA encoding = "UTF-8";
Karl
Have you seen the other answers, it seems the accent support is not a problem with the database, but it needs special considerations when using non english characters.
JL
+1  A: 

I use Sqlite for storing XML config data and have had no problems with it. I use the System.Data.Sqlite provider: http://sqlite.phxsoftware.com/. It's solid and has a good support forum. It also includes a LINQ provider. It also integrates with VS 2008 so you can use Server Explorer to query tables. The examples and documentation also show how to use parameterized commands and transactions for increased performance.

The release candidate for LinqPad now supports Sqlite: http://www.linqpad.net/Beta.aspx.

Sqlite stores everything in a single file, which can be backed up like any other binary file.

Sqlite only supports file-level locking, but shouldn't present a performance problem since it doesn't sound like you'll have a large number of simultaneous transactions.

Unicode shouldn't be a problem. This link in the forum addresses an area where someone was trying to read unicode characters with an incompatible utility http://sqlite.phxsoftware.com/forums/t/954.aspx.

This site shows how to do case-insenitive UTF8 comparisons using System.Data.Sqlite via a custom collator, with Russian characters as an example: http://www.codeproject.com/KB/database/SQLiteUTF8CIComparison.aspx.

ebpower