[erlang-questions] Erlang suitability

Ovid <>
Fri May 18 11:49:02 CEST 2012


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 <>
>To: Ovid <> 
>Cc: "" <> 
>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 <> 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
>>
>>http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120518/1dcb0bb4/attachment.html>


More information about the erlang-questions mailing list