Tuần trước tại CHAR (10) hội nghị, chúng tôi đã có một hội thảo về “Cơ sở dữ liệu đám mây”. Nói một cách đơn giản:phải làm gì khi các yêu cầu của ca sử dụng vượt quá tài nguyên có sẵn trong máy chủ cơ sở dữ liệu.
Đây là chủ đề chính của toàn hội nghị và một số giải pháp đã được minh họa trong ngày. Một chủ đề chung là không có giải pháp nào phù hợp với tất cả các trường hợp sử dụng và mỗi giải pháp đều đi kèm với chi phí của nó; do đó bạn phải chọn giải pháp mà trường hợp sử dụng của bạn có thể chi trả.
Một điểm chung khác (mặc dù ngầm) là tập trung vào các giải pháp “cấp cao”, đó là:kết nối một số máy chủ cơ sở dữ liệu ở cấp cao hơn để mô phỏng một máy chủ duy nhất với tài nguyên lớn hơn.
Một lợi thế rõ ràng là bạn không cần phải thay đổi mã PostgreSQL được xem xét kỹ lưỡng; một hạn chế là sử dụng nhiều máy chủ cơ sở dữ liệu với các mốc thời gian độc lập của chúng, bạn đang mất một số thuộc tính hữu ích. Hai ví dụ:mất một phần ngữ nghĩa giao dịch tạo ra xung đột; phân tích cú pháp trước mỗi truy vấn bên ngoài cơ sở dữ liệu giới thiệu các hạn chế đối với các truy vấn được chấp nhận.
Cuộc thảo luận khá thú vị và khi Dimitri Fontaine đề cập đến các không gian bảng từ xa, tôi bắt đầu băn khoăn về một ý tưởng có liên quan nhưng khác biệt, đó là:liệu một cách tiếp cận cấp thấp hơn vấn đề tổng hợp tài nguyên sẽ thực sự không thực tế. Trước khi tôi có thể trình bày chi tiết, hội thảo đã kết thúc và tôi chỉ có thể phác thảo ý tưởng cho một số người xung quanh bảng trắng (trong đó có Gabriele Bartolini, Nic Ferrier, Marko Kreen, Hannu Krosing, Greg Smith) cùng với những điều cơ bản câu hỏi "nó có khả thi không?" và “điều đó có giống với thứ mà bạn đã biết không?”.
Sơ lược ngắn gọn:một ngăn xếp ứng dụng có thể được biểu diễn theo cách này
(application) --> (connection) --> (db server) --> (resources)
nơi các tài nguyên được cơ sở dữ liệu sử dụng bao gồm bộ nhớ, RAM và CPU. Mục đích là cho phép ứng dụng ra lệnh nhiều tài nguyên hơn để tăng dung lượng và tốc độ. Các ứng dụng “thông minh” quản lý một số cơ sở dữ liệu có thể được biểu thị dưới dạng
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
trong khi các giải pháp "tổng hợp kết nối" có thể được biểu thị dưới dạng
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
bằng các giải pháp "cấp thấp hơn", ý tôi là một cái gì đó như
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
có thể giống với một cái gì đó quen thuộc, nhưng nó không phải là những gì tôi đang đề xuất ở đây. Để giải thích sự khác biệt, tôi có thể tăng chi tiết và viết
(resources) = (virtual resources) --> (physical resources)
đại diện cho thực tế là ở mức thấp nhất, bạn có thể có một ánh xạ không tầm thường giữa các đối tượng vật lý và các đối tượng ảo. Ví dụ:lưu trữ SAN hoặc phân dải RAID có thể cung cấp các đĩa ảo lớn hơn bằng cách kết hợp các đĩa vật lý nhỏ hơn với nhau. Những trường hợp như vậy có thể được mô tả như là
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Đề xuất của tôi là gộp các tài nguyên tại máy chủ cơ sở dữ liệu để chúng ta có thể có “ảo hóa” hiệu quả hơn bằng cách sử dụng kiến thức về các trường hợp sử dụng cụ thể cho từng tài nguyên (CPU, RAM, đĩa), đồng thời chúng ta có thể tránh được những khó khăn của mô hình giao dịch. Hình ảnh sẽ là:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
Ưu điểm là chúng tôi không cần quản lý tất cả các trường hợp sử dụng có thể có cho mỗi tài nguyên ảo; chúng ta chỉ phải quản lý (và tối ưu hóa) các trường hợp sử dụng mà PostgreSQL thực sự cần. Ví dụ:WAL vẫn nên được viết trong bộ lưu trữ cục bộ “không được thực hiện”, bgwriter sẽ truy cập tài nguyên cục bộ và từ xa (RAM và đĩa), v.v.
Vài lời cuối cùng về độ tin cậy. Để vận hành tốt toàn bộ hệ thống cần từng hệ thống con; các lỗi một phần không được quản lý, bởi vì kiến trúc này không thừa. Nó là một hệ thống phân tán, nhưng không được chia sẻ. Nếu kiến trúc này có thể cung cấp khả năng mở rộng rẻ và đơn giản thông qua một máy chủ cơ sở dữ liệu ảo có chức năng tương đương với một máy chủ vật lý với tài nguyên lớn hơn, thì tính khả dụng cao có thể đạt được theo cách tiêu chuẩn bằng cách thiết lập hai máy chủ ảo giống nhau trong cấu hình Hot Standby.
Chất lượng mạng có tác động lớn đến hiệu suất tổng thể; thiết kế này có thể hữu ích chỉ khi bạn có một loạt các máy trong cùng một mạng LAN, không chỉ vì lý do tốc độ mà còn vì lỗi mạng thực sự là lỗi hệ thống. Ngay cả với những hạn chế này, ý kiến của tôi là có tùy chọn này sẽ khá hữu ích.
Đây vẫn là một bản phác thảo, được sử dụng như một tài liệu tham khảo để thảo luận thêm. Các bước có thể tiếp theo:
- để tạo danh sách chi tiết về các trường hợp sử dụng tài nguyên
- để quyết định công nghệ nào có thể hỗ trợ tốt nhất trong từng trường hợp sử dụng
- để ước tính hiệu suất thực tế / chi phí phát triển
