Hello Jan!
On Dienstag, 6. April 2010, Jan Horák wrote:
> 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_des
> ign_v2.png
...
> 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_acce
> ss_speed_comparison.pdf
Fine, thank you very much.
> 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.
I'm fine with that.
Just a minor nit: how about allowing a mixed design (later, optional, when the
backend is running)? Ie keep blocks smaller than N in the database, but write
larger ones to the filesystem? Or provide different paths depending on the
block size?
Then people with SSDs could use them for the small blocks (or just keep them
in the database, as before), but larger data entities could be read from disk
directly.
That would probably make some sense, as small blocks don't matter if they're
travelling across a few pipes; but for multi-MB data blocks that should be
avoided.
Thank you very much!
Regards,
Phil
PS: I'd like to know which filesystems you did test, BTW ;-)
Received on 2010-04-06 10:51:25 CEST