Dne 6.4.2010 10:50, Philipp Marek napsal(a):
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.
This is interesting idea and this approach seems to be the fastest from
my perspective.
On the other hand it would be quite complicated and non-complex. I would
rather wait until some SQL
backend prototype will exist, then try all possible alternatives and
choose the best one.
Regards
Jan Horak
