Oracle Woe's - Pam Issue?

[Bryan O'Neal]

Interested yes, but I can not make the east side meeting due to a prior
political commitment.

-----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 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: plug-discuss-bounces at lists.plug.phoenix.az.us
> [mailto:plug-discuss-bounces at lists.plug.phoenix.az.us] 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 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
>
> !DSPAM:14,476086a750041902375178!
>
>

---------------------------------------------------
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