[erlang-questions] Erlang suitability

[Rapsey]

Distributed erlang
http://www.erlang.org/doc/reference_manual/distributed.html

I actually don't have a lot of experience in running a distributed erlang
installation, but guys in this discussion do:
https://groups.google.com/forum/#!topic/erlang-programming/YUEPsDtGbso

But from the information you have provided erlang should definitely be the
best tool for the job. Since you lack erlang experience, maybe you should
contact the erlang solution guys: http://www.erlang-solutions.com/



Sergej

On Fri, May 18, 2012 at 11:49 AM, Ovid <curtis_ovid_poe@REDACTED> wrote:

> Hi Sergej,
>
> Thanks for the response. It sounds like use case 2 is easier than I
> thought.
>
> As for Mnesia and use case 1, our thought was twofold:
>
> 1. We want ACID compliance. We need to ensure that were all 75 boxes to
> mysteriously crash, we could bring them back up and not worry about data
> integrity.
> 2. Our storage needs are likely to become more complex in the future. The
> daily and total capping amounts will eventually be broken down into a
> variety of different categories, along with synchronization of which
> machines bid on a request and if those individual machines won a request
> (something that we currently cannot do without offline aggregation of this
> data).
>
> When you say "75 machines in a fully connected distributed erlang network
> is a bit much but it should work." could you elaborate on that? It makes
> me a bit nervous to hear, particularly since we have no Erlang knowledge
> and just assumed that it was suited for this. Are we thinking about this
> the wrong way?
>
> Cheers,
> Ovid
> --
> Live and work overseas - http://www.overseas-exile.com/
> Buy the book - http://www.oreilly.com/catalog/perlhks/
> Tech blog - http://blogs.perl.org/users/ovid/
> Twitter - http://twitter.com/OvidPerl/
>
>   ------------------------------
> *From:* Rapsey <rapsey@REDACTED>
> *To:* Ovid <curtis_ovid_poe@REDACTED>
> *Cc:* "erlang-questions@REDACTED" <erlang-questions@REDACTED>
> *Sent:* Friday, 18 May 2012, 11:40
> *Subject:* Re: [erlang-questions] Erlang suitability
>
> 75 machines in a fully connected distributed erlang network is a bit much
> but it should work.
> use case 1: Why do you need to store to mnesia and all machines read from
> it? If you have 75 servers erlang connected, you can just send a simple
> erlang message to all of them.
> use case 2: In a fully connected erlang network you always know which
> machines are offline/online. Every machine has a name.  If you simply sort
> all online machines by node name, that is the node you pick to do
> authentication. No real synchronization required and it will work even if
> that machine is lost. Or you can hardcode a sequence of machines which ones
> do the authenticating. First in list that is online is the one that does it.
>
>
> Sergej
>
> On Fri, May 18, 2012 at 11:00 AM, Ovid <curtis_ovid_poe@REDACTED> wrote:
>
> Hi there,
>
> We've a system that run across 75 servers and needs to be highly
> performant, fault-tolerant, scalable and shares persistent data across all
> 75 servers. We're investigating Erlang/Mnesia (which we don't know) because
> it sounds tailor-made for our situation.
>
> We are not using Erlang for our first implementation, but are instead
> hacking together a solution from known technologies including Perl, MySQL
> and Redis. We're considering Erlang for our future work.
>
> We have two primary needs: Each box can bid on an auction and potentially
> spend a tiny amount of money and each of the 75 boxes will receive
> notifications of a small amount of money spent if they win the auction (the
> auction notification will probably not be sent to the box bidding in the
> auction).
>
> Use case 1: If the *total* of all of those small amounts exceeds a daily
> cap or an all-time cap, all 75 boxes must immediately stop spending bidding
> in auctions. It seems that each box can run a separate Erlang process and
> write out "winning bid" information to an Mnesia database and all boxes can
> read the total amount spent from that to determine if it should stop
> bidding.
>
> This seems trivial to set up.
>
> Use case 2: we periodically need to reauthenticate to the auction system.
> We MUST NOT have all 75 boxes trying to reauthenticate at the same time
> because we will be locked out of the system if we do this. Having a central
> box handling reauthentication is a single point of failure that we would
> like to avoid, but we don't know what design pattern Erlang would use to
> ensure that only one of the 75 Erlang instances would attempt to
> reauthenticate at any one time (all 75 boxes can share the same
> authentication token).
>
> Use case 1 is clearly perfect for Erlang. Use case 2 is less clear to us.
> We're going to be spending a fair amount of time hacking together a
> non-Erlang solution, but the benefit is using known technologies that don't
> depend on the "one guy who knows the system".
>
> At full scale, we anticipate billions of auctions per day.
>
> Does anyone care to comment about things we should look at? Particularly,
> is use case 2 not something appropriate for Erlang? A tiny amount of sample
> code would be lovely (note: I am somewhat comforable with Prolog, so Erlang
> looks fairly straightforward for me, aside from understanding the message
> passing).
>
> Cheers,
> Ovid
> --
> Live and work overseas - http://www.overseas-exile.com/
> Buy the book - http://www.oreilly.com/catalog/perlhks/
> Tech blog - http://blogs.perl.org/users/ovid/
> Twitter - http://twitter.com/OvidPerl/
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120518/c53b0ad5/attachment.htm>