[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Changes in SQL backend design

From: Jan Horák <horak.honza_at_gmail.com>
Date: Tue, 06 Apr 2010 10:19:26 +0200

Hi, I've made some changes in SQL backend desing, updated design is at:
http://www.stud.fit.vutbr.cz/~xhorak50/diplomathesis/files/100405_mysql_design_v2.png

As Philipp M. proposed, Representations are now provided with an SHA1,
but in a bit different way than in BDB. In BDB there is another table,
which means an unnecessary joining in SQL.

Txt_id fiels were renamed to txn_id, that was only a mistake. Txnprop_id
was removed and composed primary key <txn_id, name> is used instead.

Table names were kept in plural, even if Geoff R. supposed to use
singular, but plurals will correspond with BDB better. But if anybody
have good reasons, it's no problem to change it.

The last thing is the discussed storing of the representations in files,
not in DB. I've made a simple test of the access speed to database and
to pure filesystem, the report is here:
http://www.stud.fit.vutbr.cz/~xhorak50/diplomathesis/files/100406_data_access_speed_comparison.pdf

The conclusion is, that SQL can be faster when many small files are
readed the first time (thanks better cache), in other cases the
filesystem is faster, as supposed. But Greg S. had a very good point,
that I agree with:

> My gut says "not that much faster". In most scenarios, the network
> bandwidth between the client/server will be the bottleneck. Reading
> the data off a disk (rather than from a DB) is not going to make the
> WAN connection any faster.
...
> I'd go with the "store content in the database" until performance
> fiures (or a DBA) demonstrates it is a problem.

Thus the data stay in DB right now.
Received on 2010-04-06 10:20:07 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.