Có gì mới trong Postgres-XL 9.6

Trong vài tháng qua, chúng tôi tại 2ndQuadrant đã làm việc để hợp nhất PostgreSQL 9.6 vào Postgres-XL, điều này hóa ra khá khó khăn vì nhiều lý do và mất nhiều thời gian hơn so với kế hoạch ban đầu do một số thay đổi ngược dòng xâm lấn. Nếu bạn quan tâm, hãy xem kho lưu trữ chính thức tại đây (xem chi nhánh "chính" ngay bây giờ).

Vẫn còn khá nhiều việc phải làm - hợp nhất một số bit còn lại từ ngược dòng, sửa các lỗi đã biết và lỗi hồi quy, thử nghiệm, v.v. Nếu bạn đang cân nhắc đóng góp cho Postgres-XL, đây là một cơ hội lý tưởng (gửi cho tôi e-mail và tôi sẽ giúp bạn những bước đầu tiên).

Nhưng nhìn chung, Postgres-XL 9.6 rõ ràng là một bước tiến lớn trong một số lĩnh vực quan trọng.

Các tính năng mới trong Postgres-XL 9.6

Vì vậy, Postgres-XL có được những tính năng mới nào từ sự hợp nhất PostgreSQL 9.6? Tôi chỉ có thể hướng dẫn bạn đến các ghi chú phát hành ngược dòng - hầu hết các cải tiến áp dụng trực tiếp cho XL 9.6, ngoại trừ những cải tiến liên quan đến các tính năng không được hỗ trợ trên XL.

Cải tiến chính mà người dùng có thể nhìn thấy trong PostgreSQL 9.6 là truy vấn song song rõ ràng và điều đó cũng áp dụng cho Postgres-XL 9.6.

Song song trong nút

Trước PostgreSQL 9.6, Postgres-XL là một trong những cách để nhận các truy vấn song song (bằng cách đặt nhiều nút Postgres-XL trên cùng một máy). Vì PostgreSQL 9.6 không còn cần thiết nữa, nhưng điều đó cũng có nghĩa là Postgres-XL có được khả năng xử lý song song nội bộ nút.

Để so sánh, đây là những gì Postgres-XL 9.5 cho phép bạn làm - phân phối một truy vấn đến nhiều nút dữ liệu, nhưng mỗi nút dữ liệu vẫn phải chịu giới hạn "một phụ trợ cho mỗi truy vấn", giống như PostgreSQL thuần túy.

Nhờ tính năng truy vấn song song PostgreSQL 9.6, Postgres-XL 9.6 hiện có thể thực hiện điều này:

Nghĩa là, mỗi nút dữ liệu hiện có thể chạy song song một phần của truy vấn, sử dụng cơ sở hạ tầng truy vấn song song ngược dòng. Điều đó thật tuyệt và làm cho Postgres-XL trở nên mạnh mẽ hơn nhiều khi nói đến khối lượng công việc phân tích.

Duy trì một ngã ba

Tôi đã đề cập rằng việc hợp nhất này hóa ra có nhiều thách thức hơn chúng tôi mong đợi ban đầu, vì một số lý do.

Thứ nhất, việc duy trì các nhánh nói chung là khó, đặc biệt khi dự án ngược dòng đang di chuyển nhanh như PostgreSQL. Bạn cần phát triển các tính năng cụ thể cho fork của mình, đó là lý do tại sao fork tồn tại ngay từ đầu. Nhưng bạn cũng muốn theo kịp ngược dòng, nếu không bạn sẽ bị tụt lại phía sau một cách vô vọng. Đó là lý do tại sao một số nhánh hiện có vẫn bị mắc kẹt trên PostgreSQL 8.x, thiếu tất cả các tính năng được cam kết kể từ đó.

Thứ hai, việc hợp nhất được thực hiện trong một khối lớn, giống như tất cả những lần trước (9.5, 9.2,…). Đó là, tất cả các cam kết ngược dòng đã được hợp nhất trong một lệnh hợp nhất git duy nhất. Điều đó được đảm bảo là có thể gây ra nhiều xung đột hợp nhất, đến mức mã thậm chí không biên dịch được, chưa kể đến việc chạy kiểm tra hồi quy hoặc bất cứ điều gì tương tự.

Vì vậy, loạt sửa lỗi đầu tiên là về việc đưa nó vào trạng thái có thể biên dịch được, loạt tiếp theo là về việc làm cho nó thực sự chạy mà không có giá trị mặc định ngay lập tức, và cuối cùng là sửa lỗi "thông thường" bắt đầu (chạy kiểm tra hồi quy, khắc phục sự cố, rửa sạch và lặp lại) .

Những phức tạp này vốn có đối với việc bảo trì fork (và là lý do tại sao bạn có thể nên cân nhắc lại việc bắt đầu một đợt fork khác và thay vào đó đóng góp trực tiếp vào Postgres và / hoặc Postgres-XL).

Nhưng có những cách để giảm đáng kể tác động - ví dụ như chúng tôi dự định thực hiện hợp nhất tiếp theo (với PostgreSQL 10) trong các phần nhỏ hơn. Điều đó sẽ giảm thiểu mức độ xung đột hợp nhất và cho phép chúng tôi giải quyết các lỗi nhanh hơn nhiều.

Gần hơn với PostgreSQL

Điều thú vị là, việc áp dụng song song từ phía trên cũng cho phép chúng tôi loại bỏ rất nhiều mã khỏi cơ sở mã XL - một ví dụ điển hình về điều này là mã tổng hợp song song, dễ dàng thay thế mã dành riêng cho XL.

Một ví dụ khác về sự thay đổi ngược dòng ảnh hưởng đáng kể đến mã XL là “pathification” của nhà lập kế hoạch cấp trên, bị đẩy muộn trong chu kỳ phát triển 9.6. Điều này hóa ra là một thay đổi rất xâm lấn (trên thực tế, một số lỗi mở có thể liên quan đến nó), nhưng cuối cùng nó cho phép chúng tôi đơn giản hóa mã lập kế hoạch (về cơ bản là xây dựng các đường dẫn thích hợp thay vì điều chỉnh kế hoạch kết quả).

Khi tôi nói việc hợp nhất cho phép chúng tôi đơn giản hóa mã XL và làm cho nó gần với PostgreSQL hơn, ý tôi là gì? Cách đơn giản nhất để định lượng sự thay đổi là thực hiện “git diff –stat” đối với nhánh ngược dòng phù hợp và so sánh các con số. Đối với nhánh 9,5 và 9,6, kết quả như sau:

Rõ ràng, hợp nhất 9,6 làm giảm đáng kể vùng đồng bằng so với thượng nguồn (tổng cộng ~ 14%). Sự khác biệt này đến từ đâu?

Thứ nhất, một số giảm đó là do đơn giản hóa mã chính hãng. Một ví dụ điển hình của điều này là tổng hợp song song, là sự thay thế khá nhiều 1:1 của việc triển khai Postgres-XL ban đầu. Vì vậy, chúng tôi chỉ tách nó ra và thay vào đó sử dụng triển khai ngược dòng. Chúng tôi hy vọng sẽ tìm thấy nhiều địa điểm như vậy hơn trong tương lai và sử dụng triển khai ngược dòng thay vì duy trì của riêng chúng tôi.

Thứ hai, phần lớn mức giảm đến từ việc loại bỏ mã chết. Chúng tôi không chỉ giảm bớt một số đoạn mã chết / không thể truy cập, chúng tôi còn phát hiện ra một số tệp nguồn thậm chí còn chưa được biên dịch, v.v.

Tiếp theo là gì?

Tại thời điểm này, chúng tôi đã hợp nhất các thay đổi lên đến b5bce6c1, đây là nơi mà PostgreSQL 9.6 tách khỏi master. Vì vậy, để bắt kịp với PostgreSQL 9.6.2, chúng ta cần hợp nhất các thay đổi còn lại trong nhánh 9.6. Xem xét hầu hết chỉ có các bản sửa lỗi, đó phải là một công việc (hy vọng) khá đơn giản so với hợp nhất đầy đủ.

Tất nhiên, sẽ có lỗi. Trên thực tế, vẫn có một vài bài kiểm tra hồi quy thất bại ở thời điểm này. Điều đó cần được khắc phục trước khi phát hành chính thức XL 9.6. Và chúng tôi cần thử nghiệm nhiều hơn, vì vậy nếu bạn quan tâm đến việc trợ giúp Postgres-XL, điều này sẽ cực kỳ có lợi.

Một điều khó chịu mà chúng ta vẫn thường nghe đến là các gói hoặc thiếu chúng. Bạn có thể nhận thấy các gói cuối cùng có sẵn khá cũ và chỉ có .rpm, không có gì khác. Chúng tôi dự định giải quyết vấn đề này và bắt đầu cung cấp các gói cập nhật với nhiều loại (ví dụ:.rpm và .deb).

Chúng tôi cũng có kế hoạch thực hiện một số thay đổi đối với cách tổ chức quá trình phát triển, để giúp việc đóng góp và tham gia vào quá trình phát triển trở nên dễ dàng hơn. Đó thực sự là một chủ đề riêng biệt không liên quan đến nhánh 9.6, vì vậy tôi sẽ đăng thêm thông tin chi tiết về vấn đề đó trong vài ngày tới.