PostgreSQL và khái niệm everything, everywhere

1351
14-11-2024
PostgreSQL và khái niệm everything, everywhere

PostgreSQL là một trong những cơ sở dữ liệu SQL phổ biến nhất, thường được lựa chọn cho các hệ thống xử lý giao dịch trực tuyến (OLTP). Tuy nhiên, PostgreSQL còn linh hoạt hơn thế, có khả năng xử lý hiệu quả các kịch bản SQL ít phổ biến và thậm chí cả các quy trình làm việc không sử dụng SQL.

PostgreSQL là một trong những cơ sở dữ liệu SQL phổ biến nhất. Nó là cơ sở dữ liệu được nhiều dự án lựa chọn khi xử lý các hệ thống OLTP. Tuy nhiên, PostgreSQL linh hoạt hơn nhiều và có thể xử lý thành công các kịch bản SQL ít phổ biến hơn và các quy trình làm việc hoàn toàn không sử dụng SQL. Trong bài đăng trên blog này, chúng ta sẽ xem xét các kịch bản khác mà PostgreSQL tỏa sáng và sẽ giải thích cách sử dụng nó trong những trường hợp này.

Khởi đầu của PostgreSQL

Về mặt lịch sử, chúng ta tập trung vào hai quy trình làm việc cơ sở dữ liệu riêng biệt: Xử lý giao dịch trực tuyến (OLTP) và Xử lý phân tích trực tuyến (OLAP).

OLTP đại diện cho các ứng dụng hàng ngày mà chúng ta sử dụng để tạo, đọc, cập nhật và xóa (CRUD) dữ liệu. Các giao dịch ngắn và chỉ chạm vào một tập hợp con của các thực thể cùng một lúc, và chúng ta muốn thực hiện tất cả các giao dịch này đồng thời và song song. Chúng ta hướng tới độ trễ thấp nhất và thông lượng cao nhất vì chúng ta cần thực hiện hàng nghìn giao dịch mỗi giây.

OLAP tập trung vào xử lý phân tích. Thông thường sau khi kết thúc một ngày, chúng ta muốn tính toán lại nhiều tập hợp đại diện cho dữ liệu kinh doanh của mình. Chúng ta tổng kết dòng tiền, tính toán lại sở thích của người dùng hoặc chuẩn bị báo cáo. Tương tự, sau mỗi tháng, quý hoặc năm, chúng ta cần xây dựng các bản tóm tắt hiệu suất kinh doanh và hiển thị chúng bằng bảng điều khiển. Những quy trình làm việc này hoàn toàn khác với quy trình OLTP, vì OLAP chạm đến nhiều (có thể là tất cả) thực thể hơn, tính toán các tập hợp phức tạp và chạy các giao dịch một lần. Chúng ta hướng tới độ tin cậy thay vì hiệu suất vì các truy vấn có thể mất nhiều thời gian hơn để hoàn thành (như hàng giờ hoặc thậm chí hàng ngày) nhưng không nên thất bại vì chúng ta sẽ cần phải bắt đầu lại từ đầu. Chúng ta thậm chí đã nghĩ ra các quy trình làm việc phức tạp được gọi là Trích xuất-Chuyển đổi-Tải (ETL) hỗ trợ toàn bộ quá trình chuẩn bị xử lý dữ liệu để thu thập dữ liệu từ nhiều nguồn, chuyển đổi nó thành các lược đồ chung và tải nó vào kho dữ liệu. Các truy vấn OLAP thường không can thiệp vào các truy vấn OLTP vì chúng chạy trong một cơ sở dữ liệu khác.

Sự đa dạng của các quy trình làm việc hiện nay

Thế giới đã thay đổi đáng kể trong thập kỷ qua. Một mặt, chúng ta đã cải thiện rất nhiều các giải pháp OLAP của mình bằng cách liên quan đến dữ liệu lớn, hồ dữ liệu, xử lý song song (như với Spark) hoặc các giải pháp mã thấp để xây dựng trí tuệ doanh nghiệp. Mặt khác, các giao dịch OLTP trở nên phức tạp hơn, dữ liệu ít quan hệ hơn và cơ sở hạ tầng lưu trữ đã thay đổi đáng kể.

Ngày nay, việc sử dụng một cơ sở dữ liệu cho cả quy trình làm việc OLTP và OLAP không phải là hiếm. Cách tiếp cận như vậy được gọi là Xử lý giao dịch/phân tích lai (HTAP). Chúng ta có thể muốn tránh sao chép dữ liệu giữa các cơ sở dữ liệu để tiết kiệm thời gian hoặc chúng ta có thể cần chạy các truy vấn phức tạp hơn thường xuyên (như cứ sau 15 phút). Trong những trường hợp này, chúng ta muốn thực hiện tất cả các quy trình làm việc trong một cơ sở dữ liệu thay vì trích xuất dữ liệu ở một nơi khác để chạy phân tích. Điều này có thể dễ dàng làm quá tải cơ sở dữ liệu vì các giao dịch OLAP có thể khóa các bảng lâu hơn nhiều, điều này sẽ làm chậm đáng kể các giao dịch OLTP.

Tuy nhiên, một sự phát triển khác nằm trong lĩnh vực dữ liệu mà chúng ta xử lý. Chúng ta thường xử lý văn bản, dữ liệu phi quan hệ như JSON hoặc XML, dữ liệu học máy như nhúng, dữ liệu không gian hoặc dữ liệu chuỗi thời gian. Thế giới ngày nay thường là phi SQL.

Cuối cùng, chúng ta cũng đã thay đổi những gì chúng ta làm. Chúng ta không tính toán các tập hợp nữa. Chúng ta thường cần tìm các tài liệu tương tự, đào tạo các mô hình ngôn ngữ lớn hoặc xử lý hàng triệu số liệu từ các thiết bị Internet vạn vật (IoT).

May mắn thay, PostgreSQL rất dễ mở rộng và có thể dễ dàng đáp ứng các quy trình làm việc này. Cho dù chúng ta xử lý các bảng quan hệ hay các cấu trúc phức tạp, PostgreSQL đều cung cấp nhiều tiện ích mở rộng có thể cải thiện hiệu suất của quá trình xử lý. Hãy xem xét các quy trình làm việc này và hiểu cách PostgreSQL có thể giúp ích.

Dữ liệu phi quan hệ

PostgreSQL có thể lưu trữ nhiều loại dữ liệu khác nhau. Ngoài các số hoặc văn bản thông thường, chúng ta có thể muốn lưu trữ các cấu trúc lồng nhau, dữ liệu không gian hoặc các công thức toán học. Việc truy vấn dữ liệu như vậy có thể chậm hơn đáng kể nếu không có các cấu trúc dữ liệu chuyên biệt hiểu được nội dung của các cột. May mắn thay, PostgreSQL hỗ trợ nhiều tiện ích mở rộng và công nghệ để xử lý dữ liệu phi quan hệ.

XML

PostgreSQL hỗ trợ dữ liệu XML nhờ kiểu xml tích hợp của nó. Kiểu này có thể lưu trữ cả tài liệu được định dạng tốt (được xác định bởi tiêu chuẩn XML) hoặc các nút của tài liệu chỉ đại diện cho một phần nội dung. Sau đó, chúng ta có thể trích xuất các phần của tài liệu, tạo tài liệu mới và tìm kiếm dữ liệu một cách hiệu quả.

Để tạo tài liệu, chúng ta có thể sử dụng hàm XMLPARSE hoặc cú pháp độc quyền của PostgreSQL:

CREATE TABLE test (

id integer NOT NULL,

xml_data xml NOT NULL,

CONSTRAINT test_pkey PRIMARY KEY (id)

);

INSERT INTO test VALUES (1, XMLPARSE(DOCUMENT '<?xml version="1.0"?><book><title>Some tittle</title><length>123</length></book>'));

INSERT INTO test VALUES (2, XMLPARSE(CONTENT '<?xml version="1.0"?><book><title>Some title 2</title><length>456</length></book>'));

INSERT INTO test VALUES (3, xml '<?xml version="1.0"?><book><title>Some title 3</title><length>789</length></book>'::xml);

Chúng ta cũng có thể tuần tự hóa dữ liệu dưới dạng XML bằng XMLSERIALIZE:

SELECT XMLSERIALIZE(DOCUMENT '<?xml version="1.0"?><book><title>Some title</title></book>' AS text);

Nhiều hàm tạo ra XML. xmlagg tạo tài liệu từ các giá trị được trích xuất từ bảng:

SELECT xmlagg(xml_data) FROM test;

xmlagg

<book><title>Some title</title><length>123</length></book><book><title>Some title 2</title><length>456</length></book><book><title>Some title 3</title><length>789</length></book>

Chúng ta có thể sử dụng xmlpath để trích xuất bất kỳ thuộc tính nào từ các nút đã cho:

SELECT xpath('/book/length/text()', xml_data) FROM test;
xpath 123 456 789

Chúng ta có thể sử dụng table_to_xml để xuất toàn bộ bảng sang XML:

SELECT table_to_xml('test', true, false, '');

table_to_xml

<test xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance""><row> <id>1</id><_x0078_ml_data><book><title>Some title</title><length>123</length></book></_x0078_ml_data></row><row> <id>2</id><_x0078_ml_data><book><title>Some title 2</title><length>456</length></book></_x0078_ml_data></row><row> <id>3</id><_x0078_ml_data><book><title>Some title 3</title><length>789</length></book></_x0078_ml_data></row></test>

Kiểu dữ liệu xml không cung cấp bất kỳ toán tử so sánh nào. Để tạo chỉ mục, chúng ta cần chuyển đổi các giá trị thành văn bản hoặc thứ gì đó tương đương và chúng ta có thể sử dụng cách tiếp cận này với nhiều kiểu chỉ mục. Ví dụ: đây là cách chúng ta có thể tạo chỉ mục B-tree:


                                  
SHARE