Re: 回复: [External] Re: Separate volumes - Mailing list 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@momjian.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@momjian.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
+1 (866) 433-2824 x 700
