Thiết kế cơ sở dữ liệu để cho nhiều bên thuê trên điện toán đám mây

Thiết kế cơ sở dữ liệu để cho nhiều bên thuê trên điện toán đám mây Giới thiệu Điện toán đám mây là thị trường mở mà trước đây các doanh nghiệp còn chưa nhòm ngó đến. Một số công ty phần mềm bây giờ đang nghĩ đến việc cung cấp phần mềm của họ như là một dịch vụ thay vì phương thức phát triển phần mềm thông thường và bán chúng cho khách hàng của họ bằng cách sử dụng phương pháp phân phối điển hình. Để trở thành nhà cung cấp phần mềm như là một dịch vụ (SaaS), các công ty cần phải tìm được sự cân bằng đúng mức, khi tài nguyên được chia sẻ giữa nhiều người thuê khác nhau để giảm chi phí, trong khi vẫn đảm bảo rằng thông tin khách hàng được giữ kín riêng tư với các khách hàng khác. Không có vấn đề gì nghiêm trọng hơn là việc có thể xem thông tin riêng tư của một bên thuê từ tài khoản của một bên thuê khác. Ngoài thông tin riêng tư của người thuê, các nhà cung cấp SaaS phải cung cấp một mức độ tuỳ biến nào đó cho khách hàng của họ. Trong một môi trường nhiều người thuê, công ty SaaS có thể giảm chi phí nếu họ chia sẻ hoặc sử dụng lại nhiều hơn các nguồn tài nguyên của họ. Tuy nhiên, càng nhiều công ty chia sẻ tài nguyên, thì công ty càng phải đối mặt với nhiều rủi ro hơn, bởi vì sự cố ngừng một tài nguyên chia sẻ chung có thể nhiều khả năng ảnh hưởng đến nhiều khách hàng. Các nguồn tài nguyên được chia sẻ nhiều hơn cũng tăng thêm độ phức tạp cho giải pháp. Hình 1 đã được sử dụng trong một số bài thuyết trình của IBM để cho thấy tổng quan của một môi trường ứng dụng nhiều người thuê. Hình 1. Hình 1. Môi trường ứng dụng nhiều người thuê Đối với bài viết này, chúng tôi sẽ chỉ tập trung vào các tầng dữ liệu được hiển thị ở phía bên phải của hình 1, và chúng tôi sẽ sử dụng phần mềm DB2. Các tầng khác có thể được xử lý bởi phần mềm IBM khác, chẳng hạn như phần mềm WebSphere Portlet factory (nhà máy Portlet của WebSphere), WebSphere Portal Server (Máy chủ Portal của WebSphere), Tivoli® Directory Server (Máy chủ Directory của Tivoli), Tivoli Directory Integrator (Trình tích hợp Directory của Tivoli), Tivoli Provisioning Manager (Trình quản lý hậu cần của Tivoli), Tivoli Monitoring (Giám sát của Tivoli), Tivoli Usage and Accounting Manager (Trình quản lý sử dụng và kế toán của Tivoli) và v.v.. Tính năng cho nhiều người thuê tại tầng dữ liệu bằng cách sử dụng DB2 có thể được sử dụng trong các tình huống khác nhau như được thảo luận trong sáu trường hợp sau đây. Cũng nên nhớ rằng nếu bạn là một công ty nhỏ và muốn giảm chi phí mua giấy phép, bạn có thể xem xét việc sử dụng phiên bản miễn phí của DB2: DB2 Express-C. DB2 Express-C không có bất kỳ giới hạn nào về kích thước cơ sở dữ liệu. Về đầu trang Trường hợp 1: Chia sẻ bảng Trong trường hợp này, các tài nguyên sau được chia sẻ:  Máy chủ cơ sở dữ liệu  Cá thể DB2  Cơ sở dữ liệu  Một hoặc nhiều không gian bảng  Một hoặc nhiều bảng Hình 2 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này. Các bảng inventory (kiểm kê hàng), customer (khách hàng) và order (đơn hàng) có thông tin từ các khách hàng của nhiều bên thuê khác nhau.. Hình 2. Hình 2. Trường hợp 1: Chia sẻ bảng Các lợi thế của trường hợp này là nó cung cấp chi phí thấp nhất, lưu trữ thấp nhất, số tiền mua giấy phép DB2 tối thiểu và số lượng tối thiểu các cá thể đám mây cần thiết. Những bất lợi chính là nếu một bảng hỏng chẳng hạn, nó ảnh hưởng đến tất cả khách hàng. Ngoài ra, có thể có thêm sự phức tạp của ứng dụng nữa khi luôn phải cố gắng để xác định cần lấy ra những bản ghi nào trong các truy vấn của bạn để phục vụ một người thuê đã cho. Về đầu trang Trường hợp 2: Chia sẻ cơ sở dữ liệu Trong trường hợp này, các nguồn tài nguyên sau được chia sẻ:  Máy chủ cơ sở dữ liệu  Cá thể DB2  Cơ sở dữ liệu Hình 3 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này. Hình 3. Hình 3. Trường hợp 2: Chia sẻ cơ sở dữ liệu Trong trường hợp này, lợi ích là chia sẻ cơ sở dữ liệu vẫn còn chi phí tương đối thấp do vẫn còn sử dụng một giấy phép DB2 và một cá thể đám mây. Sự cô lập dữ liệu là tốt bởi vì sử dụng các tập hợp bảng khác nhau. Tùy biến từ phối cảnh dữ liệu dễ dàng hơn vì mọi người thuê đều có bộ bảng riêng. Các điểm bất lợi là phải cần lưu trữ nhiều hơn vì bạn cần tạo ra một tập hợp các bảng tương tự nhau cho mỗi người thuê. Vì vậy, khi so sánh với trường hợp 1, bạn sẽ được sử dụng x lần nhiều hơn dung lượng lưu trữ, trong đó x là số lượng người thuê. Sự phức tạp ứng dụng cũng tăng lên và không được linh hoạt lắm, vì bây giờ bạn cần tùy chỉnh các ứng dụng của bạn để xử lý tên bảng khác nhau và có khả năng là cả các cấu trúc bảng khác nhau trong trường hợp có tùy biến riêng cho người thuê. Về đầu trang Trường hợp 3: Chia sẻ cơ sở dữ liệu và sử dụng tên lược đồ khác nhau Trong trường hợp này, các nguồn tài nguyên sau được chia sẻ:  Máy chủ cơ sở dữ liệu  Cá thể DB2  Cơ sở dữ liệu Hình 4 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này. Hình 4. Hình 4. Trường hợp 3: Chia sẻ cơ sở dữ liệu và sử dụng tên lược đồ khác nhau Theo trường hợp này, lợi ích là chi phí vẫn còn thấp, gần như giống với trường hợp 2. Bạn vẫn cần một giấy phép DB2 và một cá thể đám mây. Cô lập dữ liệu là tốt vì sử dụng các tập hợp bảng riêng biệt. So sánh với trường hợp 2, có ít phức tạp hơn trong các ứng dụng bởi vì có thể sử dụng các câu lệnh SQL hoàn toàn như nhau. Chuyển hướng truy vấn đến tập hợp các bảng cho trước được thực hiện bằng cách thay đổi tên lược đồ bằng lệnh SET SCHEMA. Các tuỳ chỉnh của một bảng đã cho đương nhiên sẽ làm phức tạp thêm ứng dụng của bạn. Điểm bất lợi, giống như trong trường hợp 2, bạn vẫn phải sử dụng không gian lưu trữ nhiều hơn bởi vì bạn sẽ tạo ra một tập hợp bảng cho mỗi người thuê. Về đầu trang Trường hợp 4: Chia sẻ cá thể Trong trường hợp này, các nguồn tài nguyên sau được chia sẻ:  Máy chủ cơ sở dữ liệu  Cá thể DB2 Hình 5 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này. Hình 5. Hình 5. Trường hợp 4: Chia sẻ cá thể Trong trường hợp này, lợi ích là chi phí vẫn còn thấp, gần như giống như trong trường hợp 2. Bạn vẫn sẽ cần một giấy phép DB2 và một cá thể đám mây. Cô lập dữ liệu là rất tốt bởi vì mỗi người thuê có cơ sở dữ liệu riêng của mình, cơ sở dữ liệu này trong DB2 là một đơn vị độc lập. Mỗi cơ sở dữ liệu có thể được định cấu hình và được duy trì một cách độc lập, mang lại nhiều linh hoạt hơn. Sự phức tạp của ứng dụng ít hơn trường hợp 1. Cấu trúc bảng cho hầu hết các bảng sẽ giống nhau trong tất cả các cơ sở dữ liệu. Nếu một người thuê có yêu cầu tùy biến, thì có thể thay đổi định nghĩa bảng, nhưng điều này làm cho các ứng dụng thêm phức tạp. Điểm bất lợi là bạn sẽ cần lưu trữ nhiều hơn. Mỗi cơ sở dữ liệu DB2 tạo ra danh mục của riêng mình, mà trong các sản phẩm cơ sở dữ liệu khác được gọi là từ điển dữ liệu, do đó, sẽ phải tạo ra nhiều bảng, nhiều khung nhìn hơn cũng như các đối tượng cơ sở dữ liệu khác từ hệ thống. Ngoài ra, trong trường hợp của DB2, sẽ có giới hạn không quá 256 cơ sở dữ liệu hoạt động trong mỗi cá thể, do đó, theo kịch bản này, chỉ không quá 256 người thuê có thể làm việc đồng thời. Một nhược điểm nữa là mức tiêu thụ bộ nhớ của bạn cũng tăng lên, nó có thể là sự phiền hà về hai mặt:  Bạn có thể đạt tới giới hạn bộ nhớ của ấn bản DB2 mà bạn đang sử dụng, và sẽ phải mua một ấn bản DB2 đắt tiền hơn.  Bạn có thể đạt tới giới hạn bộ nhớ trong cá thể điện toán đám mây của bạn, trong trường hợp này, bạn sẽ cần phải chọn cá thể đám mây đắt tiền hơn. Về đầu trang Trường hợp 5: Chia sẻ máy chủ cơ sở dữ liệu Trong trường hợp này, chỉ có các tài nguyên máy chủ cơ sở dữ liệu được chia sẻ. Hình 6 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này. Hình 6. Hình 6. Trường hợp 5: Chia sẻ máy chủ cơ sở dữ liệu Trong kịch bản này, mỗi người thuê nhận được cá thể DB2 của riêng họ. Lợi ích đầu tiên là kiểm soát truy cập tốt. Sự phức tạp của ứng dụng tương tự như trường hợp 4. Tuy nhiên, người quản trị hệ thống phải định cấu hình các thông số kết nối một cách thích hợp trong tất cả các cá thể, có nghĩa là phải làm nhiều công việc hơn. Cấu trúc bảng cho hầu hết các bảng là như nhau, và giống như trong trường hợp 4, đối với một người thuê nhất định, bạn có thể tùy chỉnh một số bảng, nhưng phải thay đổi ứng dụng. Một lợi ích khác là mỗi cá thể và cơ sở dữ liệu có thể được duy trì độc lập. Nếu bạn bỏ đi một cá thể, thì nó chỉ ảnh hưởng đến một người thuê. Một lần nữa, liên quan đến các bất lợi, bạn cần lưu trữ nhiều hơn các trường hợp khác và bạn cũng có thể gặp phải các vấn đề liên quan đến bộ nhớ. Mặc dù số lượng các cá thể trong DB2 được giới hạn bởi các giới hạn của hệ điều hành, và mặc dù khởi chạy một cá thể không tiêu thụ nhiều bộ nhớ, nhưng nếu như nhiều cá thể được khởi chạy, mỗi cá thể có một số cơ sở dữ liệu hoạt động tại cùng thời điểm thì vẫn có thể gây ra các vấn đề bộ nhớ. Kết quả là, bạn có thể bị buộc phải thay đổi ấn bản DB2 của mình để mua bạn một ấn bản mới đắt tiền hơn hoặc thay đổi cá thể đám mây của bạn bằng một cá thể lớn hơn và đắt tiền hơn. Ngoài những bất lợi này, sự phức tạp về quản trị cũng sẽ tăng lên, điều này có thể khiến cho các công ty thuê thêm tài nguyên và ảnh hưởng trực tiếp đến chi phí. Về đầu trang Trường hợp 6: Chia sẻ máy chủ cơ sở dữ liệu với nhiều bản sao của DB2 Trong trường hợp này, chỉ có các tài nguyên máy chủ cơ sở dữ liệu được chia sẻ. Hình 7 là tổng quan của các tài nguyên được chia sẻ trong trường hợp này. Hình 7. Hình 7. Trường hợp 6: Chia sẻ máy chủ cơ sở dữ liệu với nhiều bản sao của DB2 Với mục đích cung cấp phần mềm như một dịch vụ (SaaS), thực sự không có lợi ích gì khi sử dụng cách tiếp cận này. Có một số nhược điểm:  Nhiều bản sao của mã DB2 hơn phải được lưu trữ trong cá thể đám mây của bạn, do vậy chiếm nhiều không gian.  Bạn phải cài đặt và định cấu hình DB2 cho mỗi bản sao đã cài đặt, do đó mất nhiều thời gian thiết lập quản trị.  Có nhiều phức tạp về ứng dụng, và loại môi trường này có thể gây nhầm lẫn cho các nhà phát triển ví dụ như sẽ kết nối đến cơ sở dữ liệu nào, trong cá thể nào của bản sao DB2 nào.  Nó có những vấn đề về bộ nhớ và tốn nhiều vùng lưu trữ, tương tự như trường hợp 5 Tóm lại, trường hợp này không có lợi ích thực sự, nhưng được bàn thêm trong bài viết này để cho đầy đủ. Về đầu trang Tùy biến trong tầng dữ liệu Như đã đề cập, việc tuỳ biến cho người thuê nào đó có thể thêm sự phức tạp cho ứng dụng và quản lý. Phần này mô tả có thể xử lý tuỳ biến như thế nào bằng cách sử dụng XML - cụ thể là công nghệ pureXML của DB2, công nghệ này cung cấp sự linh hoạt hơn. Hình 8 cho thấy một ví dụ. Hình 8. Hình 8. Xử lý các tùy chỉnh cho các máy khách riêng biệt của người thuê riêng biệt Hình này cho thấy người thuê có nhiều khách hàng và mỗi khách hàng có hồ sơ khác nhau. Cột ID của người thuê (TID) ở cả hai bảng được sử dụng để xác định người thuê. Dòng 1 và 3 trong bảng bên trái thuộc về một người thuê với TID là 1, hàng 2, 4, và 5 thuộc về người thuê khác với TID là 2. Giả sử người thuê số 2 (TID = 2) có một quy tắc kinh doanh, theo quy tắc này khách hàng không thể nhập vào thông tin về số điện thoại, do đó lưu trữ thông tin về số điện thoại sẽ không được áp dụng đối với người thuê này. Tuy nhiên, trong một môi trường nhiều người thuê với các bảng được chia sẻ (trường hợp 1), công ty SaaS cần phải xem xét rằng người thuê khác lại muốn bao gồm các thông tin về số điện thoại. Bằng cách sử dụng cơ sở dữ liệu SQL truyền thống (bảng bên trái), nhà cung cấp SaaS có thể tạo ra bảng cột cố định, trong đó bao gồm các cột cho tất cả các trường hợp về số điện thoại có thể có (số điện thoại di động, số điện thoại nhà). Ngay cả nếu người thuê số 2 không cho phép nhập số điện thoại trong hồ sơ khách hàng, thì vẫn có cột này. Vì vậy, có rất nhiều "lỗ hổng" và dữ liệu bị rải rác, thưa thớt, như được đánh dấu bằng các vòng tròn trong hình 8. Ngoài ra, giả sử người thuê số 1 (TID = 1) muốn thay đổi yêu cầu của họ, muốn rằng không chỉ lưu trữ số điện thoại di động và số điện nhà riêng mà còn cả số điện thoại tại nơi làm việc. Trong tình huống này, bạn có thể phải thay đổi bảng. Tuy nhiên, nếu bạn làm theo các quy tắc chuẩn hóa trong thiết kế cơ sở dữ liệu, bạn thực sự cần tạo ra một bảng PHONE (Số điện thoại) riêng biệt. Sau đó, bạn sẽ phải di chuyển dữ liệu và thay đổi các ứng dụng của bạn để truy vấn SQL của bạn trỏ đến bảng PHONE mới và dùng phép nối bảng (join). Phương pháp này không linh hoạt. Ở bên phải của Hình 8 là phương pháp được đề xuất nhằm xử lý tùy chỉnh. Bảng trong trường hợp này chỉ có hai cột, cột thứ hai được định nghĩa với kiểu dữ liệu là XML. Bằng cách sử dụng XML, sẽ có nhiều linh hoạt hơn để xử lý các thay đổi trong lược đồ cơ sở dữ liệu. Ngoài ra, với công nghệ pureXML của DB2, hiệu suất được cải thiện rất nhiều. DB2 9.7 cũng cho phép tiến triển lược đồ, nên các thay đổi trong tương lai với một lược đồ XML có thể được dễ dàng áp dụng. Ngoài ra, DB2 cho phép nhiều lược đồ XML cho một cột, do đó mỗi người thuê có thể sử dụng lược đồ XML riêng biệt. Về đầu trang Tóm tắt Trong bài viết này, chúng tôi đã nói về những cân nhắc mà các nhà cung cấp SaaS mới cần phải xem xét khi phát triển các ứng dụng mới hoặc sửa đổi những ứng dụng hiện có. Bài viết này thảo luận các cân nhắc hoặc các trường hợp chỉ từ góc độ cơ sở dữ liệu, cụ thể là từ phối cảnh của DB2. Sáu trường hợp hay phương pháp đã được mô tả. Trong nhiều tình huống trong thế giới công nghệ thông tin, bạn cần phải tìm sự cân bằng chi phí so với yêu cầu khi lựa chọn một phương pháp nào đó so với phương pháp khác. Các phương pháp mà bạn chia sẻ nhiều nhất cho phép sử dụng tốt hơn các nguồn lực và chi phí ít hơn. Tuy nhiên, nếu không được thiết kế một cách đúng đắn, chúng có thể gây ra rất nhiều rắc rối bởi vì sự cố của một tài nguyên có thể ảnh hưởng đến nhiều người thuê. Ngoài ra, khi sử dụng các phương pháp mà bạn chia sẻ tài nguyên ít hơn có thể làm tăng chi phí của bạn, mặc dù rủi ro cho người thuê khác là ít đi. Là nhà cung cấp SaaS, bạn có thể phải lựa chọn các phương pháp, nơi bạn chia sẻ tài nguyên. Nếu bạn có các biện pháp phòng ngừa cần thiết, chẳng hạn như bằng cách sử dụng DB2 HADR, và các khả năng sẵn sàng cao và kiểm soát dự phòng khác, bạn có thể làm giảm hoặc ngăn ngừa các vấn đề trong một môi trường nhiều người thuê. Một vài trong số những kiểm soát khả năng phục hồi dữ liệu được xây dựng sẵn trong đám mây.