Hello Folks, Has anyone had production experience using * w/ MySQL Blobs to store sound files? The application I am working on requires all user data resides in a database. I am currently reading/writing the files to disk via a phpagi scripts but I would love to read the blob into a variable in the dial plan, etc. It seems like a waste of resources to write and delete the file. Thanks, Vinko Grskovic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20050307/8c331b4d/attachment.htm
>Has anyone had production experience using * w/ MySQL Blobs to store soundfiles? The >application I am working on requires all user data resides in a database. I am currently >reading/writing the files to disk via a phpagi scripts but I would love to read the blob into a> variable in the dial plan, etc. It seems like a waste of resources to write and delete the file. Too bad your requirement is to have everything in the DB, 'cause you will be asking for trouble in the long run. BLOBs are probably the fastest way to kill your DB once you scale. I did an experiment a few years ago to stream faxes as BLOB's into a SQL server and performance beyond a few thousand records was to put it mildly crap. IMO, use filesystem for files. Use DB for DB. Put a pointer in a field to the file. Your DB will love you for it. WinFS is the Microsoft solution to this problem (assuming it ever ships and gets backported), but I think the Linux guys are doing something like it with Reiser4, there's a plug in for this??
Checkout CVS. There is now support for storing voicemail sound files in DB with ODBC. -Matthew ----- Original Message ----- From: <vgrskovic@optonline.net> To: <asterisk-users@lists.digium.com> Sent: Monday, March 07, 2005 2:05 PM Subject: [Asterisk-Users] Asterisk & MySQL Blobs> Hello Folks, > > Has anyone had production experience using * w/ MySQL Blobs to store > sound files? The application I am working on requires all user data > resides in a database. I am currently reading/writing the files to > disk via a phpagi scripts but I would love to read the blob into a > variable in the dial plan, etc. It seems like a waste of resources to > write and delete the file. > > > Thanks, > Vinko Grskovic >---------------------------------------------------------------------------- ----> _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
Hi Vinko, MySQL blobs will store binary data, so you should be OK there. I'd focus on whether or not storing the data in a variable is a good idea. Typically, with any programming language, it's good practice to keep variable lengths short so you aren't passing the variable itself between functions. I can't say if that could cause performance issues under higher load. I'd love to hear how you make out, as well as anyone else's input. - Eric On Mon, 07 Mar 2005 15:05:32 -0500 vgrskovic@optonline.net wrote:> Hello Folks, > > Has anyone had production experience using * w/ MySQL Blobs to store > sound files? The application I am working on requires all user data > resides in a database. I am currently reading/writing the files to > disk via a phpagi scripts but I would love to read the blob into a > variable in the dial plan, etc. It seems like a waste of resources to > write and delete the file. > > > Thanks, > Vinko Grskovic >
--- Colin Anderson <ColinA@landmarkmasterbuilder.com> wrote:> >Has anyone had production experience using * w/ > MySQL Blobs to store sound > files? The >application I am working on requires > all user data resides in a > database. I am currently >reading/writing the > files to disk via a phpagi > scripts but I would love to read the blob into a> > variable in the dial plan, > etc. It seems like a waste of resources to write > and delete the file. > > Too bad your requirement is to have everything in > the DB, 'cause you will be > asking for trouble in the long run. BLOBs are > probably the fastest way to > kill your DB once you scale. I did an experiment a > few years ago to stream > faxes as BLOB's into a SQL server and performance > beyond a few thousand > records was to put it mildly crap.Fair enough, I was thinking the same thing myself.> IMO, use filesystem for files. Use DB for DB. Put a > pointer in a field to > the file. Your DB will love you for it.The problem I suspect will arise is the number of inodes allowed by the file system. I don't know the exact size of the typical inode-max, but this will also presumably become an issue when the user tries to scale to really large amounts of faxes or voicemail! Would it help to split the db off to a separate server (that should reduce the CPU load on the asterisk server)? Any other alternatives? Anyone verified whether the BLOB storage solution breaks down first or the number of inodes runs out first? :) Cheers, Maya __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
--- Steven Critchfield <critch@basesys.com> wrote:> On Mon, 2005-03-07 at 13:30 -0800, beonice wrote: > >... snip ...> > Would it help to split the db off to a separate > server > > (that should reduce the CPU load on the asterisk > > server)? > > > > Any other alternatives? Anyone verified whether > the > > BLOB storage solution breaks down first or the > number > > of inodes runs out first? :) > > On a 40gig drive I have, there are 4.7million > inodes. > > On an 80gig drive I have there are 9.4million > inodes. > > Block size is (I think) 32k on these machines. At > 32k I could only use > 2.6 million inodes pointing to minimum sized files > on the 80gig drive. > > If you are worried about inodes, I believe it is xfs > that dynamically > creates inodes as needed and won't run out.Thanks, Steven. This is exactly what I was hoping to find out. DB performance issues aside, I was worried about running out of resources on the filesystem itself if I used the present vm storage mechanism. Cheers, Maya __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/