In that case, I second the use of memcached, but with the caveat of a well-tuned mysql/postgres backend and ANSI standard SQL. :) On Dec 13, 2007 10:20 AM, Bryan O'Neal wrote: > B) Very Small Shop. The development team consists of me and one other > person (not including copy people, legal people, & graphic designers). > We start with business logic and try to find the most efficient and > scalable combination to make that work. We are abstracting the code > from the DB (using hibernate), but not from the DB design (underlying > relational table structure). Think of it as not wasting a few thousand > dollars, but wasting 10%-20% of the development/deployment budget. If > we run a few K over now it is just as devastating as if we run a few > hundred K over two years from now. Any one remember Friendster? I am > doing what I can now to avoid those issues in the long run, while at the > same time make sure we get off the ground by our target date. > > -----Original Message----- > From: plug-discuss-bounces@lists.plug.phoenix.az.us > [mailto:plug-discuss-bounces@lists.plug.phoenix.az.us] On Behalf Of Dan > Lund > Sent: Thursday, December 13, 2007 9:34 AM > To: Main PLUG discussion list > Subject: Re: Oracle Woe's - Pam Issue? > > > How in god's name did we go from trying to remedy an Oracle issue, to > recommending avoiding databases? > Unless your either A) an ad-hoc programmer/designer, or B) a very > small shop, you're going to go the route of professional design which > separates code logic from DB logic. > > Added complexities in design to the point of absurdity to save the > company a thousand or so dollars just adds to future issues. > > On Dec 13, 2007 9:00 AM, wrote: > > Quoting Mike Garfias : > > > > I second this. Here's a few ideas from my experiences. > > > > - Whatever code you use to make a database connection should know how > > to select from one of many servers. The logic you use to make the > > decision isn't important yet, since you're starting with just 1 > > server. Just leave yourself a hook so that if you grow to multiple > > boxes, you won't have a major refactoring to do. Lots of web apps > > (especially ones that started as small open-source projects) are built > > around the assumption that the database is a single box, and breaking > > that assumption can be a huge pain once its in place. > > > > - Notice chunks of your code that do read-only queries. These could > > be offloaded to read-only database slaves. At least with MySQL, > > that's a very cheap and easy way to scale read traffic. MySQL > > replication is efficient and reliable. > > > > - Scaling write traffic is a lot harder. The 'sharding' approach > > mentioned earlier in this thread is the one that makes the most sense > > to me. Again, make sure your code is written so that, when the time > > comes, it is easy to select from one of many servers. > > > > - Don't use the database if you don't have to. Make use of a caching > > layer to save as much database traffic as possible. The MySQL query > > cache is a very easy way to do this, but something like memcache is > > even better since you can move traffic completely away from the DB > > server and towards other boxes. The memcache architecture is > > distributed by design, so it's easy to build a very large cache out of > > lots of cheap boxes. http://www.danga.com/memcached/ > > > > - Write good SQL. No amount of server-side tweaking will save you > > from badly written queries. > > > > - Monitor your performance from the beginning. Figure out ahead of > > time what the trouble signs might be that you're outgrowing your > > current resources. You don't want the first sign of trouble to be the > > fact that your app is crashing/offline. Ganglia is one way to do > > this, and I think works pretty well. > > http://ganglia.sourceforge.net/ If you try this out and want some > > mysql or apache specific ideas about what to monitor, let me know. > > > > I hope that helps. > > > > alex > > > > --------------------------------------------------- > > 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 > > > > > > -- > Thanks, > Dan Lund > > "This day we rescue a world from mysticism and tyranny, and usher in a > future brighter than anything we can imagine." > --------------------------------------------------- > 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 > -- Thanks, Dan Lund "This day we rescue a world from mysticism and tyranny, and usher in a future brighter than anything we can imagine." --------------------------------------------------- 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