Thread: Scalability (both vertical and horizontal)?
We are looking for information regarding any capabilities of PostgreSQL in regards to scalability. Ideally we want to beable to scale in both directions. What sort of solutions are out there for either or both directions of scalability? Specifically,open-source solutions would be most in need, but commercial applications are fine as well. Thank you. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.501 / Virus Database: 299 - Release Date: 7/14/2003 *************************************************************************** "The information contained in this e-mail message may be confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at exadmins@marketron.com." ***************************************************************************
On Thu, 18 Sep 2003, Duffey, Kevin wrote: > We are looking for information regarding any capabilities of PostgreSQL > in regards to scalability. Ideally we want to be able to scale in both > directions. What sort of solutions are out there for either or both > directions of scalability? Specifically, open-source solutions would be > most in need, but commercial applications are fine as well. The most important resource as regards vertical scalability is probably the performance mailing list. I.e. Postgresql can already take advantage of multiple processors and spare memory and fast I/O subsystems, but things like 64 way Sun E10ks are not commonly tested with Postgresql, so if you're the first guy on the block to buy one, you might find some issues that need ironing out with that large of a piece of iron. As for horizontal scaling, you could look at ERserver for that. Setup one master writer and a bunch of slave boxes to handle the majority of the queries. There's not been a bunch of work into horizontal scaling really, with most of the clustering software for postgresql aiming at failover / high availability, not massive parallelization of read and / or writes.
scott.marlowe wrote: >On Thu, 18 Sep 2003, Duffey, Kevin wrote: > > > >>We are looking for information regarding any capabilities of PostgreSQL >>in regards to scalability. Ideally we want to be able to scale in both >>directions. What sort of solutions are out there for either or both >>directions of scalability? Specifically, open-source solutions would be >>most in need, but commercial applications are fine as well. >> >> > >As for horizontal scaling, you could look at ERserver for that. Setup one >master writer and a bunch of slave boxes to handle the majority of the >queries. There's not been a bunch of work into horizontal scaling really, >with most of the clustering software for postgresql aiming at failover / >high availability, not massive parallelization of read and / or writes. > Are there any databases that do well in horizontal scaling? What really *IS* Oracle Real Application Clusters?
On Thu, 18 Sep 2003, Dennis Gearon wrote: > scott.marlowe wrote: > > >On Thu, 18 Sep 2003, Duffey, Kevin wrote: > > > > > > > >>We are looking for information regarding any capabilities of PostgreSQL > >>in regards to scalability. Ideally we want to be able to scale in both > >>directions. What sort of solutions are out there for either or both > >>directions of scalability? Specifically, open-source solutions would be > >>most in need, but commercial applications are fine as well. > >> > >> > > > >As for horizontal scaling, you could look at ERserver for that. Setup one > >master writer and a bunch of slave boxes to handle the majority of the > >queries. There's not been a bunch of work into horizontal scaling really, > >with most of the clustering software for postgresql aiming at failover / > >high availability, not massive parallelization of read and / or writes. > > > Are there any databases that do well in horizontal scaling? What really > *IS* Oracle Real Application Clusters? I've heard Vax Clusters running RDB do well. TPF on a mainframe is highly recommended by Sabre, the Airline reservation folks. I've heard horror stories about RAC though. I don't think there's anysuch thing as an easily configurable high performance clustering solution. The better the run the more infrastructure (hardware, software, support) they seem to need.
Boy, after doing some reading on the net, VAX was WAY ahead of it's time, like someone else has said. No wonder they did so well back then. It'd be nice to get that kind of stuff going on newer products using fibre channel or that other new, fiber interface. OpenVAX, ...... does that mean the source code is open? scott.marlowe wrote: >On Thu, 18 Sep 2003, Dennis Gearon wrote: > > > >>scott.marlowe wrote: >> >> >> >>>On Thu, 18 Sep 2003, Duffey, Kevin wrote: >>> >>> >>> >>> >>> >>>>We are looking for information regarding any capabilities of PostgreSQL >>>>in regards to scalability. Ideally we want to be able to scale in both >>>>directions. What sort of solutions are out there for either or both >>>>directions of scalability? Specifically, open-source solutions would be >>>>most in need, but commercial applications are fine as well. >>>> >>>> >>>> >>>> >>>As for horizontal scaling, you could look at ERserver for that. Setup one >>>master writer and a bunch of slave boxes to handle the majority of the >>>queries. There's not been a bunch of work into horizontal scaling really, >>>with most of the clustering software for postgresql aiming at failover / >>>high availability, not massive parallelization of read and / or writes. >>> >>> >>> >>Are there any databases that do well in horizontal scaling? What really >>*IS* Oracle Real Application Clusters? >> >> > >I've heard Vax Clusters running RDB do well. > >TPF on a mainframe is highly recommended by Sabre, the Airline reservation >folks. > >I've heard horror stories about RAC though. > >I don't think there's anysuch thing as an easily configurable high >performance clustering solution. The better the run the more >infrastructure (hardware, software, support) they seem to need. > > >---------------------------(end of broadcast)--------------------------- >TIP 8: explain analyze is your friend > > >
On Thu, 2003-09-18 at 16:32, scott.marlowe wrote: > On Thu, 18 Sep 2003, Dennis Gearon wrote: > > > scott.marlowe wrote: > > > > >On Thu, 18 Sep 2003, Duffey, Kevin wrote: [snip] > > Are there any databases that do well in horizontal scaling? What really > > *IS* Oracle Real Application Clusters? DECpaq ported VMSclusters to Tru64. Oracle then licensed that and built it into RAC. > I've heard Vax Clusters running RDB do well. It's seamless and extremely simple. On each node that you want the database open, you run the command: $RMU/OPEN <yourdatabase> The "root file" knows what transactions are open on each node, so if node FOO crashes, the MONITOR picks another node to apply the RECOVERY UNIT JOURNAL files from the transactions that were open on FOO when it crashed. (RDB doesn't use MVCC, so it keeps an RUJ file for each process, that has the "before images" of all table & index tuples involved in transactions. If the txn commits successfully, the file is zeroed out, but if it must be rolled back, the data is read back from the RUJ and applied back to the appropriate tablespace pages.) > TPF on a mainframe is highly recommended by Sabre, the Airline reservation > folks. > > I've heard horror stories about RAC though. > > I don't think there's anysuch thing as an easily configurable high > performance clustering solution. The better the run the more > infrastructure (hardware, software, support) they seem to need. VMSclusters are very easy to support, but the speed problem is there. It's just so much faster to from CPU0 to CPU15 in a 16x SMP or NUMA box, than it is between nodes is a 4x cluster of 4x SMP boxes. Also, you need so much extra *expensive* "stuff" to connect a bunch of boxen with dual-redundancy in a high-speed cluster. Database replication to a remote site that has a "smaller" box is usually a cheaper solution nowadays, since the remote box can still be used as a report engine. A recent development is "in-box clustering". Recent large Alpha systems (along with recent versions of VMS) allow for h/w partition- ing (like mainframes have done for, what, 20 years?, and Sun does with the Starfire). Thus, you can take a 16x machine and divvie it up into 4 nodes. The cool part is that inter-node chatter takes place at "in-box" speeds, instead of a wire speeds. So, you could have nodes dedicated to batch jobs, on-line access, etc. On-line on-the-fly re-partitioning allows you to take CPUs from underutilized nodes and allocate them to overtaxed nodes. Of course, RDB doesn't need a clue about this; it just runs. -- ----------------------------------------------------------------- Ron Johnson, Jr. ron.l.johnson@cox.net Jefferson, LA USA "What other evidence do you have that they are terrorists, other than that they trained in these camps?" 17-Sep-2002 Katie Couric to an FBI agent regarding the 5 men arrested near Buffalo NY
On Thu, 2003-09-18 at 16:54, Dennis Gearon wrote: > Boy, after doing some reading on the net, VAX was WAY ahead of it's > time, like someone else has said. No wonder they did so well back then. > > It'd be nice to get that kind of stuff going on newer products using > fibre channel or that other new, fiber interface. VMSclusters (the name was changed 10 years ago) can interconnect via fiber. > OpenVAX, ...... does that mean the source code is open? The Open in OpenVMS means that it has all the standard Posix & X Window API calls. There's no such thing as OpenVAX, since VAX is a hardware archi- tecture. BTW, VMS has already booted on Itanium, and when it ships early next year, you'll be able to have tri-arch VMSclusters: VAX/VMS, Alpha/VMS & Itaniac/VMS all accessing & sharing the same files simultaneously. > scott.marlowe wrote: > > >On Thu, 18 Sep 2003, Dennis Gearon wrote: > > > > > > > >>scott.marlowe wrote: > >> > >> > >> > >>>On Thu, 18 Sep 2003, Duffey, Kevin wrote: > >>> > >>> > >>> > >>> > >>> > >>>>We are looking for information regarding any capabilities of PostgreSQL > >>>>in regards to scalability. Ideally we want to be able to scale in both > >>>>directions. What sort of solutions are out there for either or both > >>>>directions of scalability? Specifically, open-source solutions would be > >>>>most in need, but commercial applications are fine as well. > >>>> > >>>> > >>>> > >>>> > >>>As for horizontal scaling, you could look at ERserver for that. Setup one > >>>master writer and a bunch of slave boxes to handle the majority of the > >>>queries. There's not been a bunch of work into horizontal scaling really, > >>>with most of the clustering software for postgresql aiming at failover / > >>>high availability, not massive parallelization of read and / or writes. > >>> > >>> > >>> > >>Are there any databases that do well in horizontal scaling? What really > >>*IS* Oracle Real Application Clusters? > >> > >> > > > >I've heard Vax Clusters running RDB do well. > > > >TPF on a mainframe is highly recommended by Sabre, the Airline reservation > >folks. > > > >I've heard horror stories about RAC though. > > > >I don't think there's anysuch thing as an easily configurable high > >performance clustering solution. The better the run the more > >infrastructure (hardware, software, support) they seem to need. > > > > > >---------------------------(end of broadcast)--------------------------- > >TIP 8: explain analyze is your friend > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- ----------------------------------------------------------------- Ron Johnson, Jr. ron.l.johnson@cox.net Jefferson, LA USA Some former UNSCOM officials are alarmed, however. Terry Taylor, a British senior UNSCOM inspector from 1993 to 1997, says the figure of 95 percent disarmament is "complete nonsense because inspectors never learned what 100 percent was. UNSCOM found a great deal and destroyed a great deal, but we knew [Iraq's] work was continuing while we were there, and I'm sure it continues," says Mr. Taylor, now head of the Washington http://www.csmonitor.com/2002/0829/p01s03-wosc.html
scott.marlowe@ihs.com ("scott.marlowe") writes:
> TPF on a mainframe is highly recommended by Sabre, the Airline
> reservation folks.
Sure, but they have 17 mainframes in the "bunker" in Tulsa. And that
seems more reflective of having Really Really Really Big Iron (the big
boxes are BIG BOXES) than of it scaling across a bunch of cheaper
hardware. Parts of that are multihosting applications; quite a number
of those MFs are probably devoted to running the information systems
for AMR.
(I used to do work on some of the AMR-oriented MFs; mostly indirectly,
from the Unix side...)
Furthermore, a vast number of the projects since STIN was initially
created at Sabre have been directed at replacing it. None have been
notably successful. It looks a whole lot more like vertical scaling
("the biggest box with the mostest spindles and the mostest terminal
interfaces") than anything else...
--
output = reverse("ofni.smrytrebil" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
On Thu, 18 Sep 2003, Christopher Browne wrote:
> scott.marlowe@ihs.com ("scott.marlowe") writes:
> > TPF on a mainframe is highly recommended by Sabre, the Airline
> > reservation folks.
>
> Sure, but they have 17 mainframes in the "bunker" in Tulsa. And that
> seems more reflective of having Really Really Really Big Iron (the big
> boxes are BIG BOXES) than of it scaling across a bunch of cheaper
> hardware. Parts of that are multihosting applications; quite a number
> of those MFs are probably devoted to running the information systems
> for AMR.
The last time I had dinner with some of the folks from Sabre, I was told
that 12 mainframes were running the tpf, with 6 online and 6 in a failover
/ sysplex mode I'm note that familiar with. I.e. they had it spread
across 6 machines. I'd say that's wide and tall.
> Furthermore, a vast number of the projects since STIN was initially
> created at Sabre have been directed at replacing it. None have been
> notably successful.
Same story I heard :-)
> It looks a whole lot more like vertical scaling
> ("the biggest box with the mostest spindles and the mostest terminal
> interfaces") than anything else...
If they had TPF on one mainframe with a failover, I'd agree, but like I
said above, it looks both wide AND tall scaling.
either way, it makes my poor little dual PIV 2800 machines seem puny by
comparison. :-)