[erlang-questions] HOW TO IMPROVE THE PERFORMANCE OF DETS
chamila piyasena
tchamila@REDACTED
Thu Dec 21 12:17:33 CET 2006
Thank you again Cristian,
actually it only stores the CDR records of the SMS(from number, to number ,
delivered or not, date, etc.. ) not the SMS it self and a separate dets
file is created every hour .
If some one want to see records related to a particular phone number in a
given period, suppose in a duration of month there will be many rows in
corresponding files.
going through all these records to select what we want is not efficient and
very slow.
thats why I thought about indexing (but there is no support for that in
dets)
and I changed the value N in the select function to a small value(actually
from 50000 to 2000) it speeds up some requests I made in the application.
Can we speeds up the retrieving by changing this N .
Changing the database to another type is not very easy at this stage as it
need a huge change in the coding.
thanx.
chamila
On 12/21/06, Christian S <chsu79@REDACTED> wrote:
>
> On 12/21/06, chamila piyasena <tchamila@REDACTED> wrote:
> > actually i was trying to improve the performance(the data retrieving )
> of a
> > smsc log server.
> >
> > the coding that I have use dets:select(Name, matchspec, N) inside the
> > function that gives the out put according to the request.
> >
> > And there may be huge number of rows(may be millions) that keeps track
> of
> > sms records.
>
> Why are you calling select on this data? Are you trying to find
> messages destined for a given terminal? Are you searching messages
> that are undelivered and too old so you can remove them?
>
> All these things warrant extra indecies by you. If you have millions
> of messages you probably want the robustness from using mnesia in a
> distributed setting too. Downtime affects too many users.
>
> When you receive a message, besides storing its content, also keep
> another table up to date that maps a terminal id to the messages
> destined for it.
>
>
> Using an external SQL database could be an alternative.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20061221/ca51535b/attachment.htm>
More information about the erlang-questions
mailing list