, phiên bản mới nhất của “cơ sở dữ liệu quan hệ nguồn mở tốt nhất thế giới” sẽ ra mắt sau vài tuần nữa (nếu mọi việc diễn ra theo đúng kế hoạch). Điều này tuân theo lịch trình thông thường là phát hành phiên bản mới với rất nhiều tính năng mới mỗi năm một lần và thành thật mà nói, điều đó thật ấn tượng. Đó là lý do tại sao tôi trở thành thành viên tích cực của cộng đồng PostgreSQL.
Theo tôi, không giống như các bản phát hành trước, PostgreSQL 12 không chứa một hoặc hai tính năng mang tính cách mạng (như phân vùng hoặc song song truy vấn). Tôi đã từng nói đùa rằng tính năng chính của PostgreSQL 12 là tính ổn định cao hơn. Đó không phải là những gì bạn cần khi quản lý dữ liệu quan trọng của doanh nghiệp mình sao?
Nhưng PostgreSQL 12 không dừng lại ở đó: với các tính năng và cải tiến mới, các ứng dụng sẽ hoạt động tốt hơn, và tất cả những gì bạn cần làm là nâng cấp!
(Chà, có thể xây dựng lại các chỉ mục, nhưng trong bản phát hành này, nó không còn đáng sợ như chúng ta thường thấy.)
Sẽ thật tuyệt vời khi nâng cấp PostgreSQL và ngay lập tức tận hưởng những cải tiến đáng kể mà không gặp rắc rối không cần thiết. Một vài năm trước, tôi đã xem xét bản nâng cấp từ PostgreSQL 9.4 lên PostgreSQL 10 và thấy ứng dụng đã tăng tốc như thế nào nhờ tính năng song song truy vấn được cải thiện trong PostgreSQL 10. Và quan trọng nhất, tôi hầu như không yêu cầu gì cả (chỉ cần đặt tham số cấu hình max_parallel_workers).
Đồng ý, thật tiện lợi khi ứng dụng hoạt động tốt hơn ngay sau khi nâng cấp. Và chúng tôi cố gắng hết sức để làm hài lòng người dùng, vì PostgreSQL ngày càng có nhiều người dùng hơn.
Vậy làm thế nào một bản nâng cấp đơn giản lên PostgreSQL 12 có thể khiến bạn hài lòng? Tôi sẽ kể cho bạn nghe bây giờ.
Cải tiến lập chỉ mục chính
Nếu không lập chỉ mục, cơ sở dữ liệu sẽ không đi xa được. Làm thế nào khác bạn có thể nhanh chóng tìm thấy thông tin? Hệ thống lập chỉ mục cơ bản của PostgreSQL được gọi là . Loại chỉ mục này được tối ưu hóa cho các hệ thống lưu trữ.
Chúng tôi chỉ đơn giản sử dụng toán tử CREATE INDEX ON some_table (some_column)và PostgreSQL thực hiện rất nhiều công việc để giữ cho chỉ mục được cập nhật trong khi chúng tôi liên tục chèn, cập nhật và xóa các giá trị. Mọi thứ đều tự hoạt động, như thể có phép thuật.
Nhưng các chỉ mục PostgreSQL có một vấn đề - chúng đồng thời chiếm thêm dung lượng ổ đĩa và giảm hiệu suất truy xuất và cập nhật dữ liệu. Khi nói "phình to", ý tôi là duy trì cấu trúc chỉ mục một cách không hiệu quả. Điều này có thể - hoặc có thể không - liên quan đến các bộ dữ liệu rác mà nó loại bỏ (cảm ơn Peter Gaghan vì thông tin))). Sự phình to chỉ số đặc biệt đáng chú ý trong khối lượng công việc mà chỉ số đang thay đổi tích cực.
PostgreSQL 12 cải thiện đáng kể hiệu suất của các chỉ mục cây B và các thử nghiệm với điểm chuẩn như TPC-C đã cho thấy rằng trung bình hiện nay dung lượng được sử dụng ít hơn 40%. Giờ đây, chúng ta dành ít thời gian hơn không chỉ cho việc duy trì các chỉ mục cây B (nghĩa là cho các thao tác ghi) mà còn cho việc truy xuất dữ liệu, vì các chỉ mục nhỏ hơn nhiều.
Các ứng dụng tích cực cập nhật bảng của chúng - điển hình là các ứng dụng OLTP () - sẽ sử dụng đĩa và xử lý các yêu cầu hiệu quả hơn nhiều. Càng nhiều dung lượng ổ đĩa, cơ sở dữ liệu càng có nhiều không gian để phát triển mà không cần nâng cấp cơ sở hạ tầng.
Một số chiến lược nâng cấp yêu cầu xây dựng lại chỉ mục cây B để tận dụng những lợi ích này (ví dụ: sẽ không tự động xây dựng lại các chỉ mục). Trong các phiên bản trước của PostgreSQL, việc xây dựng lại các chỉ mục lớn trên các bảng dẫn đến thời gian ngừng hoạt động đáng kể vì không thể thực hiện thay đổi trong thời gian chờ đợi. Nhưng PostgreSQL 12 còn có một tính năng thú vị khác: bây giờ bạn có thể xây dựng lại các chỉ mục song song với lệnh để tránh hoàn toàn thời gian chết.
Có những cải tiến khác đối với cơ sở hạ tầng lập chỉ mục trong PostgreSQL 12. Một điều nữa có phép thuật - , hay còn gọi là WAL (nhật ký ghi trước). Nhật ký ghi trước ghi lại mọi giao dịch trong PostgreSQL trong trường hợp xảy ra lỗi và sao chép. Các ứng dụng sử dụng nó để lưu trữ và . Tất nhiên, nhật ký ghi trước được ghi vào đĩa, điều này có thể ảnh hưởng đến hiệu suất.
PostgreSQL 12 đã giảm chi phí hoạt động của bản ghi WAL được tạo bởi các chỉ mục GiST, GIN và SP-GiST trong quá trình xây dựng chỉ mục. Điều này mang lại một số lợi ích hữu hình: Bản ghi WAL chiếm ít dung lượng đĩa hơn và dữ liệu được phát lại nhanh hơn, chẳng hạn như trong quá trình khắc phục thảm họa hoặc khôi phục tại thời điểm. Nếu bạn sử dụng các chỉ mục như vậy trong các ứng dụng của mình (ví dụ: các ứng dụng không gian địa lý dựa trên PostGIS sử dụng chỉ mục GiST rất nhiều), thì đây là một tính năng khác sẽ cải thiện đáng kể trải nghiệm mà không cần bất kỳ nỗ lực nào từ phía bạn.
Phân vùng - lớn hơn, tốt hơn, nhanh hơn
PostgreSQL 10 được giới thiệu . Trong PostgreSQL 11, nó đã trở nên dễ sử dụng hơn nhiều. Trong PostgreSQL 12 bạn có thể thay đổi tỷ lệ của các phần.
Trong PostgreSQL 12, hiệu suất của hệ thống phân vùng đã trở nên tốt hơn đáng kể, đặc biệt nếu có hàng nghìn phân vùng trong bảng. Ví dụ: nếu một truy vấn chỉ ảnh hưởng đến một vài phân vùng trong một bảng có hàng nghìn phân vùng như vậy thì truy vấn sẽ thực thi nhanh hơn nhiều. Hiệu suất không chỉ được cải thiện đối với các loại truy vấn này. Bạn cũng sẽ nhận thấy thao tác INSERT nhanh hơn như thế nào trên các bảng có nhiều phân vùng.
Ghi dữ liệu bằng cách sử dụng - Nhân tiện, đây là một cách tuyệt vời và đây là một ví dụ — các bảng được phân vùng trong PostgreSQL 12 cũng trở nên hiệu quả hơn. Với COPY, mọi thứ vốn đã nhanh chóng, nhưng trong PostgreSQL 12 thì nó hoàn toàn nhanh chóng.
Nhờ những ưu điểm này, PostgreSQL cho phép bạn lưu trữ các tập dữ liệu lớn hơn và giúp truy xuất chúng dễ dàng hơn. Và không có nỗ lực từ phía bạn. Nếu ứng dụng có nhiều phân vùng, chẳng hạn như ghi dữ liệu chuỗi thời gian, một bản nâng cấp đơn giản sẽ cải thiện đáng kể hiệu suất của ứng dụng.
Mặc dù đây không hẳn là một cải tiến "nâng cấp và tận hưởng", PostgreSQL 12 cho phép bạn tạo các khóa ngoại tham chiếu các bảng được phân vùng, khiến việc phân vùng trở nên thú vị khi làm việc.
VỚI các truy vấn đã tốt hơn rất nhiều
Khi (hay còn gọi là CTE, hay còn gọi là VỚI truy vấn), tôi nóng lòng muốn viết một bài báo về . Đây là một trong những tính năng sẽ tăng tốc ứng dụng. Tất nhiên trừ khi bạn sử dụng CTE.
Tôi thường thấy rằng những người mới làm quen với SQL thích sử dụng CTE; nếu bạn viết chúng theo một cách nhất định, bạn thực sự có cảm giác như đang viết một chương trình mệnh lệnh. Cá nhân tôi thích viết lại những truy vấn này để giải quyết mà không CTE và tăng năng suất. Bây giờ mọi thứ đã khác.
PostgreSQL 12 cho phép bạn nội tuyến một loại CTE cụ thể mà không có tác dụng phụ (SELECT), chỉ được sử dụng một lần ở gần cuối yêu cầu. Nếu tôi theo dõi các truy vấn CTE mà tôi đã viết lại, hầu hết chúng sẽ thuộc loại này. Điều này giúp các nhà phát triển viết mã rõ ràng và chạy nhanh chóng.
Hơn nữa, PostgreSQL 12 tự tối ưu hóa việc thực thi SQL mà bạn không cần phải làm gì cả. Và mặc dù bây giờ tôi có thể không cần tối ưu hóa các truy vấn như vậy, nhưng thật tuyệt khi PostgreSQL tiếp tục tối ưu hóa truy vấn.
Đúng lúc (JIT) - hiện là mặc định
Trên các hệ thống PostgreSQL 12 có hỗ trợ Trình biên dịch JIT được bật theo mặc định. Trước hết, bạn nhận được sự hỗ trợ đối với một số thao tác nội bộ và thứ hai, các truy vấn có biểu thức (ví dụ đơn giản nhất là x + y) trong danh sách chọn (mà bạn có sau SELECT), tổng hợp, biểu thức với mệnh đề WHERE và các truy vấn khác có thể sử dụng JIT để cải thiện hiệu suất.
Vì JIT được bật theo mặc định trong PostgreSQL 12 nên hiệu suất sẽ tự cải thiện, nhưng tôi khuyên bạn nên thử nghiệm ứng dụng trong PostgreSQL 11, phiên bản đã giới thiệu JIT, để đo hiệu suất truy vấn và xem liệu bạn có cần điều chỉnh gì không.
Còn những tính năng mới còn lại trong PostgreSQL 12 thì sao?
PostgreSQL 12 có rất nhiều tính năng mới thú vị, từ khả năng kiểm tra dữ liệu JSON bằng cách sử dụng các biểu thức định tuyến SQL/JSON tiêu chuẩn cho đến xác thực đa yếu tố bằng một tham số clientcert=verify-full, tạo cột và hơn thế nữa. Đủ cho một bài viết riêng biệt.
Giống như PostgreSQL 10, PostgreSQL 12 sẽ cải thiện hiệu suất tổng thể ngay sau khi nâng cấp. Tất nhiên, bạn có thể có con đường riêng của mình - kiểm tra ứng dụng trong các điều kiện tương tự trên hệ thống sản xuất trước khi kích hoạt các cải tiến, như tôi đã làm với PostgreSQL 10. Ngay cả khi PostgreSQL 12 đã ổn định hơn tôi mong đợi, đừng lười biếng thử nghiệm ứng dụng một cách kỹ lưỡng trước khi phát hành chúng vào sản xuất.
Nguồn: www.habr.com