Date: Tue, 11 Feb 2003 19:42:52 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org Subject: Re: Email push and pull (was Re: matthew dillon) Message-ID: <3E49C2BC.F164F19A@mindspring.com> References: <20030211032932.GA1253@papagena.rockefeller.edu> <a05200f2bba6e8fc03a0f@[10.0.1.2]> <3E498175.295FC389@mindspring.com> <a05200f37ba6f50bfc705@[10.0.1.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote: [ ... single instance message stores ... ] > In practice, as we scale up the system, this really isn't that useful. > > See > <http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld086.htm>; > and > <http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld087.htm>. Actually, I disagree with this presentation. There is an assumption of "sufficient storage" there in the first place, when in practice, sufficient storage is commonly a prime economic issue. If people were satisfied with the job "the big providers" were doing, there would be no little providers. As to the metadata updates: I'm not positive this is the case, though it is certainly the case in "sendmail" and certain other MTAs. It's really implementation dependent, I think, and the slide assumes a particular implementation. > Moreover, do you know how painful it is to lose a cc:Mail, Lotus > Notes, Microsoft Mail, or Microsoft Exchange database? You can > instantly toast all mail for all users on that post office. Of > course, you can only support about ~150 users per post office, but > then you have to manage a great many more post offices and your TCO > goes way, way up. The scaling issue at 150 is an implementation detail specific to the implementations you are referencing. My advice is "get some real software". 8-). You can scale something like this from Open Source components and about 3 months of concentrated coding to at least 50,000 per indivisible component cluster, and then throw hardware at it. The normal implementation to avoid single point of failure is replication of the data. At that point, the replication protocol itself becomes (essentially) a transport. The worst case failure mechanism, in that case, is a previously deleted message reappears. > How else do you think that Oracle can pitch their "Make Exchange > Unbreakable" solution, where as damn bloody expensive as the hardware > is that they base their solution on, the freakin' Oracle software > licenses are actually more expensive, and yet still make the sale? > They do it on TCO, and they do actually get the sales.... I think they do it on the basis of their name, and on the basis of the idea that "you can put any SQL server behind MS Exchange, so use ours, it's better than Microsoft's". I agree that, in one narrow view, this can translate to TCO, but it's not the major view that most people who are making the Buy Decision are coming from. Even coming from that point of view, you see mistakes made (e.g. Oracle vs. California). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E49C2BC.F164F19A>