[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] SQLite Transaction Rate and speed...
From:       Nuzzi <nuzzi () smokemytool ! com>
Date:       2009-03-07 1:44:12
Message-ID: 22383529.post () talk ! nabble ! com
[Download RAW message or body]




Griggs, Donald-3 wrote:
> 
> Regarding:
> sorry.. no luck either... or I have a personal problem with your ftp
> server -- he doesn't like my anonymous login... ;)
> 
> ======================================
> 
> I get an error of "421 Too many users logged in for this account."
> 
> I guess we smoked your tool.     ;-)
> 
> 
> Pretty much echoing Roger Binn's recent comment, this posting by D. Hipp
> may be of interest:
> http://www.nabble.com/Behavior-of-SELECT-queries-during-transaction-to13
> 249797.html#a13257203
> 
> Just curious -- are you at liberty to say what this application is with
> this firehose of data?
> 
> Also, I know you required multiple-millions of actions per minute -- but
> since you'll be updating some rows rather than inserting them all, about
> how big do you anticpate the database being?   That can make a big
> difference because:
> a) Building and consulting the table's index will get longer the
> greater the number of rows, and
> b) If it's small enough, an in-ram database (":MEMORY:") Roger
> mentions might be feasible.
> 
> FTP error below:
> 
> N:\>ftp ftp.smokemytool.com
> Connected to ftp.smokemytool.com.
> 220-FileZilla Server version 0.9.24 beta
> 220-written by Tim Kosse (Tim.Kosse@gmx.de)
> 220 Please visit http://sourceforge.net/projects/filezilla/
> User (ftp.smokemytool.com(none)): anonymous
> 331 Password required for anonymous
> Password:
> 421 Too many users logged in for this account. Try again later.
> Login failed.
> ftp> 
> 
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> 

Sorry All, it is a very unreliable home web server.  I upped the anonymous
connections, so, theoretically, it should now work.

Anyway, to answer one question, the DB can get pretty big.  It is an
application that has to keep track of soundings in cells that cover a
certain area. The data comes fast and we have to record every bit of it, but
it could get crazy big to keep all the individual soundings, so we are try
keep the relevant data for each cell (min, max, sum, sum squares, hits,
etc.).  We used to do this in memory but were exploring ways to not do that
anymore.  So, this was my first try at some kind of file based option.  I am
not optimistic, though, but was just hoping it was more my ignorance rather
than capabilities.  Also, there will be many clients updating and reading
from the "server."  I think it will have to be a very complex combined file
and memory approach.

Thanks for suggestions, and I will look at the links, but I am pretty sure I
will be starting to look at other options very soon.

John
-- 
View this message in context: \
http://www.nabble.com/SQLite-Transaction-Rate-and-speed...-tp22379931p22383529.html \
Sent from the SQLite mailing list archive at Nabble.com.

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[prev in list] [next in list] [prev in thread] [next in thread]