[Zope] ZPhotoAlbum and images in general
Frank McGeough
FrankMcGeough@msn.com
Fri, 6 Jul 2001 21:18:33 -0400
------=_NextPart_001_0001_01C10661.3620D400
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I think the question comes up a lot because when you have a db that is no=
n-relational, it's extremely difficult to get a handle on it's performanc=
e / reliability. With a relational database there are some standard bench=
marks (granted the vendors manipulate these in various ways but you can g=
et a fairly good idea of their general performance). The anecdotal, it's=
fast because I've seen it's fast is not quite as good as a standard test=
.
Most of the sql database vendors provide some means for managing the unde=
rlying files that actually store the data. Allowing me to add more, put t=
hem on separate partitions, etc. They also make it fairly easy to get the=
doc on how they layout the storage in these data files. They actually fe=
ature that in their development oriented doc -- to show how much better t=
heir technique is then other vendors. =20
To reduce the number of questions in this area, it seems like these two i=
ssues should be addressed.
Anecdotally :) --- I've become more comfortable with the Zope approach t=
hrough usage and gathering the doc that is available in various places. T=
hanks for the feedback.
=20
----- Original Message -----
From: seb bacon
Sent: Wednesday, July 04, 2001 2:17 PM
To: Steve Drees
Cc: Frank McGeough; Zope@Zope. Org
Subject: Re: [Zope] ZPhotoAlbum and images in general
=20
* Steve Drees <drees@the-bridge.net> [010703 20:38]:
> > is storing everything in one big file makes me extremely nervous. Pro=
bably
> > doesn't matter for smaller web sites but if I actually wanted to use =
this
> > for larger sites it would be a real sticking point. Any advice on thi=
s
> > point?
>
> Most databases store everything in a few large files. Why is one large =
file
> worse?
> ZODB is a real database. It's a real good database.
I just had to chip in and repeat your point again just to emphasise
it, since this question comes up so much :-)
I would always use the ZODB FileStorage unless there was a very good
reason not to. It's fast, supports undos, is easy to back up, and
keeps all your application in one place. The only two good reasons,
not to do so are:
1) if your OS has a nastily small file size limit (e.g. pre-2.4
Linuxen)
2) If you need to access the same data from elsewhere
(e.g. membership data in an LDAP storage)
sebGet more from the Web. FREE MSN Explorer download : http://explorer.m=
sn.com
------=_NextPart_001_0001_01C10661.3620D400
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><BODY STYLE=3D"font:10pt verdana; border:none;"><DIV>I think the qu=
estion comes up a lot because when you have a db that is non-relatio=
nal, it's extremely difficult to get a handle on it's performance / relia=
bility. With a relational database there are some standard benchmark=
s (granted the vendors manipulate these in various ways but you can =
get a fairly good idea of their general performance). &nbs=
p;The anecdotal, it's fast because I've seen it's fast is not quite as go=
od as a standard test.</DIV> <DIV> </DIV> <DIV>Most of the sql datab=
ase vendors provide some means for managing the underlying files that act=
ually store the data. Allowing me to add more, put them on separate parti=
tions, etc. They also make it fairly easy to get the doc on how they layo=
ut the storage in these data files. They actually feature that in their d=
evelopment oriented doc -- to show how much better their technique is the=
n other vendors. </DIV> <DIV> </DIV> <DIV>To reduce the number of qu=
estions in this area, it seems like these two issues should be addressed.=
</DIV> <DIV> </DIV> <DIV>Anecdotally :) --- I've become more c=
omfortable with the Zope approach through usage and gathering the doc tha=
t is available in various places. Thanks for the feedback.</DIV> <DIV>&nb=
sp;</DIV> <BLOCKQUOTE style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MAR=
GIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV s=
tyle=3D"FONT: 10pt Arial">----- Original Message -----</DIV> <DIV style=3D=
"BACKGROUND: #e4e4e4; FONT: 10pt Arial; COLOR: black"><B>From:</B> seb ba=
con</DIV> <DIV style=3D"FONT: 10pt Arial"><B>Sent:</B> Wednesday, July 04=
, 2001 2:17 PM</DIV> <DIV style=3D"FONT: 10pt Arial"><B>To:</B> Steve Dre=
es</DIV> <DIV style=3D"FONT: 10pt Arial"><B>Cc:</B> Frank McGeough; Zope@=
Zope. Org</DIV> <DIV style=3D"FONT: 10pt Arial"><B>Subject:</B> Re: [Zope=
] ZPhotoAlbum and images in general</DIV> <DIV> </DIV>* Steve Drees =
<drees@the-bridge.net> [010703 20:38]:<BR>> > is storing ever=
ything in one big file makes me extremely nervous. Probably<BR>> > =
doesn't matter for smaller web sites but if I actually wanted to use this=
<BR>> > for larger sites it would be a real sticking point. Any adv=
ice on this<BR>> > point?<BR>><BR>> Most databases store ever=
ything in a few large files. Why is one large file<BR>> worse?<BR>>=
ZODB is a real database. It's a real good database.<BR><BR>I just had to=
chip in and repeat your point again just to emphasise<BR>it, since this =
question comes up so much :-)<BR><BR>I would always use the ZODB FileStor=
age unless there was a very good<BR>reason not to. It's fast, suppo=
rts undos, is easy to back up, and<BR>keeps all your application in one p=
lace. The only two good reasons,<BR>not to do so are:<BR><BR>1) if =
your OS has a nastily small file size limit (e.g. pre-2.4<BR> =
Linuxen)<BR><BR>2) If you need to access the same data from elsewh=
ere<BR> (e.g. membership data in an LDAP storage)<BR><B=
R>seb<BR><BR></BLOCKQUOTE></BODY></HTML><br clear=3Dall><hr>Get more from=
the Web. FREE MSN Explorer download : <a href=3D'http://explorer.msn.co=
m'>http://explorer.msn.com</a><br></p>
------=_NextPart_001_0001_01C10661.3620D400--