[erlang-questions] Erlang suitability

[Rapsey]

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/25076456/attachment.htm>