[erlang-questions] Mnesia for mobile telco billing?

[Ulf Wiger]

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
>