Oracle Woe's - Pam Issue?

[Dan Lund]

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 <BONeal at cornerstonehome.com> 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 at lists.plug.phoenix.az.us
> [mailto:plug-discuss-bounces at 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,  <alex at crackpot.org> wrote:
> > Quoting Mike Garfias <mike at garfias.org>:
> >
> > 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 at 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 at 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 at 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."