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

List:       sqlite-users
Subject:    Re: [sqlite] SQLite vs. Oracle (parallelized)
From:       Ken <kennethinbox-sqlite () yahoo ! com>
Date:       2009-02-23 21:47:24
Message-ID: 19818.5956.qm () web81006 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

I fully agree with DRH regarding SQLITE and single user performance. If you need to \
replace  fopen then sqlite is a really really great product. Even if you have some \
mild concurrency sqlite still does pretty darned good.

Oracle excels when you have many users that require concurrent database changes. 

Oracle performs row level locking and Multi-Versioning on data blocks to achieve \
concurrency.

Oracle can perform Parallel queries. But the best usage of parallel query is for full \
table scans where the entire table is read. And there are equally sized segments for \
scanning by the query slaves. Other wise parallel query probably won't help much. 



--- On Mon, 2/23/09, D. Richard Hipp <drh@hwaci.com> wrote:

> From: D. Richard Hipp <drh@hwaci.com>
> Subject: Re: [sqlite] SQLite vs. Oracle (parallelized)
> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
> Date: Monday, February 23, 2009, 3:28 PM
> On Feb 23, 2009, at 3:54 PM, python@bdurham.com wrote:
> 
> > Dr. Hipp,
> > 
> > When you say "SQLite is way faster than Oracle in
> a single-user
> > applications" do you mean that SQLite can be
> faster than Oracle even
> > when Oracle's parallel processing features are
> being used? For example
> > Oracle's support for parallelization can speed up
> table loading from  
> > an
> > external data source, certain SQL selects, and certain
> indexing
> > operations.
> 
> I don't run Oracle and have no way of verifying the
> following.  But I  
> conjecture that from a cold start, you and launch an
> application that  
> uses SQLite, have it do a dozen or so queries, print out
> the answer,  
> and shut down, all before the Oracle server has even booted
> up to the  
> point where it will accept connections.  Correct me if I am
> wrong.
> 
> Perhaps Oracle will run a gazillion more transactions per
> second,  
> given enough memory and CPUs, and once you get it up and
> going.  I  
> have no way of knowing.  But then again, that isn't
> really the point  
> of SQLite.
> 
> 
> > 
> > 
> > Are there any plans to enhance SQLite to support some
> of Oracle's
> > parallel processing or partitioning capabilities?
> 
> Remember:  SQLite is not trying to replace Oracle.  SQLite
> is trying  
> to replace fopen().
> 
> For people who are using Oracle as a replacement for
> fopen() (as  
> apparently Angela is) they will likely find that SQLite
> makes a far  
> superior replacement.  Or to put it another way, people who
> are using  
> Oracle for a single-user application (low concurrency) will
> likely  
> find that SQLite works much better for them.  It has been
> my  
> experience that old-time Oracle users are incredulous at
> this  
> statement, until they actually see a live demonstration. 
> So I won't  
> try to argue the point.  It is merely my observation.
> 
> On the other hand, nobody things that SQLite is a suitable
> database  
> when you have 1000 separate connections beating on the
> database all at  
> once.
> 
> 
> 
> > 
> > 
> > Thank you,
> > Malcolm
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > 
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> D. Richard Hipp
> drh@hwaci.com
> 
> 
> 
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
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]