|
|
 | | From: | Richard_D_Levine at raytheon.com | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 10:42:27 -0500 |
|
|
 | --0__=8ABBE51CDFC59A338f9e8a93df938690918c8ABBE51CDFC59A33
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
I think maybe a SAN in conjunction with tablespaces might be the answer.
Still need one honking server.
Rick
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
Stephen Frost=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
To: Christop=
her Kings-Lynne =20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20
Sent by: cc: Herv=E9 =
Piedvache , pgsql-performance@postgresql.org=20=20=20=20=20=
=20=20=20
pgsql-performance-owner@pos Subject: Re: [PER=
FORM] PostgreSQL clustering VS MySQL clustering=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
tgresql.org=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
01/20/2005 10:08 AM=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
* Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:
> PostgreSQL has replication, but not partitioning (which is what you
want).
It doesn't have multi-server partitioning.. It's got partitioning
within a single server (doesn't it? I thought it did, I know it was
discussed w/ the guy from Cox Communications and I thought he was using
it :).
> So, your only option is Oracle or another very expensive commercial
> database.
Or partition the data at the application layer.
Stephen
(See attached file: signature.asc)
--0__=8ABBE51CDFC59A338f9e8a93df938690918c8ABBE51CDFC59A33
Content-type: application/octet-stream;
name="=?ISO-8859-1?Q?signature=2Easc?="
Content-Disposition: attachment; filename="=?ISO-8859-1?Q?signature=2Easc?="
Content-transfer-encoding: base64
LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBH
IHYxLjIuNSAoR05VL0xpbnV4KQ0KDQppRDhEQlFGQjc4bC9yemdNUHFCM2tp
Z1JBa05rQUowV0RCcTZ6Tno5Q0FsLzJBZW1YQkJza3FzWDFRQ2dsSFowDQp2
OHNwVnBTeXl2WHEwbDV5Vitub0ovMD0NCj1DQTFvDQotLS0tLUVORCBQR1Ag
U0lHTkFUVVJFLS0tLS0NCg==
--0__=8ABBE51CDFC59A338f9e8a93df938690918c8ABBE51CDFC59A33
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--0__=8ABBE51CDFC59A338f9e8a93df938690918c8ABBE51CDFC59A33--
|
|
| | From: | Stephen Frost | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 11:13:25 -0500 |
|
|
|
--aUZUxHew3C+tqlLv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
* Richard_D_Levine@raytheon.com (Richard_D_Levine@raytheon.com) wrote:
> I think maybe a SAN in conjunction with tablespaces might be the answer.
> Still need one honking server.
That's interesting- can a PostgreSQL partition be acress multiple
tablespaces?
Stephen
--aUZUxHew3C+tqlLv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFB79ilrzgMPqB3kigRAk1bAKCIA2wpbjLYTLy27jAv7rYI3RTyjwCdHn2s
uqALSHXbE/WNAnQ1UzvawcM=
=vfkW
-----END PGP SIGNATURE-----
--aUZUxHew3C+tqlLv--
|
|
| | From: | Alex Turner | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Thu, 20 Jan 2005 12:23:12 -0500 |
|
|
| The problem is very large ammounts of data that needs to be both read
and updated. If you replicate a system, you will need to
intelligently route the reads to the server that has the data in RAM
or you will always be hitting DIsk which is slow. This kind of routing
AFAIK is not possible with current database technology, and you are
still stuck for writes.
Writes are always going to be the bane of any cluster. Clustering can
give better parallel read performance i.e. large no. of clients
accessing data simultaneously, but your write performance is always
going to be bound by the underlying disk infrastructure, not even
Oracle RAC can get around this (It uses multiple read nodes accessing
the same set of database files underneath)
Google solved the problem by building this intelligence into the
middle tier, and using a distributed file system. Java Entity Beans
are supposed to solve this problem somewhat by distributing the data
across multiple servers in a cluster and allowing you to defer write
syncing, but it really doesn't work all that well.
The only way I know to solve this at the RDBMS layer is to configure a
very powerfull disk layer, which is basicaly going to a SAN mesh with
multiple cards on a single system with multiple IO boards, or an OS
that clusters at the base level, thinking HP Superdome or z900. Even
Opteron w/PCI-X cards has a limit of about 400MB/sec throughput on a
single IO channel, and there are only two independent channels on any
boards I know about.
The other solution is to do what google did. Implement your own
middle tier that knows how to route queries to the appropriate place.
Each node can then have it's own independant database with it's own
independant disk subsystem, and your throughput is only limited by
your network interconnects, and your internet pipe. This kind of
middle tier is really not that hard to if your data can easily be
segmented. Each node runs it's own query sort and filter
independantly, and supplies the result to the central data broker,
which then collates the results and supplies them back to the user.
Updated work in a similar fasion. The update comes into the central
broker that decides which nodes it will affect, and then issues
updates to those nodes.
I've built this kind of architecture, if you want to do it, don't use
Java unless you want to pay top dollar for your programmers, because
it's hard to make it work well in Java (most JMS implementations suck,
look at MQueue or a custom queue impl, forget XML it's too slow to
serialize and deserialize requests).
Alex Turner
NetEconomist
On Thu, 20 Jan 2005 11:13:25 -0500, Stephen Frost wrote:
> * Richard_D_Levine@raytheon.com (Richard_D_Levine@raytheon.com) wrote:
> > I think maybe a SAN in conjunction with tablespaces might be the answer.
> > Still need one honking server.
>
> That's interesting- can a PostgreSQL partition be acress multiple
> tablespaces?
>
> Stephen
>
>
>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
|
