You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by pl...@lanminds.com on 2003/05/12 15:14:14 UTC
SQLite?
I don't know if anyone's heard of this little gem yet:
http://www.sqlite.org/
I came across it in the most recent issue of Linux Journal. The nice
thing seems to be that it's a full-fledged mostly-SQL92-compliant
embeddable DBMS which supports transactions, and is really fast (as
compared to MySQL and PostgreSQL. Additionally, it has bindings for
every language known to man-kind:
http://cvs.hwaci.com:2080/sqlite/wiki?p=SqliteWrappers
including Perl, Python, tcl, C/C++, and even shell!
Just thought someone doing the SQL port might be interested in
playing with this, either for prototyping or otherwise...
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQLite?
Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
> Any txns intended for a commit "should" be synchronized, but even then it
> doesn't really matter. If the server crashes mid-commit, then the client can
> just resubmit. The *only* time that you really want to sync to disk is
> during the final stages of a commit.
I.e. you want the `sync' mode.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQLite?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, May 13, 2003 at 01:07:08AM +0200, Benjamin Pflugmann wrote:
>...
> Reading the source[2] suggests that accesses for different processes
> are supported, but are serialized with granularity on the database
> level (the whole file containing all tables), i.e. nobody could check
> out any project while someone else is importing a new Linux kernel. I
> presume BDB handles that better?
BDB allows for access from multiple process and threads, simultaneously. I'm
not sure at what level the locks are, but I thought I heard somebody say
"page level" which is going to be better than table-locks, but not as nice
as row-locks. And certainly hella-better than database-locks.
> Besides, according to its own benchmark, it is only really fast for
> huge transactions (25000 INSERTs), but significantly slower for single
> statements with syncs (I presume here, that the nosync option is not
> suitable for Subversion).
Depending upon the operation, nosync might be quite nice. I actually
mentioned that to cmpilato the other day. For example, we construct a
long-lived txn in the database during an 'svn update' and other operations.
There is no reason at all to synchronize those to the disk. If the server
crashes while doing an 'svn update', then no big deal. The long-lived stuff
is actually supposed to be transitory, but the architecture doesn't allow us
to be that transitory.
Any txns intended for a commit "should" be synchronized, but even then it
doesn't really matter. If the server crashes mid-commit, then the client can
just resubmit. The *only* time that you really want to sync to disk is
during the final stages of a commit.
[ well, there are probably some generated IDs that need to be synced, and
maybe a few other bits, but in the majority: most of the DB operations we
performed can be somewhat lossy ]
>...
> > Just thought someone doing the SQL port might be interested in
> > playing with this, either for prototyping or otherwise...
>
> HTH,
It sure did. Thanks.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQLite?
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hello.
On Mon 2003-05-12 at 11:14:14 -0400, pll@lanminds.com wrote:
>
> I don't know if anyone's heard of this little gem yet:
>
> http://www.sqlite.org/
>
> I came across it in the most recent issue of Linux Journal. The nice
> thing seems to be that it's a full-fledged mostly-SQL92-compliant
> embeddable DBMS which supports transactions, and is really fast (as
> compared to MySQL and PostgreSQL.
Well, don't get me started on how flawed the comparisons are[1], but I
wanted to mention something, that is might be relevant to an SQL
backend for Subversion:
Since it's an embedded DBMS, it is not self-evident that several
processes can use it at the same time. I was not able to find any info
on that in the documentation (only for threads of the same process).
Reading the source[2] suggests that accesses for different processes
are supported, but are serialized with granularity on the database
level (the whole file containing all tables), i.e. nobody could check
out any project while someone else is importing a new Linux kernel. I
presume BDB handles that better?
Besides, according to its own benchmark, it is only really fast for
huge transactions (25000 INSERTs), but significantly slower for single
statements with syncs (I presume here, that the nosync option is not
suitable for Subversion).
That said, it's an interesting project, which already shows impressive
results.
> Just thought someone doing the SQL port might be interested in
> playing with this, either for prototyping or otherwise...
HTH,
Benjamin.
[1] For starters:
I was not able to find what kind of hardware the tests were
running on.
Standard RedHat packages for MySQL and PostgreSQL against an -O6
optimized Sqlite? Huh?
Default installs? The page links the result of someone configuring
PostgreSQL correctly, which gets the same speed as MySQL. So the
"sometimes 10 to 20 times faster" statement was simply ignorance
of the tester, but was not removed after he received the correction.
The web site (not only the benchmarks) is ignorant of the fact
that there is a MySQL version supporting transactions for as long
as Sqlite is published. And it is declared stable for almost 3
years now.
Tests are for Sqlite, which is embedded, against the network
version of MySQL. But there is an embedded version of MySQL
available! For quite some time. Meanwhile released as stable.
Don't know about PostgreSQL.
I do not mean that Sqlite isn't faster. But the available
benchmarks are not suitable at all to show anything relevant,
except that Sqlite isn't particularly slow when transactions are di
I am sorry for this rant. But it stems from being really
interested about the project and then being disappointed by the
presented information. Wrong expectations on my side, I guess.
[2] Version 2.8.0
Hm. It seems to try hard to differ in some way to any coding style
I am aware of :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org