There are two purposes for a database in sipXecs.  The first use is
transactional.  This is to keep track of the current state of the system
including registrations, subscriptions, calls, etc.  This information needs
to be persisted so that if a process fails, it can be restarted with the
current state to become quickly operational.  In a HA implementation, this
information also needs to be replicated to all servers running similar
processes.  In today's architecture, this is accomplished by custom code
that writes out the tables in memory as XML files, establishing tunnels
between systems, and exchanging data over those tunnels. The data is not
normalized which is why the same information is found in many of the files.
There are scenarios when this information is of value to an administrator
(i.e. ability to delete a registration or kill an active call) but in these
cases, access to the data should only be through an API.

Postgres' use was intended as persistence for configuration information
including users, phones, etc.  It is also used for capturing call history
(CDRs) and call state (CSEs).  The information in this database is
normalized to facilitate queries and processing via a web interface. The
tables in Postgres are normalized to facilitate queries.

There are many transactional databases that provide replication across
servers.  Use of one of these databases will remove the home-grown
replication/persistence and simplify the code in a many processes.  The
transactional database should be a "black box" and its' selection should be
based on how well it meets the need to persist state and replicate that
state across nodes in a cluster.

So I do not see an issue with use of two different databases in a system.
This is a common practice with high volume messaging systems. 

DD 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Douglas Hubler
Sent: Monday, September 13, 2010 6:35 PM
To: sipXecs developer discussions
Subject: Re: [sipx-dev] Request for comments regarding system performanceand
how it's related to configuration

On Mon, Sep 13, 2010 at 9:18 PM, Flatfender <[email protected]> wrote:
> +1 for everything being in one DB.  I'm not saying mongoDB doesn't
> have distinct advantages over PostgreSQL.  But for a sake of
> simplicity,  having everything in one DB makes a lot of sense.

for creds and perms, memcached would be better than postgres for our
needs.   We're leaning way more towards ephemeral storage, replicated
everywhere seemlessly.  There is no need to backup these databases,
consequently no need to restore them. Rebuilding 5000 record db takes
3 seconds.  Calls and proxys stay up in the meantime.

Could you use postgres for what people use memcached for? yes, and
people do, and it's not pretty.

I've registered for a mongodb conference on monday here in boston,
i'll try to keep an open mind.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/

Reply via email to