Cho dù bạn có tham gia hội nghị CHAR (10) của chúng tôi vào tháng trước hay không, thì giờ đây bạn có thể hồi tưởng lại một phần trải nghiệm bằng cách tải xuống các trang trình bày hội nghị. Một số trong số đó đã được đăng trực tiếp trong hội nghị, một số hiển thị sau đó, nhưng hầu hết mọi thứ đều ở đó bây giờ. Đáng buồn thay, bài thuyết trình thú vị của Nic Ferrier về cách WooMe (được Zoosk mua lại) được mở rộng quy mô bằng Londiste và Django không có sẵn ở dạng mà chúng tôi có thể dễ dàng phát lại. Đối với điều đó, bạn chắc chắn phải có mặt ở đó, theo nhiều cách.
Hai cuộc nói chuyện mà tôi thấy có nhiều thông tin nhất là cập nhật về trạng thái của pgpool-II và pgmemcache. Cả hai công cụ đó đều có sự kết hợp hơi khó chịu là thực sự hữu ích và một chút ít tài liệu liên quan đến mức độ phức tạp của chúng (ít nhất là bằng tiếng Anh!), Vì vậy việc có thêm thông tin chi tiết về chúng từ những người thực sự làm việc trên mã là điều tuyệt vời.
Cuộc thảo luận của Markus về MVCC và phân cụm cũng có một điểm nhấn thú vị. Buổi nói chuyện của anh ấy kết thúc bằng phân tích hiệu suất của Postgres-R so với pgpool-II, Postgres-XC và PostgreSQL 9 bằng cách sử dụng Streaming Replication cộng với Hot Standby, tất cả đều được sử dụng trong cấu hình cụm để tăng tốc kết quả kiểm tra dbt2. Tôi không hoàn toàn đồng ý với tiền đề của ông ở đó rằng tắc nghẽn mạng là thành phần quan trọng nhất của cụm vì “khả năng tính toán tổng thể, bộ nhớ và dung lượng lưu trữ dễ dàng mở rộng” – điều đó không phải lúc nào cũng đúng – nhưng thật hài lòng khi thấy rằng PG9 HS / SR Việc ghép nối có hiệu quả về mặt đó.
Hội nghị dành ra hai phiên thảo luận về các chủ đề phân nhóm chung theo một cách tương đối không có cấu trúc. Cuộc thảo luận sôi nổi hơn nói về điều gì sẽ khiến việc triển khai PostgreSQL vào cơ sở hạ tầng điện toán đám mây dễ dàng xử lý hơn. Điều đó đã khuấy động đủ ý tưởng để tạo ra hai mục blog từ các đồng nghiệp của tôi.
Một trong những ý tưởng từ phiên đó mà tôi thấy đặc biệt thú vị là lưu ý rằng nếu bạn có một triển khai trong đó các nút được thêm vào theo cách mà mọi người thích để thảo luận liên quan đến khái niệm đám mây, có một khoảng cách quản lý ở đó ngay bây giờ về việc giúp các ứng dụng dễ dàng nói chuyện với tập hợp nút đó. Nếu bạn có thể đặt pgpool-II hoặc pgBouncer giữa ứng dụng của mình và tập hợp các nút, bạn có thể tóm tắt chính xác những gì đằng sau các nút ngay bây giờ. Nhưng bây giờ bạn đã thêm một lớp khác và do đó có thể là một nút thắt cổ chai cho toàn bộ vấn đề. Đó là điều ngược lại với những gì triển khai đám mây đàn hồi được cho là:chỉ cần thêm dung lượng khi cần với công việc quản lý tối thiểu.
Một cách tiếp cận giải pháp được đề xuất là giúp dễ dàng hơn trong việc xây dựng thư mục định tuyến cơ sở dữ liệu ở cấp ứng dụng, để các ứng dụng chỉ có thể yêu cầu loại nút cần thiết và nhận một nút để kết nối trực tiếp. Các nút chỉ có thể tự đăng ký vào thư mục khi chúng được đưa trực tuyến (hoặc được gỡ xuống). Điều này có điểm tương đồng với một số thành phần đã trôi nổi xung quanh. Phần tra cứu thư mục bạn có thể đưa vào LDAP; Các máy chủ PostgreSQL đã có thể tự thông báo thông qua ZeroConf AKA Bonjour. Không khó để tưởng tượng việc kết hợp hai thứ đó lại với nhau, đặt một lớp ứng dụng có chức năng tra cứu LDAP được kết nối với một chương trình phụ trợ định tuyến theo dõi các nút có sẵn thông qua bất kỳ giao thức nào. Như thường lệ, chi tiết của quỷ dữ. Những thứ như định thời gian cho các nút bị lỗi, phân biệt giữa lưu lượng đọc và ghi (pgpool-II thực hiện điều đó bằng cách thực sự phân tích cú pháp SQL, điều này rất tốn kém) và làm cho các chương trình phát sóng thư mục kết quả được lưu vào bộ nhớ cache để có hiệu suất cao trong khi tính năng vô hiệu bộ nhớ cache đều là những chi tiết triển khai phức tạp để làm đúng.
Với PostgreSQL 9.0 có nhiều cách hơn bao giờ hết để mở rộng cấu trúc cơ sở dữ liệu hướng lên, vấn đề này sẽ không biến mất. Tôi không chắc mọi người sẽ giải quyết nó ở dạng nào, nhưng đó là một vấn đề đủ phổ biến và đáng để giải quyết.
