Re: 回复: [External] Re: Separate volumes

From: Erik Brandsberg <erik(at)heimdalldata(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Lu Dillon <ludi_1981(at)hotmail(dot)com>, Iuri Sampaio <iuri(dot)sampaio(at)gmail(dot)com>, Ed Behn <ed(dot)behn(at)collins(dot)com>, MichaelDBA <MichaelDBA(at)sqlexec(dot)com>, Steve Midgley <science(at)misuse(dot)org>, "pgsql-sql(at)lists(dot)postgresql(dot)org" <pgsql-sql(at)lists(dot)postgresql(dot)org>
Subject: Re: 回复: [External] Re: Separate volumes
Date: 2020-04-10 20:52:06
Message-ID: CAFcck8H1JfBE1sM98y1C+=Qfay4DayO-_gE_5hcjpX3_r4BmzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

A modern filesystem can help avoid even this complexity. As an example, I
am managing one PG setup that is self-hosted on an AWS EC2 instance, with
16TB of raw storage. The bulk of that storage is in ST1, or the cheapest
rotating disk capacity available in EBS, but is using ZFS as the filesystem
(with compression, so realistically about 35TB of raw data). The instance
type is a Z1d.metal, which has two 900GB NVME drives, which have been
divided to provide swap space, as well as ZFS read and write caching. This
setup has largely offset the slow performance of the st1 disks, and kept
the performance usable (most of the data is legacy, and rarely used). I'm
a big fan of keeping the DB configuration simple, as it is way too easy to
overlook tuning of a filespace for an index, causing performance problems,
while if you keep it auto-tuning at the filesystem level, it "just works".

Must my $.02

On Fri, Apr 10, 2020 at 4:04 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Tue, Apr 7, 2020 at 04:31:51PM +0000, Lu Dillon wrote:
> > Hi All,
> >
> > This is a very intersting question. I believe this is not just a best
> practice
> > to PG. We can apply to all RDBMS. In my opinion, I agree with the
> others: with
> > SSD, you don’t separate tables and indexs to different disks. I think
> the IOPS
> > is enough. If you still have a problem of IOPS, you can try NVME device
> or U2
> > device.
>
> If you are mixing magnetic and SSDs for the same database, having
> indexes on SSDs can really help, compared to table files on SSDs, where
> the benefit is more limited. Also, having current data on SSDs and
> archive data on magnetic is also useful, and you usually use
> time-based partitioning for such cases.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> + As you are, so once was I. As I am, so you will be. +
> + Ancient Roman grave inscription +
>

--
*Erik Brandsberg*
erik(at)heimdalldata(dot)com

www.heimdalldata.com
+1 (866) 433-2824 x 700
[image: AWS Competency Program]
<https://aws.amazon.com/partners/find/partnerdetails/?n=Heimdall%20Data&id=001E000001d9pndIAA>

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2020-04-10 21:01:54 Re: 回复: [External] Re: Separate volumes
Previous Message Bruce Momjian 2020-04-10 20:04:20 Re: 回复: [External] Re: Separate volumes