Sounds like performance is going to be fair and acceptable. I am not sure of the bandwidth on the network mounted file system but I believe its fairly good, probably gigabit.
Seems like my only worry is the data corruption possibilities. That's the crunch. Thanks for answering the latency question, Wayne. Anil. -----Original Message----- From: WB Stow [mailto:[EMAIL PROTECTED] Sent: Friday, 2 February 2007 1:12 PM To: sqlite-users@sqlite.org Subject: RE: [sqlite] Appropriate uses for SQLite I think that he said that he is running one website on four different servers using loadbalancing, in which case they do need to all share the same database. I have not tested this with SQLite, but if all four servers are connected via a gigabit ethernet backbone then you shouldn't have to worry about network latency much. I do not know anything about the warning about using SQLite with *high concurrency* websites. I thought that I read something about locking issues, but maybe someone else on the list can clarify that warning a little. Wayne -----Original Message----- From: Philip Butler [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 7:39 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Appropriate uses for SQLite I am not an expert on SQLite - but if you are running separate websites from your multiple servers, then why not use 4 instances of SQLite ?? That is unless the websites need to share the same database/tables. If they do need to share the same database/tables, then PostgreSQL or MySQL may be the more appropriate choice. They are designed to be distributed (hence their increased overhead) while SQLite is designed to be lean-and-mean. Just my 2 cents worth... Phil On Feb 1, 2007, at 7:03 PM, Anil Gulati -X ((agulati - Michael Page at Cisco)) wrote: > Hi SQLite users > > Thank you for your attention - I am just hoping for some clarification > of usability of SQLite. > Referring to: http://www.sqlite.org/whentouse.html > - SQLite works well in websites > - Other RDBMS may work better for Client/Server applications > - SQLite will work over a network file system, but because of the > latency associated with most network file systems, performance will > not be great > > I am trying to decide whether I can use SQLite for a website that runs > on 4 load-balanced servers using networked file storage mounted by all > servers for common data access. SQLite will have to load its database > from the network file space. > > These servers run multiple web-sites, hence the additional servers, > but my pages are not high hit-rate. The sites I am planning anticipate > a maximum of 200 users altogether. Current raw, uncompressed data > (mostly > text) is about 2MB growing to around 4MB. The current starter database > of 1.6MB raw compresses to 963KB. > > My concerns are: > > 1. Network file system > How bad is the latency introduced from using a network file system? > > 2. Concurrent access > I can't understand how SQLite is recommended for 99.9% of websites but > only *high* concurrency is not recommended? I currently use a flat- > file system which uses a single file per record. If users happen to > write to the same record simultaneously one of the updates will be > lost but corruption is highly unlikely, if not impossible. It seems > that for SQLite the risk for concurrent access is always data > corruption, which would be unacceptable for me. > > The issue is that there may be short periods where multiple users will > be updating around the same time and I want to make sure that the > possibility of corruption is extremely low. I am asking for more > detailed information on the above issues to clarify my decision. > > All feedback gratefully received. > Thanks. > Anil. > > ---------------------------------------------------------------------- > ------- > To unsubscribe, send email to [EMAIL PROTECTED] > ---------------------------------------------------------------------- > ------- ------------------------------------------------------------------------ ---- - To unsubscribe, send email to [EMAIL PROTECTED] ------------------------------------------------------------------------ ---- - ------------------------------------------------------------------------ ----- To unsubscribe, send email to [EMAIL PROTECTED] ------------------------------------------------------------------------ ----- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
