> What they want to have is a huge entity they can blame when everything
> goes wrong. They're not interested in the actual response times or
> even in the much more important time-to-fix because once they've
> blamed Oracle, they know the responsibility is no longer on their
> shoulders.
The usual individual developer, open source community, and small
company attitude is one that prefers to employ intelligent staff and
give them a lot of responsibility (with varying degrees of success).
They would rather spend a week refactoring code for performance, or
experimenting with another language or database, sending an employee
to training or conferences, contribute patches to open source
projects, etc. They will try to make a well thought-out decision up
front when possible, and often this results in an early choice for
PostgreSQL, especially because it fits within any budget. When these
people end up working in larger companies with different mindsets,
they sometimes are successful at getting PostgreSQL utilized through
resources like Command Prompt, EnterpriseDB, Greenplum, and so on, to
replace the vendor support that Oracle comes with. They might start
off with MySQL as a first database, but once learning about
PostgreSQL, will invest lots of time into porting if they understand
the advantages (this can be evidenced all the time by people
communication in the #postgresql IRC channel), and will put a lot of
effort into doing things the architecturally best way over time rather
than just slopping together bandaided bits and poor lazy table design.
Others are lazy, go with some popular name of something free they
hear, and end up as Red Hat/PHP/MySQL shops, with a huge pile of
random crappy free apps bandaided together - hoping to make some quick
cash. If they end up with PostgreSQL it's not a thought-out decision
(well or otherwise), and they use it very irresponsibly and then
everyone will blame "PostgreSQL" for all their problems simply because
it's not the most common name. There's a perception here that MySQL
is better for them because it's more popular, has more random free
crappy apps available for it, and they don't care much about the added
reliability of PostgreSQL (often they'll run with fsync=off), as
they're a rickety shop anyways. They'll also have a perception that
Oracle is some magical holy grail simply because it is so out of their
reach during early development, but as they become profitable enough,
the idea of buying Oracle becomes very exciting.
The corporate attitude is one that prefers things to be as
encompassing, bundled, automatic, and self-maintaining as possible.
They prefer Oracle because they provide a wide array of inbuilt
replication, backup, and administrative functionality - things like
raw device management (Oracle has implemented a couple different
filesystems as well), early integration with Java when it was all the
rage, tons of complicated shinies for permission control that managers
don't really comprehend but think they like and need and are using
correctly. These are typically Java shops, with no diversity at all -
you won't find a single perl or bash script lying around - they'll
load up a slow common Java framework for even the simplest task. Code
quality tends to be pretty decent, but there is heavy denial of any
problems and fixes are slow and obstructed by managerial complexity
and too much influence from Sales. :P
Another similar example can be found with ZFS or VxFS versus
traditional simple filesystems. ZFS has few tuning options and their
use is discouraged. It does a lot of things automatically and there
is a favoring of defaults over workload-specific tuning and
administrative overhead. It builds in every filesystem-related thing
(the filesystem itself, a logical volume manager, clustering tools,
and even it's own ZFS-specific filesystem cache daemon) into a single
manager-friendly bundle. You can't get the same levels of performance
out of it as you can by carefully tuning other systems, but that
tuning requires hiring intelligent staff and this seems to be
amazingly challenging for large corporations, and they'd rather pay
some middle-level manager a salary worth 5 developers, and have him
buy and assemble big packaged solutions instead.
PostgreSQL can't really take over the corporate market - Oracle and
DB2 will always be around too. :) To do that we'd need to do a lot of
unwanted things to the code, build in much more unecessary complexity
that most will never use, reduce flexibility and options in the
process, spange up incredible amounts of well-placed marketing dollars
and slowly get more acceptance by proving years of experience at an
increasing number of corporate PostgreSQL users.
I worked with PostgreSQL at Cingular - and the simple fact is that it
was not a good choice for the requirements of the task. The task as
defined could easily be called stupid and easy to change to do a
better way, but in that environment you can't stop a ball once it's
rolling and getting that ball or another one for change rolling takes
months and many meetings. Their minds were steeped in the ways of
Oracle, and Oracle has better optimizations for some stupid common
design/architectural/PHB mistakes. So then they try to bring their
broken methods to PostgreSQL verbatim, and it fails terribly. This is
not PostgreSQL's fault, but "PostgreSQL" gets the blame and label as a
substandard ("open source" in disdaining scoffing voice) database that
people only use because they can't afford Oracle, and even if the
effort is put in to do things right and it *is* faster, they still
won't like it and will feel that it's chosen out of resignation. So
really, it's better that we don't get the corporate market. This is
good, because it enables intelligent small businesses to have more of
a competitive edge and saner budget. Things like RAC and multimaster
replication are not good designs architecturally, but they are
encompassing ways to scale pretty much any existing design with
minimal effort. Corporations would much rather throw money/hardware
at a problem than refactor.
Right now where I work, our biggest performance problem could easily
be solved by moving a couple tables into an Oracle database. It
would be an easy port, and Oracle would handle the bad design much
better. Fixing it correctly is going to be a tedious process that
takes months to reach completion. As a small company, we plan to do
the latter, seek out quick fixes to buy us a little breathing room
until then, and avoid spending money (we'd much rather spend the
Oracle dollars on hardware improvements, etc.). A corporation will
usually throw money at Oracle and avoid spending developer time.
Currently PostgreSQL has a very good, strong, intelligent user
community. This has been the case consistently for all the years that
I've been using it, and it grows steadily over time without
significant changes in the overall community vibe. That said, when we
ported to Windows, there was an influx of a lot of former MySQL and
Microsoft SQL folks with very little general database knowledge
compared to the average PostgreSQL user. Fortunately this has not
been overpowering, and has lead to more people learning and doing
things more intelligently. But if we somehow magically took over the
majority of the corporate market, we'd have a lot more people involved
who frankly don't care to learn and just bicker and blame, which would
deplete the community resources for everyone else.
A knowledgeable PostgreSQL DBA can make significantly more than an
Oracle DBA as they're a scarcer resource and generally higher quality
on average. But it may be harder for them to find work - they may end
up having to move, telecommute, or commute a longer distance simply
because there are less PostgreSQL shops. It also means a much higher
probability of working for a small-medium company versus a corporation.
An Oracle DBA can be a lot lazier, and lean on the vendor a lot more.
There are open Oracle DBA positions everywhere, and it is very easy
for them to find another job, so learning a lot and focusing on doing
a good job are not important to them. In the corporate environment in
which most of these jobs are, they are responsible for far less in
their job role, whereas the PostgreSQL DBA tends to end up responsible
for a lot more pieces of the puzzle.
Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No comments:
Post a Comment