An RDBMS for CTI System? 51
cpt_koloth asks: "The company I work for are currently in the process of designing a custom CTI system for a client. A small part of the system is implemented, mostly to familiarize the development team with the telephony API (in our case TSAPI, since the client uses an Ericsson PBX) as a simple click 'n dial application. The main issue is the database system which will be used. We need a database is fast so that it can assign the calls without delays. The present system uses MySQL and is doing great but the numbers of requests will increase exponentially once the 'main' parts of the system are implemented (we have about 60000 requests per day currently most of them being cross table queries but finally they should be seven or eight times this number). Another aspect is the reporting agent, which will operate on the same database and also needs to be fast. We are currently thinking on a system with two databases one for the 'calling part', and one for the reporting part, and we cannot decide on the RDBMS to be used with the way the data will be updated between the two databases. Keep in mind that cost matters a lot. Does Slashdot have any insight to offer?"
My Solution: Two MySQL Databases! (Score:4, Interesting)
If mysql is working for you now, you should look at mysql scaling options. For example, if you are worried about reporting queries, replicate the database to a second machine for running the reports against. Mysql replication works great for this sort of application. Also, if your dialer application is only performaning read queries, you can spread those across replicas too.
Knowing the current 'size' of your database would help -- if it's a dual processor box with 1 or 2 gb of ram, there are still a few affordable forklift upgrades before you need to worry too much about one box or mysql's performance (assuming your indexes are set right).
Also, MySQL Cluster was designed by/for the telecomm industry -- the original commissioners were performaning analysis on call records or something of the such.
MySQL can definitely do whatever you want it to. Why switch?
Re:Interesting Solution (Score:2, Interesting)
CTI is a "common telephony interface". In my particular application, you would call into our helpdesk number and get a automated voice response unit. It would prompt you to type in the asset tracking tag off your PC. Once you entered this number in and pressed the # key you would be parked in the queue waiting for a helpdesk tech to answer. The IVR unit would pass this asset tag into the helpdesk software via CTI, and the helpdesk software would query the asset db so all the PC information would prefill right as the helpdesk agent took the call via a softphone on the pc. This allowed for all the relveant info to be present and sped up the call.
In the event the agent needed to transfer the call to a level 2 rep, they would transfer the call via softphone and the CTI interface would pass along all relevant details to the new party taking the call. This saved us from having each person taking the call to ask for the same basic info over and over again, and if each tech inserted noted on what they did, the client would not have to repeat the problem and the level 2 tech would not have to repeat troubleshooting steps already done.
Long and the short of it, the DB has to be quick enough to pass this info along or its not useful. If the info doesn't prefill immeadiately and it's quicker just to ask, then you haven;t bought yourself anything.
Re:And the problem with MySQL is? (Score:3, Interesting)