<div dir="ltr"><p>Thank you for detailed reponse! <br> <br>What i liked in Mnesia that it is adapted for "one by one" synchronous requests that`s right what we need in telco domain, where each request should be safe and logged in redo file, since request may convey fund movements like payment, debiting correction, reservation and so on, it means we cant lose even one of them. Although asynchronous bulk interaction would be more faster and efficient, but not safe such as component which is sending/receiving/retranslating requests towards IMDB becomes statefull and in case of any crash may lose requests which were not processed</p>

<p>as for geo redundancy you are right it is worth but not mandatory, moreover that property can be maintaned by Oracle RAC which serves as persistent storage for an IMDB, since Oracle RAC is common choise in telco field<br>
 <br>btw what do you mean in coding, i am not so good in Erlang / Mnesia yet, has Mnesia allow some coding/redisining ?<br> <br>one more point, on what I have not found any info is Mnesia benchmarks, have you seen it anywhere ?<br>
 <br>Cheers,<br>Ks.<br><br></p>
<div class="gmail_quote">On Mon, Jul 28, 2008 at 5:40 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@wiger.net">ulf@wiger.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">What about geographical redundancy?<br><br>(If that's a requirement too, the answer is: Mnesia doesn't support it,<br>
but it can be faked, to some extent, by fragmenting the tables and<br>spreading the fragments and corresponding replicas smartly.<br>One reason why this is possible is that mnesia is not particularly<br>sensitive to delays in communications, so parts of a transaction<br>
can go over low-latency links and others over high-latency links.)<br><br>As for the other requirements, the answer is "yes, but it depends".<br>It depends on data volumes, and whether it's Ok that you have to<br>
do some coding (I've encountered similar cases where a requirement<br>was that the DBMS should do all these things pre-packaged, with<br>no coding whatsoever necessary - this has never been Mnesia's<br>focus.)<br>
<br>Prototyping is of course a good idea, and you should convince<br>yourself that you can get the kind of characteristics you want.<br>The requirements you list aren't obvious showstoppers, but<br>Mnesia wasn't primarily designed for implementing billing databases.<br>
<br>BR,<br>Ulf W<br><br>2008/7/28 xenta xenta <<a href="mailto:ksiztof.laurenovic@gmail.com">ksiztof.laurenovic@gmail.com</a>>:<br>
<div>
<div></div>
<div class="Wj3C7c">> Hello gents,<br>><br>> Just bumpped into Mnesia db and after studying it whole weekend I am still<br>> in exalted state by him. Since I dont believe "silver bullets" I diecided to<br>
> ask Mnesia gurus before starting to prototype it. So what I am looking for<br>> is suppopsed to be high performance IMDB for mobile telco billing, currently<br>> our R&D department is considering off-the-shelf products like TimesTen,<br>
> BerkleyDB, MySQL Carrier Grade and so on. But there are also a lot of issues<br>> even though they are comercial.<br>><br>> could you dedicate some time to check whether Mnesia cover my very strict<br>> requirements:<br>
><br>> 1) The imdb is intended for storing big amout of subscriber fund items (like<br>> balances, counters: free traffic, free sms, free minutes, friendly numbers<br>> and etc)<br>><br>> 2) The number of fund items may vary from 12 mln and up to 420 mln depending<br>
> on telco provider, means scaling up and scaling out features are necessary<br>><br>> 3) Fault tolerance and high availbility level of imdb should be "five nines"<br>> at least<br>><br>> 4) The host OS is Windows, pls dont I ask me why so :) but this requirement<br>
> is optional and can be substituted in case imdb provide high performance<br>> through the network<br>><br>> 5) Locking read and respecting unlocking write requests shall be supported<br>><br>> 6) Number of items per atomic locking read/unlocking write may vary from 1<br>
> till 20 items<br>><br>> 7) As persistent storage supposed to use Oralce DB, where imdb will write<br>> all of changes asynchronously, and the fund items will be loaded from<br>> persistent storage during fisrt initialization, this req is optional though<br>
><br>> 8) And the most important requirements are the throughput of IMDb that<br>> should be at least 3000 locking read + write requests per second and latency<br>> of either read or write request should be not more than 10ms<br>
><br>> Thank you,<br>> Ksiztof<br>><br></div></div>> _______________________________________________<br>> erlang-questions mailing list<br>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>><br></blockquote></div><br></div>