Though you don't have to load a MySQL DB onto a RamDisk. MySQL has the MySQL cluster that loads the entire DB into memory and creates a fault tolerant DB as well. We use that today for an LCR that works well. The newest version of MySQL has stored procs, a very mature replication (it can even do a Cluster to Cluster Replication), triggers, and competes very well with Postgres. But this is a Chevy vs Ford type of discussion.
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html There are lots of telco's using it as well. I use it a lot for many differnet projects and it keeps up nicely. --Joe On Tue, Aug 12, 2008 at 4:14 PM, Ken Rice <[EMAIL PROTECTED]> wrote: > Actually having evaluated MySQL for large scale environments it works > well up to a point... Postgres on the other hand has much more mature > replication, store procedures, triggers, a query cacher that insane and no > need to use mysql's so called 'hash tables' to get the data loaded into ram > (pg does this automagically via its caching mechanism) > > Mix that with table partitioning and you have some fairly crazy numbers > > Real world deployments doing some pretty complex LCR shows that a small > cluster (4 boxes) or old dell 2650s are able to sustain > 40K queries/sec > (~10% being inserts for CDRs) > > When you get into this scale the real enterprise work that has been done on > pgsql starts to show thru... Companies like Greenplum feed a good bit of > their core performance tuning back to PgSQL... (for those that are wondering > pgsql is bsd licensed so its actually license compatible w/ FreeSwitch say > some someone want to look at replacing sqlite with a pgsql engine) > > > > > ------------------------------ > *From: *Darren Schreiber <[EMAIL PROTECTED]> > *Reply-To: *<freeswitch-users@lists.freeswitch.org> > *Date: *Tue, 12 Aug 2008 12:35:25 -0700 > > *To: *<freeswitch-users@lists.freeswitch.org> > *Subject: *Re: [Freeswitch-users] Performance bottleneck > > I dont know if this makes any sense - it's just an idea. > > If you're willing to take the hit of running MySQL, I know that it's > replication features could potentially be used. You can have the primary > MySQL server run in ramdisk and get all the performance benefits of doing so > while also writing log files to the ram disk in a seperate area. Those > logfiles can, using MySQL's built in replication features, be copied over to > a backup server and played backup, giving you both a hot spare as well as a > disk based backup. > > This does three things for you: > 1) Gives you backup on disk, while preserving performance in RAM > 2) Gives you a live backup that you can quickly shunt things over to if for > some reason the primary dies > 3) Allows you to handle spikes in volume. MySQL by default will just write > to the log files and they can be played back later by the (slower) backup > server, so a spike in volume of calls should not cause the server to slow > down per say. There is a small risk your data will be lost if there is a > failure for whatever is not copied over to the (slower) backup server, but > that's unlikely to be that huge a lag (better then nothing). > > As to whether any of this applies (like why the heck you'd install MySQL on > a ramdisk to start), I can't say. but it's a thought...Oh, and you need a > lot of RAM ;-) > > ------------------------------ > *From:* Ken Rice [mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]> > *Sent:* Tuesday, August 12, 2008 11:44 AM > *To:* freeswitch-users@lists.freeswitch.org > *Subject:* Re: [Freeswitch-users] Performance bottleneck > > Actually I don't know of any mechanism that will back up the DB... Where > sqlite does work well for small to medium installations it only scales to a > point... Sqlite does not reuse 'nodes' in the db on an update... It marks > them as dead and creates a new entry... While this works ok on smaller > tables w/ light to medium updates after a while you have to compress or > vacuum the tables... This requires a table level lock with sqlite... FS does > have some things built in to handle this, but under load this can cause the > switch to appear to hang. > > Switching over to use something like Postgresql (my prefered db) helps out > a good bit here, but keep in mind that in doing so you greatly increase the > resources required for the db. Also don't forget that pgsql has a similar > mechanism on how it handles updates, just don't forget to enable > auto-vacuuming on pgsql... That is a discussion for a different list tho > > K > > > ------------------------------ > *From: *Brian West <[EMAIL PROTECTED]> > *Reply-To: *<freeswitch-users@lists.freeswitch.org> > *Date: *Tue, 12 Aug 2008 13:24:40 -0500 > *To: *<freeswitch-users@lists.freeswitch.org> > *Subject: *Re: [Freeswitch-users] Performance bottleneck > > Well putting the db in ram does help a bit but it has to keep states of > everything going on and do extra work for that... its a heavy task in > itself. > > On Aug 12, 2008, at 1:19 PM, Michael Collins wrote: > > That begs the question… is there a mechanism in sqlite or Linux that > allows for the RAM drive to be backed up periodically? That would be a > cool feature to get documented for those power users like Ken! ;) > > -MC > > > > > Brian West > sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> > > > > > > ------------------------------ > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > ------------------------------ > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > >
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
