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?"
Interesting Solution (Score:4, Funny)
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)
Re: (Score:1, Offtopic)
I am kinda frightened, and never want to have anything to do with a telephony set up....
Re: (Score:2, Funny)
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
Wow! (Score:2)
Re: (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 int
Re: (Score:2)
Thanks, I was wondering what it was since Wikipedia had not reference to this CTI [wikipedia.org]. However, Google offers some other definitions [google.com], including "computer telephony integration".
Cheers,
Fozzy
Re: (Score:1)
And according to the history it's been there for over a year.
Re: (Score:2)
Cheers,
Fozzy
Re: (Score:2, Funny)
Re: (Score:2)
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.
MySQL Cluster (Score:1)
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: (Score:2)
Re:My Solution: Two MySQL Databases! (Score:4, Insightful)
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:1)
> 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
Re: (Score:2)
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
First rule of development (Score:3, Insightful)
Re: (Score:2)
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)
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
And the problem with MySQL is? (Score:1)
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)
Re: (Score:1)
Re: (Score:1)
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
Get it right then get it fast (Score:1, Troll)
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
Warning: parent contains FUD (Score:2, Informative)
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
Is there definitely a problem here? (Score:1)
Agree--scalability isn't really a problem (Score:2)
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)
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).
No, NOT RAID5! (Score:2)
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
DB design is the key (Score:4, Insightful)
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: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
with oracle almost everything is an extra add on from the base product
Re: (Score:1)
MySQL should be fine (Score:2)
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.
Sounds like you need MySQL Cluster (Score:2)
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.).
Try Oracle XE (Score:2)
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/databas
I'll answer the easy question. (Score:3, Funny)
No.
First, measure the DB scalability (Score:2)
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
Good, Cheap, Quick -- Pick Two (Score:2)
Reliability? (Score:2)
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?
Buy proper CTI software (Score:2)
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
RDBMS for CTI (Score:1)
Ingres (Score:2)