Forgot your password?
typodupeerror
Databases Programming Software IT

An RDBMS for CTI System? 51

Posted by Cliff
from the chosing-the-right-database dept.
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?"
This discussion has been archived. No new comments can be posted.

An RDBMS for CTI System?

Comments Filter:
  • by locokamil (850008) on Wednesday December 27, 2006 @01:46PM (#17379316) Homepage
    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: (Score:2, Funny)

      by Anonymous Coward
      I just wish you would STFU.
    • Re: (Score:1, Offtopic)

      by Thansal (999464)
      I honestly can't tell if that was a joke or real advice.

      I am kinda frightened, and never want to have anything to do with a telephony set up....
    • Re: (Score:2, Funny)

      by RingDev (879105)
      Unfortunatly, only one of those acronyms are on the Acronym Finder http://www.acronymfinder.com/ [acronymfinder.com]

      So while the original poster's text was a bit over-acronymed, I can still understand the basic jist of it. Your post however appears to lack any merrit. I hope it was made in an attempt to ridicule the original poster's excessive use of acronyms, but it would have been significantly better had you used real acronyms.

      -Rick
      • by uradu (10768)
        Just Wow!
      • Re: (Score:2, Interesting)

        by rgbscan (321794)
        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 int
    • Re: (Score:2, Funny)

      by sampowers (54424)

      ... and lead to greater LUD which, of course, is what every management team wants!
      I am SO SICK of all these management LUDdite types.
    • by Blakey Rat (99501)
      List of acronyms in the summary I don't understand:

      RDBMS
      CTI
      TSAPI
      PBX

      List of acronyms in the summary I do understand:

      API
      MySQL

      Of course, since I don't know what the hell a CTI *is* (that seems to be the main focus of the question), I can't give any appropriate advice. So instead I'll give some inappropriate advice: Take your developers out to a martini bar.
  • Sounds like a good fit for MySQL Cluster.
  • by DrZaius (6588) <gary.richardson+slashdot@gmail.com> on Wednesday December 27, 2006 @02:05PM (#17379604) Homepage
    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?
    • by Pegasus (13291)
      Absolutely ... 60k per day number he mentions seems low to me. I'm comfortably running mysql with 2-3k queries per second ...
    • by kpharmer (452893)
      > MySQL can definitely do whatever you want it to. Why switch?

      because it is obviously a poor contender?

      > 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.

      Ah, that doesn't address partitioning, parallelism, query optimization, automatic summarization pr query rewriting, does it?

      Note t
      • by DrZaius (6588)
        I'm guessing the administration overhead of oracle or db2 would make it not worth while. Due to the fact he's asking slashdot about his problem, the expensive db's are probably out of reach for him. This is especially true because he says "cost matters a lot."

        I made the assumption that the reporting application already exists and runs against the current schema. If it doesn't, ETL is an option with MySQL just as much as any other database. Again, I doubt it will be a problem if cost matters -- they probably
        • by kpharmer (452893)
          > I'm guessing the administration overhead of oracle or db2 would make it not worth while. Due to the fact he's asking slashdot about
          > his problem, the expensive db's are probably out of reach for him. This is especially true because he says "cost matters a lot."

          Note that administration of oracle or db2 may or may not be greater than administration of mysql - if you find yourself having to manage a half-dozen mysql databases all replicating large amounts of data and struggling to support slow & co
          • by DrZaius (6588)
            All of your thoughts are valid, but probably not in this case.

            Sure, you've worked with all sorts of huge 100GB+ db's. It's really easy to say what a table scan of a 100m table can take on mysql. Again, I'm sure this poster isn't looking for db's in the 100gb scale, especially if he's asking slashdot.

            I'm betting a simple solution that will meet the needs of the poster using mysql can be done very quickly and cheaply. I'm also sure that you would end up spending around the same amount on oracle or db2 if the
  • by SirCyn (694031) on Wednesday December 27, 2006 @02:06PM (#17379630) Journal
    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.
    • by Dan Ost (415913)
      That rule only applies when you're doing the full development yourself.

      In this case, they're not interested in developing their own DBMS and so the quality
      of what they choose is independent of the time it takes to choose it (the cost depends
      on what they choose, but there are free DBMSs out there that, depending on what they
      need, will do just as nicely as an expensive DBMS).
  • Don't use an RDBMS (Score:1, Insightful)

    by chatgris (735079)
    From the sounds of it, you are using a RDMBS as a queue. If not, then ignore my message :D

    I've worked on a number of systems similar to yours: The end result is that databases aren't meant to be queueing systems, they are meant to *STORE* data. ACID compliance (even the little that MySQL has) is not meant for a queueing system. It's meant for long term data reliability. Replicating databases is generally useless, as you need to delete a queue element once it is complete, and that has to be done on *ever
  • MySQL is fast. If the queries you are doing on it now it can handle, "correctly" (i.e. with indexes.. use EXPLAIN SELECT....) then MySQL will almost definitely be as fast or faster then anything else for reads. Well, on a single machine. And Ill cover even money bets on when there is clustering, when all the data is everywhere. The likes of DB2 and Oracle may be able to do something with complex clustering, e.g. partitioning the data up on different machines. Without knowing about your app, I would think th

    • Re: (Score:3, Interesting)

      by dknj (441802)
      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.
      • by T-Ranger (10520)
        Details? Across how may boxes? Was it partitioned data? How many tables in a typical query? With mostly-reads, I just cant believe that MySQL was at the bottom of the list. Oh, yeh. What version of MySQL?
    • by kpharmer (452893)
      > MySQL is fast.

      Sorry - but relational databases are complex beasts - and too complex for such simplifications. MySQL can be fast - if you're on limited hardware with simple and highly-selective repetitive read-only queries hitting its MyIsam storage engine.

      But:
      - if you're doing reporting and querying more than 2-4% of the rows in the database then it wonly use a btrieve-index, and so will do table scans. This will suck, and be far slower than using a database like db2, oracle, informix
  • 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.

    Performance is always an issue, but there are some standard techniques for that. E.g., connection pooling (where a single connection is reused for 100-ish queries or 15 seconds before being discarded), caching read-mostly data, pushing as much of your logic in
    • 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 flawles

  • You're anticipating 500,000 requests a day, so let's bump it up to a million to give you a bit of wiggle-room. Assuming a worst-case scenario of those queries being shoe-horned into a typical 8-hour working day, that equates to an average of 35 queries a second, multiplied by some factor to account for peak usage. I have no experience of MySQL specifically but that doesn't sound like an unreasonable ball-park to me - with a decent server, proper indexing and well-written queries I don't see why you should s
    • Assuming a worst-case scenario of those queries being shoe-horned into a typical 8-hour working day, that equates to an average of 35 queries a second, multiplied by some factor to account for peak usage. I have no experience of MySQL specifically but that doesn't sound like an unreasonable ball-park to me - with a decent server, proper indexing and well-written queries I don't see why you should struggle.

      I'd also say from experience that either of the main Free/open source options could handily manage the
  • MySQL scales enough (Score:3, Informative)

    by guruevi (827432) <evi AT smokingcube DOT be> on Wednesday December 27, 2006 @02:29PM (#17379938) Homepage
    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 [developer.com] 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).
    • You do not use RAID5 for anything other than file systems with large files that need only sequential access.

      For databases nothing will hurt performance more than RAID5.

      A database will update 13 bits here and there, with RAID5 you need to read all of the (potentially multi-MB) stripe into memory to recompute the parity and then write both the data and the parity.

      For a database you will need something without parity, but with redundancy, than means: Mirrors.

      If you want more space and more performance you add
  • by alen (225700) on Wednesday December 27, 2006 @02:45PM (#17380108)
    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
  • "(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)."

    MySQL can very happily handle >800 queries per second on a single machine with good indexes. if you've got complicated data in big datasets, go with cluster or reader/writer replication where you can, and have a read-replica for reporting.

    Like others have said - any respectable db should be able to do this without problem.
  • MySQL Cluster may be just what you are looking for. Just keep your database schema very simple since there are some gotchas with the cluster back end.

    In the end, your real-time call database may need to be mysql cluster for speed and call processing, but other database functions can probably be farmed off to an inno back end or another database entirely (pgsql, sql server, etc.).

  • If the supported limits are enough for your app:

    Max 4 gb of user data
    Using at most a single processor
    Using max 1 gb RAM

    Oracle its a pretty decent option, and this version its free (as in beer, not as in speech).

    Faq here: http://www.oracle.com/technology/products/database /xe/pdf/dbxe_faq.pdf [oracle.com]

  • by Generic Player (1014797) on Wednesday December 27, 2006 @03:39PM (#17380672)
    "Does Slashdot have any insight to offer?"

    No.
  • You control the app, so you can easily log the response time of the database, and measure it with a small but credible test load.

    If you send the database a hundred or so requests at a rate that's deliberately slow, you will get an average response time that's a good estimate of the actual internal response time of the database. Let's say it's 1/10 second. With that number (alone) you can predict and plan for the performance you need.

    On a uniprocessor, you will get a maximum of 10 transactions per seco

  • ...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...

    We need a database is fast so that it can assign the calls without delays.

    ...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 a

  • How important is reliability to you? Do you do lots of writes, and if so are they to several tables?

    My gut reaction is that this is the kind of situation where you want a "real" database with ACID. But if reliability isn't that important (or you can, for instance, control power down tightly) then maybe something less can do.

    From what I read, MySQL is usually considered to be good for situations with lots of reads and a few simple writes (e.g. websites). Is that your situation or not?
  • I'm sorry to tell this to you, but you will be better off buying CTI software such as Altitude (disclaimer: I work for Altitude). You will pay your developers much more implementing all the different CTI possibilities:
    dial, answer, hold, extend, retrieve, conference, transfer, blind transfer, etc, etc.
    Also you want to do predictive dialing in the future perhaps, multimedia (web chat, e-mail handling), IVR? It is all in there when you buy it. When you need to write it - a huge amount of work.
    When you
  • Several rules to follow: 1) NEVER mix batch and production 2) NEVER mix reporting and production 3) Build on a platform that can scale 4) Do not share your CTI instance with ANY other activity. 5) Explore active:active deployment (such as Oracle 10G RAC) with transactional replication between the active nodes (such as shareplex). Our production CTI database uses a 32CPU cluster with 90GB ram, SRDF/S replicated disk between the sites between 2 facilities and BCV snapshots for performing Backup & Recove
  • by jregel (39009)
    No-one ever seems to notice that Ingres (not to be confused with Postgres) is now Open Source (GPL) software. As someone who has been using it for several years, I'm somewhat surprised. It's a mature and powerful RDBMS that can scale to very large systems. As an example, we supply systems capable of supporting upwards of 800 users running multiple complex queries on databases that are 80GB+. Of course, this is running on a 4 CPU Sun Fire V890 with 16GB RAM, but the point is that Ingres scales and is used in

"Consistency requires you to be as ignorant today as you were a year ago." -- Bernard Berenson

Working...