An RDBMS for CTI System?

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?"

Comments

Interesting Solution

[locokamil]

I would recommend a RTFK running on a SMKPR, with a stock GHCCF, and several KKDFL's.

As you can see, this would drastically cut UIUER, and lead to greater LUD which, of course, is what every management team wants!

Re:Interesting Solution

[Anonymous Coward]

I just wish you would STFU.

Re:Interesting Solution

[rgbscan]

While I can't comment on the DB part, I can give a little insight into the idea behind this having worked on something similar.

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:Interesting Solution

[sampowers]

... and lead to greater LUD which, of course, is what every management team wants! I am SO SICK of all these management LUDdite types.

My Solution: Two MySQL Databases!

[DrZaius]

Hey,

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:My Solution: Two MySQL Databases!

[moderators_are_w*nke]

Queries per second is a meaningless number. It depends on what the queries are doing and how much data you have. Single row selects on primary keys are cheap, 1000 rows accross 8 tables with an order by is less so, it really depends what you're doing.

First rule of development

[SirCyn]

You have Cost, Performance/Features, and Time. When requesting anything you pick two and the other is determined by what you pick. You have picked all three. You want low cost, fast performance, and in a reasonable time. It doesn't exist. Pick two and try again. There's nothing essentially wrong with MySQL running in a high capacity environment. It would need to by properly maintained, and database design will matter a lot. Speaking of DB design, wanting to separate the reporting and dialing databases, which are functionaly connected, sounds like it rubs against the grain a bit. I don't know much about your specific environment, so take my opinion with a large grain of salt.

MySQL scales enough

[guruevi]

You have ONLY 60000 query's per day? That's on a 12 hour working cycle about 1,3 per second. ANY RDBMS should be able to handle this on today's hardware (even on yesterday's hardware).

If you're looking for data safety and recovery etc. you better make sure you use decent table types and optimized queries and that your programmers use database-side transactions (Yes, I've seen programmers implement the transactions on the program side, not a good idea btw) with whatever database system they are using. Check out http://www.developer.com/db/article.php/2235521 for the different table types and the pro/con's about them on MySQL.

Also make sure your hardware is decent. Especially with database systems, you do not want to have downtime because you saved $200 on the hardware. Use RAID5 or even RAID6 if possible, look at optimizing your server with the documentation from the merchant (MySQL AB has some good documentation). Another issue I recently walked into: don't use cheap SuperMicro hardware enclosures you built yourself. I got a hard drive stuck the other day because a power cable slipped under while sliding it in and had to bring the whole machine down to 'operate' it. I have good experience with Apple's hardware (the server hardware), it falls apart quit easily and is easy to maintain without downtime (up to replacing fans and power), you do not have to keep Mac OS X however if you don't want to.

MySQL is definitely an industry-grade solution, especially their latest versions. And they're relatively cheap (free if you want) and have a very good commercial support plan and staff (if you go not-so-free).

DB design is the key

[alen]

i'm a dba in a sql2000 shop and we have servers that serve over 1 million hits a day with very little problems

database design is your biggest challenge no matter what you use. you can spend $1 million on orcale, but if you build it wrong then you are wasting your money.

build a read/write design where your writable servers don't serve reporting or similar queries. A long select can cause locks for people trying to update data. force people to use the reporting servers for report and other data generation

use the right data type for the data. don't use bigint's where an int will do since it will cause your storage needs to grow and the data involved in each query will increase as well

build the hardware right. don't use RAID5 on files where you are going to have a lot of writes

Re:And the problem with MySQL is?

[dknj]

it also depends on size as well. we did a digital library project and benchmarked our app with mysql, postgresql, sql server, oracle and db2. the winners? oracle, sql server and db2. postgresql gets an honorable mention. i laugh at mysql.

Warning: parent contains FUD

[nule.org]

That's fine if you happen to like PostgreSQL. I use both that and MySQL a great deal. However, unless you have something to back it up, your comment that:

MySQL? Be sure you have a robust database first and work around that. I don't know if MySQL can handle high loads gracefully now, but in the past it's been known to flake out and corrupt the database. Not a good thing if that takes out your phones. needs to be taken as pure FUD. I implemented a MySQL solution for the integration department of a major North American hospital (one of the top 5) that logs all electronic medical record transactions between different hospital information systems (some 4+ million a day) to a MySQL database for querying, lookups and other functions, and it's run flawlessly for years on both 4.x and 5.x versions. The only time there was ever any data issue was when the entire data center lost power and you better believe that was the least of their worries.

Anyway, hopefully the mods will see this and -1 mod you and your fanboyism. PGSQL is fine, I'm using it now for a major project, but you needn't attempt to trash talk other solutions. It's simply counterproductive to the original poster's question.

I'll answer the easy question.

[Generic Player]

"Does Slashdot have any insight to offer?"

No.