Thread: Re: What do Oracle, DB2, etc. actually *do*?
Oops! Tim Smith <reply_in_group@mouse-potato.com> was seen spray-painting on a wall: > I've not been able to really figure out an answer to this question from > the websites of the commercial DB vendors: what do Oracle, DB2, etc., > actually do or provide that I do not get with PostgreSQL? > > Is there anything technical (as opposed to non-technical things like > support) that they provide that PostgreSQL is missing? In the case of Oracle, they have an excruciatingly large set of additional products that can be bundled in along with the database, including things like: - XML extensions - GIS extensions - Numerous Java-related extensions including a JMS implementation - Web application infrastructure - Additional tools for managing database instances A while back, we needed an Oracle 8i license for a project and ordered the "CD pack" which was a whole box full of CDs (including the one bit we needed) of all sorts of things they'd love to sell us. It was close to 30 CDs of this and that. Oracle is spending billions per year on developers; while some of the results may be of dubious interest, it certainly leads to having a growing stack of CDs. -- "cbbrowne","@","gmail.com" http://linuxdatabases.info/info/x.html "The computer is the ultimate polluter: its feces are indistinguishable from the food it produces." -- Alan Perlis
> > - XML extensions > - GIS extensions > - Numerous Java-related extensions including a JMS implementation > - Web application infrastructure > - Additional tools for managing database instances > >A while back, we needed an Oracle 8i license for a project and ordered >the "CD pack" which was a whole box full of CDs (including the one bit >we needed) of all sorts of things they'd love to sell us. It was >close to 30 CDs of this and that. > >Oracle is spending billions per year on developers; while some of the >results may be of dubious interest, it certainly leads to having a >growing stack of CDs. > > Oracle and DB2 also offer an ability to parallelize queries across nodes, so that you can query extremely large (multi-TB) data sets quickly. They also all market multimaster replication. PostgreSQL is an excellent small-to-reasonably-large-database RDBMS. If you get into the 3-5 TB range and need fast access to all the data, or if you need multi-master replication, you may need to look elsewhere, depending on your application. Best Wishes, Chris Travers Metatron Technology Consulting
Chris, While there may be limits to PostgreSQL's scalability, progress is definitely being made in this area. For example, Tom Lane's recent bufmgr locking overhaul should be a significant win on larger SMP systems. Also, if people do move to PostgreSQL and subsequently find that they're having problems with scalability, there are options other than migrating to an entirely new DBMS like Oracle/DB2/etc. If you'll pardon a shameless plug, Fujitsu Supported PostgreSQL includes a plug-in module, ESM, that should allow for significantly higher scalability (refer http://fastware.com.au/postgresql.html). Regards, Liam O'Duibhir _____________________________________________ Liam O'Duibhir - Product Manager - Open Source Software Fujitsu Australia Software Technology 14 Rodborough Road, Frenchs Forest NSW 2086 Tel: (61-2) 9452 9068 Fax: (61-2) 9975 3779 Mob: 0423 025 852 Email: LiamOD@fast.fujitsu.com.au www.fastware.com.au > -----Original Message----- > From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy- > owner@postgresql.org] On Behalf Of Chris Travers > Sent: Tuesday, 15 March 2005 3:47 AM > To: Christopher Browne; PostgreSQL advocacy > Subject: Re: [pgsql-advocacy] What do Oracle, DB2, etc. actually *do*? > > > > > > - XML extensions > > - GIS extensions > > - Numerous Java-related extensions including a JMS implementation > > - Web application infrastructure > > - Additional tools for managing database instances > > > >A while back, we needed an Oracle 8i license for a project and ordered > >the "CD pack" which was a whole box full of CDs (including the one bit > >we needed) of all sorts of things they'd love to sell us. It was > >close to 30 CDs of this and that. > > > >Oracle is spending billions per year on developers; while some of the > >results may be of dubious interest, it certainly leads to having a > >growing stack of CDs. > > > > > Oracle and DB2 also offer an ability to parallelize queries across > nodes, so that you can query extremely large (multi-TB) data sets quickly. > > They also all market multimaster replication. > > PostgreSQL is an excellent small-to-reasonably-large-database RDBMS. If > you get into the 3-5 TB range and need fast access to all the data, or > if you need multi-master replication, you may need to look elsewhere, > depending on your application. > > Best Wishes, > Chris Travers > Metatron Technology Consulting > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au
Liam O'Duibhir wrote: >Chris, > >While there may be limits to PostgreSQL's scalability, progress >is definitely being made in this area. For example, Tom Lane's recent >bufmgr locking overhaul should be a significant win on larger SMP systems. > > > I did not mean to suggest that these were permanent limitations. Indeed PostgreSQL seems to be growing fast enough to more than keep up with the growth of the users' databases! In the end every feature, from multimaster replication to parallelized queries will, I am sure, eventually be included in PostgreSQL. So this was more a statement of the current situation than a statement regarding all time. >Also, if people do move to PostgreSQL and subsequently find that they're >having problems with scalability, there are options other than migrating >to an entirely new DBMS like Oracle/DB2/etc. If you'll pardon a shameless >plug, Fujitsu Supported PostgreSQL includes a plug-in module, ESM, that >should allow for significantly higher scalability (refer >http://fastware.com.au/postgresql.html). > > Of course. I was approaching this more from the angle of "if i were using DB2, why might I not be able to migrate to PostgreSQL?" and "Where might I be included to pay for Oracle?" rather than "What limitations should I worry about in the future?" The last issue is a non-one. PostgreSQL 8.0 is a big step forward for competing with Oracle. And I am sure that we will take out another large chunk with the next release, etc. And if PostgreSQL meets your needs today, I really don't see that changing as your needs change. I guess, maybe I wasn't specific enough. Best Wishes, Chris Travers Metatron Technology Consulting
On Mon, Mar 14, 2005 at 09:47:24AM -0800, Chris Travers wrote:
> Oracle and DB2 also offer an ability to parallelize queries across
> nodes, so that you can query extremely large (multi-TB) data sets quickly.
>
> They also all market multimaster replication.
"Market" is the operative word in the IBM case, note. It's a fine
product, no question, but I've never been able to see any significant
way in which it's really multimaster. And you can actually do the
same sort of thing using the right combination of hardware and
PostgreSQL. In fact, my colleagues and I (ok, mostly my colleagues
-- I'm relegated to moving the furniture about) doing it right now.
ORAC is in another league entirely. I hope we can do something about
that soon, too.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
Here's my question about "multi-master" replication whether it's Oracle or not. How in the world does it work over high latency, low bandwidth connections w/o getting pummelled in performance? I mean it's fine when you have whole bunch of servers in the same building. But I've got servers across the country and waiting for 2-phase commit across a 100ms+ connection just sounds ugly like hell. I've tried some simple tests -- a client running some simple transactions across a VPN from San Francisco/CA to Sterling/VA and it's 10000 times slower than on a local 100mbit LAN. Andrew Sullivan wrote: > On Mon, Mar 14, 2005 at 09:47:24AM -0800, Chris Travers wrote: > >>Oracle and DB2 also offer an ability to parallelize queries across >>nodes, so that you can query extremely large (multi-TB) data sets quickly. >> >>They also all market multimaster replication. > > > "Market" is the operative word in the IBM case, note. It's a fine > product, no question, but I've never been able to see any significant > way in which it's really multimaster. And you can actually do the > same sort of thing using the right combination of hardware and > PostgreSQL. In fact, my colleagues and I (ok, mostly my colleagues > -- I'm relegated to moving the furniture about) doing it right now. > > ORAC is in another league entirely. I hope we can do something about > that soon, too. > > A >
William Yu wrote: > Here's my question about "multi-master" replication whether it's Oracle > or not. How in the world does it work over high latency, low bandwidth > connections w/o getting pummelled in performance? Well, it may well be the case that it doesn't work :) Not all kinds of replication are appropriate for all situations, and I agree that synchronous, multi-master replication isn't likely to be useful in the situation you describe. One solution to multi-master replication on slow networks (or networks with nodes that are only intermittently connected) is to be very asynchronous: transaction commit only affects the local node, and conflict resolution is done when replicating changes later. This is more useful for filesystem replication: it is easier to do after-the-fact conflict resolution, although it is still very complex. ISTM it should be possible with DBMS replication, at least in theory. -Neil
In an attempt to throw the authorities off his trail, neilc@samurai.com (Neil Conway) transmitted: > William Yu wrote: >> Here's my question about "multi-master" replication whether it's >> Oracle or not. How in the world does it work over high latency, low >> bandwidth connections w/o getting pummelled in performance? > > Well, it may well be the case that it doesn't work :) Not all kinds of > replication are appropriate for all situations, and I agree that > synchronous, multi-master replication isn't likely to be useful in the > situation you describe. > > One solution to multi-master replication on slow networks (or networks > with nodes that are only intermittently connected) is to be very > asynchronous: transaction commit only affects the local node, and > conflict resolution is done when replicating changes later. This is > more useful for filesystem replication: it is easier to do > after-the-fact conflict resolution, although it is still very > complex. ISTM it should be possible with DBMS replication, at least in > theory. PeerDirect is marketing something that sounds like that... <http://www.peerdirect.com/products/data_replication_engine/index.ssp> This sort of "after the fact data synchronization with conflict resolution" bears marked similarities to: a) The way PalmOS systems address syncing between a handheld computer and potentially multiple desktop machines. It's often most convenient to cut'n'paste changes to things into one's "Palm Desktop" software because you have higher-bandwidth input devices like keyboards and mice as compared to scribbling with a stylus. I can make changes to data at home or at the office, and when I HotSync to my PDA, the data starts flowing towards those places it hasn't been yet... b) The way Lotus Notes(tm) allowed you to set up queues of messages. You could update/add material offline, and then "sync up" which would push/pull changes. Slony-I and Slony-II won't be doing that, which means that there's room for someone with interest to have a further usefully-distinct form of replication. -- let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;; http://linuxdatabases.info/info/slony.html "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle."
Neil, William, > One solution to multi-master replication on slow networks (or networks > with nodes that are only intermittently connected) is to be very > asynchronous: transaction commit only affects the local node, and > conflict resolution is done when replicating changes later. This is more > useful for filesystem replication: it is easier to do after-the-fact > conflict resolution, although it is still very complex. ISTM it should > be possible with DBMS replication, at least in theory. Actually, Sybase tackles this issue a different way .... one that, I may add, could be done with Slony-I with a little back-end glue. Basically, they make each replicated node the "master" of one subset of data; for example, if it's a personnel database, then all personnel records for each office location are "mastered" at that office location. If you're updating records at your current location (which is assumed to be the majority of updates) it goes in direct and cascades out to the other servers; if you update records for a different office, it goes to their server across the wire and cascades back to you asynchronously. Obviously, this only works for distributed applications where such partitioning of data is reasonable, but that actually covers a lot of real-world WAN distributed databases. Point-of-Sale, for example, as well as HR. -- Josh Berkus Aglio Database Solutions San Francisco
On Saturday 19 March 2005 13:13, Josh Berkus wrote:
> Neil, William,
> Actually, Sybase tackles this issue a different way .... one that, I may
> add, could be done with Slony-I with a little back-end glue. Basically,
> they make each replicated node the "master" of one subset of data; for
> example, if it's a personnel database, then all personnel records for each
> office location are "mastered" at that office location. If you're
> updating records at your current location (which is assumed to be the
> majority of updates) it goes in direct and cascades out to the other
> servers; if you update records for a different office, it goes to their
> server across the wire and cascades back to you asynchronously.
>
> Obviously, this only works for distributed applications where such
> partitioning of data is reasonable, but that actually covers a lot of
> real-world WAN distributed databases. Point-of-Sale, for example, as well
> as HR.
ISTR someone doing something like this with Slony... where they were doing all
inserts/updates to a local table that replicaed out to other offices but
using either a view that encapsulated all tables or using inheritence between
the local (child) table and a parent table (encapsulating all tables) to do
selects to see changes. I think this was an inventory system... anyone
remember for sure?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Fri, Mar 18, 2005 at 09:13:51PM -0800, William Yu wrote:
> Here's my question about "multi-master" replication whether it's Oracle
> or not. How in the world does it work over high latency, low bandwidth
> connections w/o getting pummelled in performance? I mean it's fine when
It doesn't. RAC is for one data centre only.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin