Interested yes, but I can not make the east side meeting due to a prior political commitment.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Garfias Sent: Wednesday, December 12, 2007 7:44 PM To: Main PLUG discussion list Subject: Re: Oracle Woe's - Pam Issue? Bryan - In my experience you'll be far better off NOT relying on one killer database box (or even a cluster) to handle all your data. HW only scales so far before it gets too expensive. Currently our most loaded DB box is doing 2-300 queries per second (a bit over 17M per day for those keeping score), and running just fine on commodity hardware w/ MySQL (ok, so commodity here is a raid10 scsi setup but still, its not big iron). We're seeing some serious performance problems, and we have the choice of scaling the hardware up, which gets stupid expensive really fast, or "sharding" the database See this link for info on howto do it: http://www.highscalability.com/unorthodox-approach-database-design-comin g-shard The benefits of doing this NOW is that you can start with one db server, and then add more when you need to. Not doing it as part of the inital dev cycle means that when you run into the wall, you'll have to spend a big chunk of time/money/frustration to add that support into your app. You also get the benefits of being able to goto frys and build a box today that'll work if you have an immediate need. Once you get into the big stuff, you can't have the hw the same day or even likely within a week. I'd definitely spend my money on an efficient use of the db, rather than on HW/licenses to run bigger and badder db hardware/software. Also, if you think of the db as a big storage drop, you could also say that Google did this with their search indexes. They didn't buy monster hardware, they found a way to use commodity hardware efficiently. If you're interested I'll (gasp!) be at the east side meeting tomorrow, hit me up then and we can discuss. Mike On Dec 12, 2007, at 6:10 PM, Bryan O'Neal wrote: > It's my nature to worry about problems that haven't happened yet. > After > all just because your paranoid doesn't mean their not out to get > you ;) > But seriously I like to have things mapped out and tested well in > advance. If there are two paths you can go by, I like to take both > paths and see which one goes further. That said, I am still willing > to > fight with Oracle, but not as much as I have been. I will be > discussing > with the development team on Friday, and will highly suggest we change > our DB out for My/PosetgreSQL and then just take that road as far as > it > will go while working down the oracle path. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Micah DesJardins > Sent: Wednesday, December 12, 2007 1:34 PM > To: Main PLUG discussion list > Subject: Re: Oracle Woe's - Pam Issue? > > Right now I think you're worrying about problems that haven't happened > yet. MySQL is pretty robust for what it does. Google uses it for a > lot > of internal applications stuff and the architecture of MySQL is > improving all the time. Personally I prefer PostgreSQL I think it's > cleaner and it makes "more sense" to me. Yeah, it's had a > reputation as > a bit of a dog but if you haven't looked at Postgres 8 benchmarks you > owe it to yourself to see how PostgreSQL is doing now that the code > base > is growing up. A lot of time and energy is now going into optimizing > performance these days and it has made a real difference. > > If you want to be blunt about it, given near infinite resources and > significant database complexity, neither MySQL nor PostgreSQL can > touch > Oracle. However, given finite resources and reasonably simple DB > structure with lots of brief OLTP queries instead of huge long linear > ones, MySQL and PostgreSQL can perform fairly close to on par with > Oracle but all talk about database speed needs to be prefaced with a > caveat that your DB structure and code, your hardware and storage > subsystems and how you have tweaked your chosen DB for performance for > YOUR application will all play a more significant role in your overall > application/transaction speed than which database you chose to begin > with. > > For a mere "thousands of transactions per minute" any of the discussed > databases will work depending on how complex said transaction is. My > advice is to write the best SQL you can that as is as close to ANSI > standards as possible (See Joe Celko's excellent books on this subject > for more info), pick one or the other of the free options (I'd go with > PostgreSQL for constraints and foreign keys alone but hey that's MY > preference and comfort zone go with what feels right to you) with the > understanding that if this really takes off, you'll be planning a > migration to Oracle (which happens all the time) if you find > yourself in > a situation where the database you started with is now > underperforming. > Just make sure it really is the DB software that is causing your > limitations, not your hardware, storage, or your code (or any number > of > middleware solutions for ORM) that is the choke point. > > Good luck! > > Micah > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > !DSPAM:14,476086a750041902375178! > > --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss