[erlang-questions] Mnesia for mobile telco billing?

[xenta xenta]

Thank you for detailed reponse!

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

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

btw what do you mean in coding, i am not so good in Erlang / Mnesia yet, has
Mnesia allow some coding/redisining ?

one more point, on what I have not found any info is Mnesia benchmarks, have
you seen it anywhere ?

Cheers,
Ks.

On Mon, Jul 28, 2008 at 5:40 PM, Ulf Wiger <ulf@REDACTED> wrote:

> What about geographical redundancy?
>
> (If that's a requirement too, the answer is: Mnesia doesn't support it,
> but it can be faked, to some extent, by fragmenting the tables and
> spreading the fragments and corresponding replicas smartly.
> One reason why this is possible is that mnesia is not particularly
> sensitive to delays in communications, so parts of a transaction
> can go over low-latency links and others over high-latency links.)
>
> As for the other requirements, the answer is "yes, but it depends".
> It depends on data volumes, and whether it's Ok that you have to
> do some coding (I've encountered similar cases where a requirement
> was that the DBMS should do all these things pre-packaged, with
> no coding whatsoever necessary - this has never been Mnesia's
> focus.)
>
> Prototyping is of course a good idea, and you should convince
> yourself that you can get the kind of characteristics you want.
> The requirements you list aren't obvious showstoppers, but
> Mnesia wasn't primarily designed for implementing billing databases.
>
> BR,
> Ulf W
>
> 2008/7/28 xenta xenta <ksiztof.laurenovic@REDACTED>:
>  > Hello gents,
> >
> > Just bumpped into Mnesia db and after studying it whole weekend I am
> still
> > in exalted state by him. Since I dont believe "silver bullets" I diecided
> to
> > ask Mnesia gurus before starting to prototype it. So what I am looking
> for
> > is suppopsed to be high performance IMDB for mobile telco billing,
> currently
> > our R&D department is considering off-the-shelf products like TimesTen,
> > BerkleyDB, MySQL Carrier Grade and so on. But there are also a lot of
> issues
> > even though they are comercial.
> >
> > could you dedicate some time to check whether Mnesia cover my very strict
> > requirements:
> >
> > 1) The imdb is intended for storing big amout of subscriber fund items
> (like
> > balances, counters: free traffic, free sms, free minutes, friendly
> numbers
> > and etc)
> >
> > 2) The number of fund items may vary from 12 mln and up to 420 mln
> depending
> > on telco provider, means scaling up and scaling out features are
> necessary
> >
> > 3) Fault tolerance and high availbility level of imdb should be "five
> nines"
> > at least
> >
> > 4) The host OS is Windows, pls dont I ask me why so :) but this
> requirement
> > is optional and can be substituted in case imdb provide high performance
> > through the network
> >
> > 5) Locking read and respecting unlocking write requests shall be
> supported
> >
> > 6) Number of items per atomic locking read/unlocking write may vary from
> 1
> > till 20 items
> >
> > 7) As persistent storage supposed to use Oralce DB, where imdb will write
> > all of changes asynchronously, and the fund items will be loaded from
> > persistent storage during fisrt initialization, this req is optional
> though
> >
> > 8) And the most important requirements are the throughput of IMDb that
> > should be at least 3000 locking read + write requests per second and
> latency
> > of either read or write request should be not more than 10ms
> >
> > Thank you,
> > Ksiztof
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080729/5381020c/attachment.htm>