---------- Forwarded message ---------- From: Alex Jacobson <a...@alexjacobson.com> Date: Wed, Jun 17, 2009 at 2:55 PM Subject: Re: commercial happs project? To: Lemmih <lem...@gmail.com> Cc: Matthew Elder <m...@mattelder.org>, Thomas Hartman < thomashartm...@googlemail.com>
Better to talk about architecture on the mailing list, but short....
On 6/17/09 5:06 PM, Lemmih wrote:
On Wed, Jun 17, 2009 at 9:58 PM, Matthew Elder<m...@mattelder.org> <m...@mattelder.org> wrote:
I like the idea of building around the Amazon Platform initially. I saw that you mentioned something about using EBS as a filestore. I see a problem with this in a multimaster setup -- I initially looked into EBS for use with GFS (red hat's global file system) for shared darcs repositories between server instances. At the moment AFAIK an EBS is only able to be used by one instance, there is not that much flexibility as of yet.
In a multimaster setup, as long as you have one durable copy of the checkpoint and log you are good. Running on top of EBS, you just need to make sure that one instance is writing them (or that one is writing the checkpoint and that another is writing the log). You don't need sharing.
Now that said, if you wanted to leverage the Amazon platform for multimaster (if you don't think the existing spread implementation is good enough), I think we should consider something like SQS. http://aws.amazon.com/sqs/
with SQS we can allow the amazon platform to manage one unified queue (transaction log). One "master" can be in charge of writing the filestore to s3. what do you think?
While I agree that spread leaves some to be desired, I'm not sure SQS is a suitable replacement. Pulling instead of pushing messages would most likely add a significant amount of latency. The monetary cost of constant pulling and the difficulties with ordering messages also worry me.
SQS is really slow. We need millisecond latency. SQS has latency that is in seconds.